On Wed, Jun 17, 2009 at 3:59 PM, Robert Connolly<rob...@linuxfromscratch.org> wrote: > 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.
Ok. Well theres no harm in attempting a 4.4.0 build I suppose. I will have a look at it when I begin again. > 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. Oh lord say no more that paints a clear picture. > 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. This will be a learning experience for me, but thats really what this is all about anyway. I doubt I will come back around to this before I build through the base system again. > Add iptables to the rebooted system, and sshd, for users doing a remote build. Yes and yes. I found this to be fairly frustrating myself, and ended up adding them in for my temp tools. I also found myself needing a text editor so I included vim. Any thoughts on including an editor? > The package/file management system discussed before. It needs to be simple so > that using it is easy and second nature. I take it rpm and dpkg are a little too involved to meet your simple requirement. If I recall correctly you were more concerned about having recorded what files were introduced by what packages rather than having a full fledged package manager/build system. Correct me if I am wrong. > 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. Would you also want to include logrotate or is there a better way of handling log rotations that I have somehow missed? > 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. If that is true for most daemons this should be fairly easy to get a handle on. I am sure there will be some curve balls as usual, but such is life. > 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. I like the idea of limiting access for opening a sockets. Forgive me if I am just not aware of an example, but I don't recall any package manager requiring system files be owned by anyone other than specific. All of them that I am fimiliar with require root to do darn near anything. If your interested I would like to hear more about what you envision the package management system to be for HLFS. > 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. Sounds like the whole process will come to a head outside of the book at some point. Thats completely reasonable. I like this idea better than just assuming the user will have picked up what they need through osmosis by the time they complete the base system. I would be happy to run down blfs packages once we are further along with the base system. > 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 > I agree. I really just wanted to pick your brain to see what you had in mind for a stable release. It sounds to me like you have thought it through quite a bit. There is definitely a good deal of work to be done, but things appear to be heading in the right direction. Robert Baker -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
