On Tue, Aug 06, 2002 at 11:29:28AM +0200, Radoslaw Stachowiak wrote: > AFAIK rpm files (/pub/Owl/current/i386/RPMS) are not sgined by pgp/gpg. That's true. None of the Owl RPM packages have embedded signatures. I do, however, sign mtree(8) specification files for releases and some snapshots that I either build offline or am able to verify and sign offline. Owl-current for i386 is constantly built on a network-connected box, so signing it with the same key is probably not a good idea (it would both risk leaking the private key that is also used for more secure things and provide a false sense of security). I should probably generate a separate key pair that could be used to sign everything that gets to our FTP feeds and could thus be used to check integrity of copies obtained via the mirrors. That'd be similar to what is used for *.kernel.org. As for starting to use RPM embedded signatures, I think this is a bad idea. RPM's signature checking code paths didn't pass my review last time I checked (about 1.5 years ago, but we're using a rather old version of RPM, and I don't think that has improved anyway). It means that RPM itself may be attacked by a malicious package. With mtree, there's much less processing of untrusted input. First, you check the (possibly detached) PGP/GPG signature on the *.mtree file. GnuPG is prepared to treat the files it checks signatures on as untrusted input. RPM would invoke GnuPG in a similar way, so there's provably no additional processing. Once the signature is checked, the *.mtree file is now trusted and thus any possible attacks on the parser in mtree(8) are irrelevant. This saves the processing RPM would do on the package prior to passing control to GnuPG as well as RPM's processing of GnuPG output. You also check the whole directory tree at once, -- mtree will even tell you if there're any extra files which aren't in the specification. This is important because "make installworld" would be willing to pick certain additional packages which normally don't exist on a particular architecture. This is not to say that we'll never provide RPM embedded signatures. We may do so just because the functionality is there. But their use will remain deprecated, in favor of mtree. > I think its a good idea and can help a lot people which dont build from > sources but use precompiled rpm packages. Yes, signatures are a good thing. > It can also help to use some kind of automated upgrade procedures (yeah, > i know, i know ;) its not secure :) which is: > > 1. fetch rpm files (e.g. use mirror command from lftp) > 2. check signatures (rpm --checksig) > 3. use rpm -F --test *rpm - to test for conflicts/broken deps > 4. do upgrade -F (without --test) or just email admin list of (already > fetched and verified) packages ready to upgrade. This is reasonable, except that step 2 should use mtree and step 4 should require manual approval. (The upgrade should preferably be done at a time when the availability of the system isn't critical.) -- /sd
This archive was generated by hypermail 2.1.3 : Sun Jan 15 2006 - 13:43:16 PST