Welcome back. :) I have been following your progress as I notice changes in the 2.4-branch of svn. First off thank you for your hard work. I had not noticed the latest updates you mentioned here, but I will svn update and have a look tonight. I will post any issues I come across to the list.
R. Baker Robert Connolly wrote: >Hello. I just realized linuxfromscratch.org is the mail server now, not >mail.linuxfromscratch.org. 1800 messages later, I'm back. > >I fixed some of the uClibc 2.4-book issues this week. Chapter 5 builds now. I >haven't finished a chapter 6 build in a very long time, and I know there are >various problems. There was a post a while ago about adding the assertions to >a header, so fputs=assert(fputs) all the time, and I think this is a better >idea but I just haven't gotton to it yet. I apologize for the brokenness in >chapter 6 and the kernel. I'll try to start removing the assertions stuff >from chapter 6 and finish by adding a new header for <stdio.h> to wrap >affected functions in assert(). > >I'm concentrating mainly on the 2.4 branch but adding differences that work to >the trunk too. I finally added the hardened-specs header, minus >stack-protector, to the 2.4-branch. And switched uClibc-snapshot with >uClibc-0.9.28.1. > >I got rid of that Sed patch because it broke Sed. > >Regarding the two mail threads about testing the security of an HLFS system, >there is a Paxtest package at the PaX website that I'd like to add to the >book somewhere. There are also of course the test suites for each package. >And fixing compiler warnings, including backporting gcc-4.3 fixes to the >2.4-branch gcc-3.4 systems. Assertions aren't intended to be used on a >production system because of performance loss, but I think it's a good idea >because they will abort programs that have unforeseen errors. The >gcc41 'unused return value' warning fixed with assertions should make sure >every function has a contingency plan for errors. > >I'd like to mention that people who want to run linux-2.6 can still build the >2.4-book and simply boot a 2.6 kernel. 2.6 isn't stable, even though it runs >well without crashing. My cdrom used to be named /dev/hda in 2.6.18, and is >named /dev/sr0 in 2.6.19. Using the 2.6 kernels involves constant adjustments >to userland configuration, like Udev, which inherently means it's in the >development stage. The 2.6.18.x branch seems to be being maintained parallel >to the latest kernels, but who knows how long this will last. The 2.4-branch >system will allow the system to boot anything after linux-2.4.20, or so, but >won't have performance features from the later kernels. > >I've been thinking of adding pages to cross build a uClibc system, either at >the end of chapter 5 or near the end of the book, with examples of building a >4MB embedded system for a mips (netgear) router/firewall or an initrd for >booting a loop-aes encrypted drive... a Busybox system. I think this is more >what uClibc is intended for. It would preferably be built from an HLFS system >so the host is more trusted, but doesn't necessarily have to be. The howto's >for rescue systems are fairly out of date, aren't very specific, don't >mention firewalling, often lack boot scripts, and adding loop-aes, sshd >(dropbear), or addressing security concerns only complicates it. So I think >it deserves a place in the (b)hlfs-book. The uClibc config for an embedded >system isn't the same as for a full featured system because things like GCC >(wchar) support are not needed, so the libraries can be cut smaller. > >So anyway, I'll start try to fix chapter 6 so the book isn't broken anymore. > >Robert > > -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
