RE: [Leaf-devel] Updated Oxygen Development Image - and lrp/ source directory
If people could bang away on the Oxygen development image, I'd appreciate it. I'd like to hear from some testers before I release... Finally got a chance to download (and test), so far looks good. The config.lrp handling works nicely now. Thanks! As an observation, /dev/boot seems to be a permanent symlink to /dev/fd0u1680, even when booting from /dev/hda1 (I had globally replaced fd0u1680 /w hda1 in oxygen.cnf) But I probably missed something somewhere on changing that (RTFM, right?) So far the new image looks good. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Updated Oxygen Development Image - and lrp/ sourcedirectory
Angelacos, Nathan wrote: If people could bang away on the Oxygen development image, I'd appreciate it. I'd like to hear from some testers before I release... Finally got a chance to download (and test), so far looks good. The config.lrp handling works nicely now. Thanks! As an observation, /dev/boot seems to be a permanent symlink to /dev/fd0u1680, even when booting from /dev/hda1 (I had globally replaced fd0u1680 /w hda1 in oxygen.cnf) But I probably missed something somewhere on changing that (RTFM, right?) So far the new image looks good. I tried it too, and the dhcpcd on eth0 didn't work for connecting to the new attbi.net replacement for @Home. Works on Dachstein rc2, but the system hangs during boot on Oxygen 12/8. Matthew ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: [Leaf-user] uninstall option for lrpkg
Matt Schalit wrote:
Here's what David does with Oxygen. It has
the -r option for removing a package that's
been installed.
I see a bug - it's bit me recently in another area, and I see it here!
remove () {
cd $PKGD
[ ! -f $1.list ] err no package! ($1)
grep -v $1 packages packages.new
mv packages.new packages
cd - ; cd /
rm -f `cat $PKGD/$1.list`
cd -
}
grep -v $1 will remove all packages that have the name in them from
the package list.
Probably the best (and most catastrophic!) example would be e.lrp (an
expression evaluator). Using this code to remove e would ALSO remove
(only from the package list, that is)
ettercap
etc
beep
e2fs
e3
ncurses5
ncurses4
mod-net1
mod-net2
zile
Need to change
grep -v $1 [...]
...to...
grep -v '^'$1'$' [...]
...to match a package ONLY by itself on a line - so ^e$ matches but
^etc$ does not...
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Updated Oxygen Development Image - and lrp/ source directory
Angelacos, Nathan wrote: If people could bang away on the Oxygen development image, I'd appreciate it. I'd like to hear from some testers before I release... Finally got a chance to download (and test), so far looks good. The config.lrp handling works nicely now. Thanks! Thanks for testing it out... As an observation, /dev/boot seems to be a permanent symlink to /dev/fd0u1680, even when booting from /dev/hda1 (I had globally replaced fd0u1680 /w hda1 in oxygen.cnf) But I probably missed something somewhere on changing that (RTFM, right?) To change this, you need the option boot in a source block. However, it should really BE the boot device, but flexibility is good... ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] cryptographically signed .LRPs
On Tue, 4 Dec 2001, Charles Steinkuehler wrote: snip Yeah, I think it's pretty big, plus I believe most of these packages require openssl and other huge add-ons to run. The basics of public-key cryptography, however, are pretty simple, so I think it'd be possible to make a small (a few K, perhaps) binary that would simply calculate and verify signatures, as long as there arn't too many various options to deal with (ie no cert chains, or fancy stuff, just plain-old crypto signing). And Jack Coats pointed out gpgv that might fit on a CD (283932 bytes), to which Jeff Newmiller reminded all that gpg will take that much ramdisk + RAM to run in... gpgv is the verification only part, and looking through the source code, most of it is gpg stubbed out (to be as small as possible.) From the looks of it, it is pretty close to what you were describing: gnupg 1.0.6 (gpgv), stripped and upx'ed down to 113522 bytes That's still pretty big. Or do you think that would be small enough? I don't see any way to get a pgp-like app smaller than that. Another idea might be to use OpenSSL, something like s/mime. (OpenSSL 0.9.6b stripped upx'ed is 400K or so, but it includes alot of other junk.) I saw no obvious way to strip it down without rewriting a small wrapper app that uses just a subset of the SSL libraries. (but, I make NO claims to being a coder.) With OpenSSL, you'd have to worry about maintining x509 certs, though. No solutions, just some ramblings on my thoughts. Comments or ideas welcome. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] cryptographically signed .LRPs
And Jack Coats pointed out gpgv that might fit on a CD (283932 bytes), to which Jeff Newmiller reminded all that gpg will take that much ramdisk + RAM to run in... gpgv is the verification only part, and looking through the source code, most of it is gpg stubbed out (to be as small as possible.) From the looks of it, it is pretty close to what you were describing: gnupg 1.0.6 (gpgv), stripped and upx'ed down to 113522 bytes That's still pretty big. Or do you think that would be small enough? I don't see any way to get a pgp-like app smaller than that. I'm not looking for something general purpose. The code has to do one thing, and one thing only: Given a file, a signature, and a public key, verify the signature (and hence the file's) authenticity. The public key and signature can be in a pre-defined format, if desired, although it might be nice to support varying key lengths. No pass-phrase encryptions of files, no complex code trying to keep secrets from other users of the system (that all belongs on the development side, when the package creator signs the package in the first place), no webs of trust, just a simple public-key signature verification. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] cryptographically signed .LRPs
Thought I'd contribute my brief understanding of package signing using openssl. I believe this package can be customized on install so that it only provides the tools you need. Package signing only needs (I believe) 4: md5, rsautl, genrsa, and rsa. First, you need the md5 hash of the package you're going to distribute: % openssl md5 package.lrp package.md5 Then use an RSA or DSA private key to sign the hash value. I'll use RSA here cuz the docs at www.openssl.org refere to rsautl a lot more than dsautl: % openssl rsautl -sign -in package.md5 -inkey priv.key -out package.sig Note that 'rsautl' requires version 0.9.6 or above. I'm pretty sure all of this is doable without it, but it'd take more poking around to be sure. Anyhow...the signature file is written to package.sig. This presumes you have a RSA private key in the priv.key file. To generate one, do this: % openssl genrsa -rand /dev/random -out priv.key That generates a private key into priv.key. To get the public key you should distribute along with package.sig, do this: % openssl rsa -in priv.key -out pub.key -pubout Now you got package.sig and pub.key which you can send out to anyone. The remote user verifies everything's cool with: % openssl rsautl -in package.sig -verify -inkey pub.key -pubin I think all the details are there. Hope this helps... -Scott And Jack Coats pointed out gpgv that might fit on a CD (283932 bytes), to which Jeff Newmiller reminded all that gpg will take that much ramdisk + RAM to run in... gpgv is the verification only part, and looking through the source code, most of it is gpg stubbed out (to be as small as possible.) From the looks of it, it is pretty close to what you were describing: gnupg 1.0.6 (gpgv), stripped and upx'ed down to 113522 bytes That's still pretty big. Or do you think that would be small enough? I don't see any way to get a pgp-like app smaller than that. I'm not looking for something general purpose. The code has to do one thing, and one thing only: Given a file, a signature, and a public key, verify the signature (and hence the file's) authenticity. The public key and signature can be in a pre-defined format, if desired, although it might be nice to support varying key lengths. No pass-phrase encryptions of files, no complex code trying to keep secrets from other users of the system (that all belongs on the development side, when the package creator signs the package in the first place), no webs of trust, just a simple public-key signature verification. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] New Oxygen Development Image
Now the configurations aren't secret anymore :) Press 'F5' at the main screen (undocumented) to get at it. In the actual CDROM, the standard splash screen and the CDROM splash screen will switch places. Also, an undocumented configuration: testcd.cfg - you'll have to specify another configuration and add a conf=testcd.cfg parameter for now. The purpose was to boot from floppy, load packages from floppy, then load the rest of the boot packages from CDROM - followed by whatever standard set of packages (presumably from CDROM). new.load had to be revamped entirely, but should be better now. The problem was include files; now it seems to work solidly (didn't before). For some reason, using the current floppy and CDROM will cause a SegFault if the packages in boot/*.lrp are loaded (!). It happens consistently, right after ctar apparently. For this reason, the system does NOT lock up after an error during package loading. Maybe someone can test this out. I can't imagine what it is - unless usr.lrp had something to do with it (it had some files duplicated from other packages in it). The floppy usr.lrp is fixed. Maybe my CDROM is bad (?) but after booting with a configuration that skipped boot/* the packages in boot/* tested fine. I'll try some more tonight or tomorrow. In spite of setbacks, I feel very good about the current state of development; a release should come soon. Now if I could just get to making a Resource CDROM... ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
