> >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). > > This is probably a stupid question, but are you thinking of something > along the terms of having the package maintainer's public keys on the > local box to compare to? For example, a "certs keyring" package, and if > the public key isn't found the signature can't be verified?
This is exactly what I'm thinking of. The whole idea for cryptographic support is to enable trusted package downloads from the internet. > Or are you suggesting that the the package be self-signed - simply verify > the package is intact, but not cerified that its what the maintainer put > together? No, the intent is to verify the package is as originally released by the developer...not modified or molested in any way. I don't think there's much point in self-signed packages. Since I don't think we need to support package encryption (just signing), self-signing is simply a compute intesive way to verify the storage/transmission media is working properly, and there are CRC's and checksums in the compression formats for that already. The whole concept of self-signing relates more to certificate chains and webs of trust...things that I'd really rather avoid entirely. A simple signature check is the initial goal, since I'd still like a working system to fit on a floppy. 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
