From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 57FF31381F3 for ; Mon, 24 Jun 2013 22:05:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 84706E09FE; Mon, 24 Jun 2013 22:05:36 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E0309E09FD for ; Mon, 24 Jun 2013 22:05:35 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway2.nyi.mail.srv.osa (Postfix) with ESMTP id 14AD520F79 for ; Mon, 24 Jun 2013 18:05:35 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 24 Jun 2013 18:05:35 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=QV4UCA0mXYGVNfHnJbLXTDGv8EM=; b=j8kwkQJMYXBckHLqOiaYO650AYsn XC53b/hKhwANzJRhQ+HwSwl4vnnzqdt5LdDOUA3mAK+wjkEzQX/Lnpq4rGuMvU7o fwvXNivxg2owj5xkQsTcd3V9msqvFUPBJ+suXySzytP37AqVK1zFxvP+xrIueUG+ 4lNxq1GGsRim8/E= X-Sasl-enc: smdW2vMqxVNKer4tGeANh8SjHDFz93Yol64HAw1HExu9 1372111534 Received: from localhost (unknown [76.28.172.123]) by mail.messagingengine.com (Postfix) with ESMTPA id B521C680469; Mon, 24 Jun 2013 18:05:34 -0400 (EDT) Date: Mon, 24 Jun 2013 15:05:33 -0700 From: Greg KH To: gentoo-kernel@lists.gentoo.org Subject: Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions Message-ID: <20130624220533.GA22438@kroah.com> References: <20130621145801.GA5202@kroah.com> <20130622020259.7a411a7a@TOMWIJ-GENTOO> <20130622001303.GA2278@kroah.com> <20130622024516.3a51911e@TOMWIJ-GENTOO> <51C503E6.9080605@gentoo.org> <20130622034728.GB2058@kroah.com> <51C566C7.1030400@opensource.dyc.edu> <20130622144344.GA11218@kroah.com> <51C5D4C9.4030404@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-kernel@lists.gentoo.org Reply-to: gentoo-kernel@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51C5D4C9.4030404@gentoo.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 7cc5f0b1-386e-4a03-b6ea-5a2e96736df5 X-Archives-Hash: 02da5d0006ce7790b0f34aed2a96f646 On Sat, Jun 22, 2013 at 12:46:01PM -0400, Anthony G. Basile wrote: > >>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. Ah, this is just the "hardened" stuff, not the "normal" gentoo kernels, right? > >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. Any pointers to the patch so that I can take a look at it? thanks, greg k-h