Pushing forward with Onward.
robert at linuxfromscratch.org
Wed Jun 17 13:59:29 PDT 2009
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.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the hlfs-dev