bobb at netslyder.net
Tue Nov 28 10:55:40 PST 2006
No ssp will require the removal of the regex_ssp patch in the perl
section of the book. My question is if we intend not to use ssp in the
2.4 branch doesn't that compromise the level of security offered by this
kind of system? I realize that adding features to GCC can introduce
issues in and of itself, but stack smashing is one of the most common
attacks used today... Obviously if the patch affects the stability of
the system then we are not there yet.
I have been running thru what we have thus far. In pass 2 of gcc I found
I had to use --with-dynamic-linker= just to get the linker tests to
pass after a gcc install. (hence the commit that I made to the 2.4
branch adding that switch) This had me off running until the regex_ssp
patch in perl. I had initially assumed that the missing GCC ssp patch
was the mistake. I will have to go back and make my assessment of the
build process without the ssp patches.
In any event I am back from vacation, and I am eager to help.
Robert Connolly wrote:
>I'm not in favor of including ssp in this branch because it's not part of
>gcc-3.4. glibc-2.5 has memory checking stuff, the pie linking in gcc-3.4
>works good, the '-z now' options also works good. In addition to
>strlcat/strlcpy in libc, and grsecurity, and straightening out the mktemp
>usage, it's probably enough for the first stable release. I wouldn't mind
>adding openssl to the base either, with the previously discussed use of it,
>depending on how stable it seems (with pointers to cryptodev). And blowfish
>passwords is probably stable enough to include too. Owl also has some glibc
>patches for sys-queue(this depends on kernel features) and sanitize-env I've
>wanted to look at better. And cracklib is probably a good thing to add too.
>Still a ways to go it seems :-)
[This E-mail scanned for viruses courtesy of Netslyder, Inc.(http://www.netslyder.net)]
More information about the hlfs-dev