* Max Vozeler <max@xxxxxxxxxxxx> wrote: > > I'm a slackware user (as indirectly mentioned before) so I work > > on the slackware installer. > > Hey, cool that you're working on this for slackware. :-) slackware won't include loop-aes and therefore the project will be just an add-on for slackware. Because of that I will only include a non-SMP kernel (I don't have the hardware for SMP testing) and only the i686 build. i486 with loop-aes doesn't make sense. One has to fiddle with loop-aes & kernel anyway. > > Well, I've got it working (proof-of-concept), but the setup is > > somewhat messy... Long story short, One has to know what one is > > doing, most likely there won't be the infamous > > Point'n'Click-interface due to the nature of a typical slackware > > install. But I have some ideas of making life more comfortable in > > this regard.... will put up a draft / roadmap when I'm confident > > about beta testers. > > Just a thought: Reading your mail I went through the issues I > came across doing similar for debian-installer -- and came to think > that some of those issues probably affect all installers independent > of the distribution to be installed. For example, the small amount > of entropy gathered up to the point of key generation. I agree. > I think it could be interesting to share some ideas and maybe code > in this area. Like, to overcome the small amount of entropy, in Debian > the user is presented with a text entry box and asked to type random > characters into it - A progress bar shows how much mindless typing > remains ;-) This is not exactly great, and I would be interested in > discussing other approaches to the problem. most likely it's going to be a simplistic setup only, nothing fancy. Just that it works and people can adapt it to their needs easily. > E.g. we could try to take advantage of hardware RNGs - but how to > detect them? hw_random used to autoload and provide a /dev/hwrandom > (IIRC) on this system here but blocked reads forever as the chipset > doesn't really have an RNG. Another idea was to just trigger any disk > IO and hope that the IDE/SCSI driver contributes entropy this way. > Or perhaps using audio/video-entropyd - but are they reliable enough > on their own or should their output be fed through something like > rngd to be safe? Or should we just use /dev/urandom? There are some approaches to this (found some sites about the topic), but I tend to stick to gpg --gen-random for now. gpg is already needed so why not make use of it ;-) It's using an implementation of "Software Generation of Practically Strong Random Numbers" by Peter Gutman, which is ok for me http://www.cs.auckland.ac.nz/~pgut001/pubs/random.pdf He published a followup-paper on the subject, but I doubt gnupg is going to tinker with that. > Regarding the implementation, large parts of our code are specific > to the Debian partitioning tool (partman) and the debconf interface > used in the installer, but maybe some bits are also applicable or > interesting for your slackware implementation, maybe blockdev-wipe > which is like dd if=/dev/zero with progress output. You can find most > of this code at [1] and there is some discussion at [2] and also > spread in the debian-boot list archives. the slackware installer is spartanic, if the disk is not partitioned one will get a nice message about fdisk ;-) However, I've stopped work on the latest official release installer because that was made for 2.4 kernels (which gave me troubles here and there.... had to use chroot et al. --- messy) and it looks like (finally!) the next release will feature a 2.6 kernel, and maybe a recent busybox for the installer. I have some ideas concerning the boot setup (create boot CD/USB stick on-the-fly, adapt initrd, patch linuxrc instead of compiling freshly) and try to get that framework running in the meantime. -- left blank, right bald
Attachment:
pgpRD3PI6wt8z.pgp
Description: PGP signature
