From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11065 invoked from network); 19 Sep 2004 02:06:56 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 19 Sep 2004 02:06:56 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1C8r6R-00052A-Pl for arch-gentoo-dev@lists.gentoo.org; Sun, 19 Sep 2004 02:07:00 +0000 Received: (qmail 21443 invoked by uid 89); 19 Sep 2004 02:06:28 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 9048 invoked from network); 19 Sep 2004 02:06:15 +0000 Date: Sat, 18 Sep 2004 19:06:22 -0700 From: Thomas Zimmerman To: gentoo-dev@lists.gentoo.org Message-ID: <20040919020622.GA6080@darklands> Reply-To: Thomas Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <1095487827.11248.284.camel@simple> <414C5A1E.4030808@gentoo.org> <1095532070.6077.1193.camel@simple> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <1095532070.6077.1193.camel@simple> X-Operating-System: Linux darklands 2.6.8.1-ck X-Operating-Status: 13:39:18 up 8 days, 14:02, 10 users, load average: 0.27, 0.53, 0.73 User-Agent: Mutt/1.5.6i Subject: Re: [gentoo-dev] Considering dropping the hardened toolchain (A Quantitive Approach) X-Archives-Salt: 0880cb51-e40e-4ee1-a902-aaa71ea14dbf X-Archives-Hash: 5e43e158fe437a48f4b8a57c32c634d1 On 18-Sep 02:27, Ned Ludd wrote: > Alex know I love and respect your opinion but with you being mostly gone > and my own business starting is suffering due to the large amount of > time the project takes I'm not seeing a whole lot of alternatives unless > we get some help from some hard hitters. >=20 > Yes we could leave the patches in and _hope_ that things continue to > work. But who is going to watch the bugs and verify that something is > not a flaw in our own design? how do we deal with fundamental design > flaws with upstream security patches when they don't care? (I know you > know this one all to well) example > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D132149 >=20 > Where is our core documentation? Where is the comparative analysis of > security measures? Who is going to maintain our appropriate profiles? > Keeping up with virtuals is nearly a task in and of itself. Rolling > stages and working towards things like livecd's. These are fundamental > things that have to be done on a cycles that follow gentoo mainline. how > about aiming for getting some of these solutions to go gentoo mainline. > All suids and daemons for example should really be compiled the way we > do. But that's an uphill battle that I'm pretty sure I don't want to try > to tackle alone. If you think this is one area where there are "low hanging fruit", please push this into mainline Gentoo. I've used the "ssp-3.3.2-2" addition to=20 gcc to run gtk-gnutella with -fstack-guard. If it's too hard to puch these things your self, please post _something_ that intrested users can=20 point to.=20 =20 > I see things like users that have completely uninstalled the > hardened-toolchain to work around small bugs when they don't have to. I > can't comment on every bug to say here is another way you can get the > same end goal without them having to dismiss the solution completely, be > that their own ignorance or ours it's a disservice to our community do > nothing. Maybe a cycle of developer/user education needs to take place. Hardend- Gentoo looks much like a proving ground; is it time for some of that hard one effort to bear fruit in Gentoo and other projects? It does take dev buy in to make most of the easy transitions distro wide. (and I would like to believe that all source based distros _speed_ the adaption of upstream tool chains.)=20 > Being on this team means more than just watching the "hardened" bugs > that get routed to us and replying to emails once every few weeks, one > has to watch all toolchain bugs and look for how things correlate to > each other and determine the right thing to do.=20 >=20 > Other distro's are wanting to adopt similar to the same solution but > those guys need to be helped so they don't make fatal mistakes. Yes it's > a very good sign when others want to adopt it. But that's also time > consuming. Ask yourself should we keep our dear precious all to > ourselves or dedicate some time and effort to other projects of the > world. I think we should as most of these designs are being developed in > house and we by far have the most experience. > See http://d-sbd.alioth.debian.org/ for more details. >=20 > How are we going to handle the other arches. > ppc/ppc64 These two arches could be added to mix relatively easy. But > **** we can't even get one of those teams to test simple kernel patches > that were developed especially for them after multiple requests. >=20 > Peter has many questions that he needs definitive answers to. With those > questions going unanswered and him being a key player these days in your > absence we could be potentially introducing more bugs than need be. > He is/was happy with his own homegrown build system and does not really > need to support us or our efforts. >=20 > You want to help pappy? Spend your time being proactive vs defensive. > Help me train some people so the workload is reduced on us and our time > can be better spent focusing on making the next steps with more ease. >=20 > After planting the initial seeds one day and seeing things being > maintained properly long term I'd like to be just a user ya know. As always, do try and post much like this, where regular developers and=20 advanced users can see some of the problems and see where the bleeding edge is heading.=20 Thomas Zimmerman PS: Thanks. As an advanced user--without the skills to contribute to develo= pment-- your work is truely appreacated. -- gentoo-dev@gentoo.org mailing list