Hlfs iso?

Robert Connolly cendres at videotron.ca
Wed Mar 10 14:14:42 PST 2004

On March 10, 2004 02:17 pm, Dagmar d'Surreal wrote:
> ...
> You don't appear to get it.  "Security" is not just a arbitrary value
> level that you can raise up or down depending on effort expended or pour
> on like maple syrup.  While it's a nice feature, our "trusted" system
> doesn't need to be able to replicate itself because that's a feature of
> a developers platform.  It should be perfectly reasonable to accept a
> known stable system to develop from.  With respect to security, a
> self-validating toolchain is about useful as C2 certification to a
> webserver.  Unless the security measures taken reflect the computing
> environment and requirements, the result is going to be half-assed.

This is a development platform. The bootstrap issue isn't a feature problem, 
its a stability problem. The way the toolchain features build themselves, 
when you get into chap6 neither libc nor gcc are built properly yet. The gcc 
in /tools does not have ssp function built into it, and the libc in /tools 
doesn't have fpie or ssp functions built into it. So, the gcc running the 
testsuite against glibc (chap6) is not exactly the same gcc that will be 
install shortly after. Unless you replicate the whole build process again, 
purelfs style, then you can't be completely sure about the regression tests 
in chapter 6. An iso with a glibc and gcc prebuilt with ssp and fpie would 
solve this issue. A system built from an another host, like slackware, might 
very well be equally stable, but since the toolchain keeps producing slightly 
different results untill chap6 you can't be sure.

More information about the hlfs-dev mailing list