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]

Message-ID: <20090710010945.234cd8aa@lxorguk.ukuu.org.uk>
Date:	Fri, 10 Jul 2009 01:09:45 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Theodore Tso <tytso@....edu>
Cc:	James Bottomley <James.Bottomley@...senPartnership.com>,
	tridge@...ba.org, Martin Steigerwald <Martin@...htvoll.de>,
	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>, corbet@....net,
	jcm@...masters.org
Subject: Re: CONFIG_VFAT_FS_DUALNAMES regressions

> However, I don't think they will think it's necessary, and I'll tell
> you why.  Regardless of whether or not source code with an #ifdef'ed

They do it for existing cases in existing packages. So I'd say the
evidence is very very clearly that they will and they do, already, now,
at this moment. No speculation - go look at the packages.

> the case), either way, the *binary*, which is to say the **product**
> does not contain any of the infringing functionality or code.  Hence,

You have a GPL obligation to supply the sources used to build the binary.

> But in any case, even for a very risk-averse company, getting this
> proposed patch into mainline is useful, since at any point in time the
> company can get a version of the code without any code that might be
> claimable as being infringing by using unifdef.  So it's still a net
> win.  And if people are worried about the very small chances of

That aspect of the argument makes sense and I would agree with you. Its
one way to keep a reference implementation in tree as a patch.

> problems (which perhaps we can improve), we can fix that as future
> patches against the mainline --- which is the right way to do OSS
> development.  Given that Hirofumi-san has already decided to take this
> patch, so unless Linus decides to override his decision, this
> discussion is rapidly becoming moot in any case.

I've not seen any evidence to support this, and there seem to be other fs
maintainers deeply unhappy with the longname corrupting patch - Christoph
included.

Alan
--
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/