From: Thomas Zimmerman <thomas@zimres.net>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Considering dropping the hardened toolchain (A Quantitive Approach)
Date: Sat, 18 Sep 2004 19:06:22 -0700 [thread overview]
Message-ID: <20040919020622.GA6080@darklands> (raw)
In-Reply-To: <1095532070.6077.1193.camel@simple>
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.
>
> 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=132149
>
> 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
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
point to.
> 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.)
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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
advanced users can see some of the problems and see where the bleeding edge
is heading.
Thomas Zimmerman
PS: Thanks. As an advanced user--without the skills to contribute to development--
your work is truely appreacated.
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2004-09-19 2:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-18 6:10 [gentoo-dev] Considering dropping the hardened toolchain Ned Ludd
2004-09-18 15:54 ` [gentoo-dev] Considering dropping the hardened toolchain (A Quantitive Approach) Alexander Gabert
2004-09-18 17:01 ` Thierry Carrez
2004-09-18 17:27 ` Rumen Yotov
2004-09-18 18:27 ` Ned Ludd
2004-09-19 2:06 ` Thomas Zimmerman [this message]
2004-09-19 5:16 ` Allen Parker
2004-09-19 5:41 ` Ned Ludd
2004-09-19 22:16 ` Lars Weiler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040919020622.GA6080@darklands \
--to=thomas@zimres.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox