On 06/22/2013 10:43 AM, Greg KH wrote:
On Sat, Jun 22, 2013 at 04:56:39AM -0400, Anthony G. Basile wrote:
On 06/21/2013 11:47 PM, Greg KH wrote:
On Fri, Jun 21, 2013 at 09:54:46PM -0400, Anthony G. Basile wrote:
The bug where this was discussed is
https://bugs.gentoo.org/show_bug.cgi?id=338739
Thanks for the link, unfortunatly, things have changed since then, with
stable kernel releases happening much more frequently now (instead of
about ever 2-3 weeks, it's now, 1-2 releases a week.
So the chance for an arch team to mark anything is going to be tough.
greg k-h
I've been following, but I can't say I've been following closely.
I'm on the stable{,-commits}@vger list and the rate at which this
stuff is coming is too fast for human consumption.
So, as I am the one creating all of that "stuff", does that mean I'm
somehow not "human"? :)
Yes, yes it does :) I was one of your 40 elect when you needed minion,
but I just can't with all my other duties.
We could just drop stabilization of vanilla-sources and have people
follow ~arch. That might be closer to the meaning of ~testing vs
stable in other packages: other upstreams push out releases they
consider stable, but we don't consider them stable within Gentoo
until our QA team tests.
I agree.
Another reason for dropping all vanilla-sources to ~arch is that we
have some Gentoo specific needs that upstream will not and should
not accept, eg we are making greater use of extended attributes in
our package management, so we need end-to-end copying of xattrs.
This means preserving certain namespaces (beyond security.* and
trusted.*) on tmpfs for emerge. Gentoo users that use
vanilla-sources will loose those xattr values making vanilla-sources
~ with respect to the rest of Gentoo.
What? So we are now relying on kernel patches that are not merged
upstream for proper operation of at Gentoo-based system? That's news to
me, I've _never_ run a gentoo-based kernel on my boxes in all of my
years as a Gentoo developer, with no problems, and I don't think we want
to require this in the future, do you?
Its related to PaX coming form the grsec/pax team.
Also, why aren't these patches upstream? Were they rejected? Just not
ready? No one submitted them?
We need to maintain a special namespace on tmpfs beyond security.* and
trusted.* It is "user.pax.flags" and it is limited to 8 bytes. Without
it, we will not have end-to-end xattr support for the namespaces we need
in Gentoo.
As for why they are not upstream, I can try. I'm like 99.9% certain it
will be rejected but at the very least, if the rejection is "we don't
need that crap" then I can safely ignore it, but if the rejection is
"there's a gapping security whole" then we can at least address it even
if in the end they pulled into vanilla.
Don't ever try to differentiate at the kernel level from other distros,
it's not worth it, and will cause problems in the end. The other
distros have realized this, I thought we were smarter than that...
Like the 50k line patch that Brad spews out every other day? I
understand your point but grsec/pax has a large enough user base and
we've supported it for 10 years now.
As for not differentiating at the kernel level, our choice here was
either that or differentiate at the toolchain level. Try readelf -l on
any Gentoo elf object and tell me what you see different than, oh say,
OpenSuse. A 5 line patch to mm/shmem.c in the kernel is a small price
to pay for cleaning up the program headers of our elf objects
userland-wide. *That* will bring Genoo in line with other linux distros.
thanks,
greg k-h
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : [email protected]
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
