linux-kernel - Re: [PATCH] Added 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: <20090701154151.7f45abad@lxorguk.ukuu.org.uk>
Date:	Wed, 1 Jul 2009 15:41:51 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	tridge@...ba.org
Cc:	Pavel Machek <pavel@....cz>,
	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
	john.lanza@...ux.com, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org,
	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>,
	Steve French <sfrench@...ibm.com>,
	Mingming Cao <cmm@...ibm.com>,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCH] Added CONFIG_VFAT_FS_DUALNAMES option

> If there is another approach that achieves this goal in a better way
> then we should look at it. Can you suggest an alternative that will
> work better for Linux handheld device makers?

They can type 

patch -p1 < linux-foundation-recommended-ussa-fat.patch

which removes all the subversive terrorist code that Americans are scared
to posess.

As has already been said from their point of view thats lowest risk so
they will go that path anyway because the question is always "how do I
cover my backside maximally"

Vendors already do this for other stuff. Why is the kernel special or
different ? Take a look at Red Hat RPMS of music players, video players,
even things like netpbm for a while where JBIG had patent issues and was
simply ripped out of the package.

I think you are in real danger of creating a compromise that helps nobody

Putting the stuff in kernel upsets everyone who isn't under US rule,
creates situations where things cannot be discussed and doesn't make one
iota of difference to the vendors because they will remove the code from
the source tree options and all anyway - because as has already been said
it reduces risk.

It also sets a very dangerous precedent. What do you want to do about say
our Kconfig help for 'Taiwanese' if it doesn't meet Chinese regulations.
What about the Burmese code page. What about code submissions from Iran ?

The kernel really cannot and should not get involved in these. Its a
vendor problem. They deal with it every day of the year already from MP3
to Taiwanese flags to US crypto export regulations to patents to the
openssh option for using the DVD crypto algorithm to making sure their
language definitions don't get their product banned in some jurisdiction
or another. They have to remove games that glorify war in any way from
German product, and so on..

None of this other mass of red tape, bogocracy and the like gets dumped
on users all over the world. It's handled by specialists in vendor
companies supported by qualified legal personnel with whom they can have
full and frank discussion.

Another problem with this is that the foundation lawyers goals are almost
certainly influenced by the goal to maximise arse coverage for large
businesses with US connections. That is who pays them, that is who asks
their advice. That puts them partly at odds with the general good.

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/