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 :-) >robert > > --- [This E-mail scanned for viruses courtesy of Netslyder, Inc.(http://www.netslyder.net)] -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
