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:	Wed, 8 Jul 2009 17:18:48 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	tridge@...ba.org, Martin Steigerwald <Martin@...htvoll.de>,
	Jan Engelhardt <jengelh@...ozas.de>,
	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
	Theodore Tso <tytso@....edu>,
	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

> > That represents loss of functionality for loss of risk (a trade off).
> 
> Precisely ... that's what this whole thread is about.  Accepting the
> lawyer's argument that this patch eliminates the risk of suit under the
> FAT32 patents, does the loss of functionality it comes with represent an
> adequate reward?

You are missing the point still.

Ship with problem feature enabled	risk high    features high
Ship with problem off but in source	risk lower   features low
Ship with it ripped out			risk lowest  features low

So the only two logical positions to operate are low feature/lowest risk
and high feature/high risk. So if you decide not to ship the feature it'll
get ripped out entirely.

> OK, so we disagree on whether providing source code constitutes
> contributory infringement.

We disagree whether there is zero risk involved. If there is any risk
then the logical position if you've decided not to enable the feature is
not to ship source for it.

> OK, so rather than get into a what my lawyer says versus what your
> lawyer says argument, can we get back to the technical aspects of this
> and leave the lawyers retained by the vendors to sort out what they
> actually do?

Sure and I'd say the technical issues are simple

- Tridge's patch breaks stuff
- Tridge's patch masquerades as vfat but isn't.

We can fix those by only creating short names (but honouring existing
long ones) and by not claiming its vfat.

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/