linux-kernel - Re: [AppArmor 00/44] AppArmor security module overview

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:	Tue, 3 Jul 2007 02:20:20 -0400
From:	Dave Jones <davej@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	John Johansen <jjohansen@...e.de>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org
Subject: Re: [AppArmor 00/44] AppArmor security module overview

On Tue, Jun 26, 2007 at 07:47:00PM -0700, Andrew Morton wrote:

 > I suspect that we're at the stage of having to decide between
 > 
 > a) set aside the technical issues and grudgingly merge this stuff as a
 >    service to Suse and to their users (both of which entities are very
 >    important to us) and leave it all as an object lesson in
 >    how-not-to-develop-kernel-features.
 > 
 >    Minimisation of the impact on the rest of the kernel is of course
 >    very important here.
 > 
 > versus
 > 
 > b) leave it out and require that Suse wear the permanent cost and
 >    quality impact of maintaining it out-of-tree.  It will still be an
 >    object lesson in how-not-to-develop-kernel-features.

How is this different from Red Hat wearing the permanent cost of
carrying Execshield or other vetoed-by-upstream features ?

Given the choice, I'd ship a kernel for Fedora with nothing added
that isn't upstream, but we have something of a legacy from our
dumber days. (Though we've managed to drop lots of the more invasive
stuff over time thankfully.. 4g4g for eg).

 > Sigh.  Please don't put us in this position again.  Get stuff upstream
 > before shipping it to customers, OK?  It ain't rocket science.

Indeed.  The idea of granting exceptions to our usual acceptance
criteria just because "some distro shipped it" strikes me as wrong
on so many levels, regardless of its technical flaws.

And this isn't just because this is a patch from a competitor,
I'd expect the exact same criteria to be applied if I tried
to ram execshield etc down everyones throats.

	Dave

-- 
http://www.codemonkey.org.uk
-
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/