[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20020806205301.A29314@openwall.com>
Date: Tue, 6 Aug 2002 20:53:01 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: gpg rpm signing - auto upgrade
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
