On Wednesday June 17 2009 02:43:07 pm robert baker wrote: > I am all for staying current so long as there are no breakages. I > would be more than willing to do a test build with an upgraded GCC > this next run through. Are you talking about moving up to GCC-4.4.0 or > do you have another release in mind?
I'm not sure. I don't even know the differences between gcc42 and gcc44, but in general newer gcc versions produce healthier systems, as long as the other packages are using compatible source code. Many distributions have patches to fix compiler warnings. After confirming the warning, I like to compare these with the package's cvs, and submit it a bug report if it's not in upstream, and observe the feedback. If it's in upstream then it's considered an upstream fix. Don't use these patches blindly, remember what happened with debian and ssl. > Would you be interested in outlining any goals that you would like to > see set for the "stable" revision of the book? I am absolutely > interested in lending a hand wherever I can. Just pretty much enough to get the user on their feet. Replace suid-root with capabilities, giving enough examples and debugging tips so the user knows what to do with blfs packages. Same with grsecurity rules, have enough examples and debugging tips so blfs packages aren't a problem. Use the blfs wiki pages to add help on a per package basis, and mention in hlfs book that users should check the blfs wiki for every package. If the tips are very hlfs specific, maybe just add a link to the blfs wiki for the hlfs wiki, to keep the blfs wiki cleaner. Add iptables to the rebooted system, and sshd, for users doing a remote build. The package/file management system discussed before. It needs to be simple so that using it is easy and second nature. Adding fcron to the final system is a good idea. This can do log rotations, reseed /dev/erandom, clean /tmp, with /etc/daily and /etc/weekly scripts. Nothing crazy. With posix capabilities daemons don't need privilege separation anymore. I haven't looked into this though. Debian has a 'runas' program that is basically like 'su -c foo bar' but it cleans the environment too. 'env -i su -c /usr/sbin/sshd sshd' might work. Daemon program files with capabilities need to be readable only by owner and group, not other, with the daemon user in the group. Grsecurity could use a little more tightening, by adding a networking group and only allowing that group to open sockets. Trusted path execution might become unusable with the file management user owning every system file and directory, but there may be a way to workaround or fix it. A while ago I tried to get libcap added to BLFS, but libcap was not maintained at that time, and needed a lot of patches to build, so BLFS decided against it. Libcap2 is maintained now, and I think BLFS would add it. They have enough to do without libcap, so we should maintain this for them. Almost every daemon in BLFS can use capabilities to drop root. After the initial patch, the maintenance should be as simple as upgrading the libcap2 package, and adding it to new blfs daemon's from time to time. The initial patch will be a major pain, involving installing every single blfs package with suid-root programs and root daemons. This is all of gnome, kde, and pretty much everything else. After a few of us do this, and confirm it works, I think we'd have a stable hlfs candidate. --warn-shared-textrel --fatal-warnings causes a build failure if mktemp() or tmpnam() are used. This affects a few blfs packages. I have patches for the packages I found. Hopefully blfs will accept these patches, otherwise they go to blfs wiki. I don't think we've come this far to slap a "stable" sticker on whatever we have and promote it. Everything needs to be checked ten times, then continue to the next task, until everything is done, then check it again. Then use the "we did it" sticker. robert
pgpZXIGGBHqMd.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
