linux-kernel - Re: CONFIG_VFAT_FS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 10 Jul 2009 22:40:14 +0200
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	Jonathan Corbet <corbet@....net>
Cc:	Martin Steigerwald <Martin@...htvoll.de>,
	David Newall <davidn@...idnewall.com>,
	Christoph Hellwig <hch@...radead.org>,
	Theodore Tso <tytso@....edu>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	tridge@...ba.org, Jan Engelhardt <jengelh@...ozas.de>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Pavel Machek <pavel@....cz>, john.lanza@...ux.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org,
	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>, jcm@...masters.org
Subject: Re: CONFIG_VFAT_FS_DUALNAMES regressions

On Friday 10 July 2009 21:31:27 Jonathan Corbet wrote:

> I have a lot of sympathy for Alan's assertion that we can't muck up our
> upstream code with hackarounds for every bit of legal obnoxiousness we
> encounter.  But outright refusal of things like patent workarounds does
> not help us either.  Linux is a pragmatic system; somehow, I believe,
> we can find a way to minimize our patent hassles without messing up the
> system as a whole.

Alan, Pavel and other people are suggesting pragmatic *long-term* solutions,
like moving kernel.org outside problematic geopolitical area.  Tainting *our*
code-base with (confusing for *our* users) workarounds doesn't belong in this
class of solutions.. actually no.. it is a PURE F*CKING IDIOCY..

Microsoft having patents on their *obsolete* filesystem should be *their*
problem, not *ours*.  We keep said filesystem strictly for compatibility
reasons and not because we would like to encourage hardware/software vendors
or users to use it.  Lets just update VFAT help text to mention potential
risks of using it, default it to N, rip it from defconfigs, pass it through
lawyers, remove CONFIG_VFAT_FS_DUALNAMES and move on..

When it comes to distributions if they really need they can easily deal with
the problem by simply allowing the 3-rd parties to host the repositories with
risky package (like they do with mp3 etc).

The end result is that end-users can still use full vfat, vendors are safe,
kernel developers don't waste their time on artificial problems and the blame
goes where it belong..

[ The validity of potentially bogus patents (or problems of hardware vendors
  caused by *their* decisions to use *obsolete* and patent-risky filesystem in
  their products) is an entirely different matter/discussion and it shouldn't
  be mixed with technical solutions.. ]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/