[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20020807094042.GO17880@blue.alter.pl>
Date: Wed, 7 Aug 2002 11:40:43 +0200
From: Radoslaw Stachowiak <radek@...er.pl>
To: owl-users@...ts.openwall.com
Subject: Re: gpg rpm signing - auto upgrade
*** Solar Designer <solar@...nwall.com> [Tuesday, 06.August.2002, 20:53 +0400]:
> 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.
Thats reasonable. What I suggest is separate key pair for automated
signing, which is signed by Your master key. Of course it should be also
published on website/pgp servers.
[..]
> 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.
as for me, there is no problem if its mtree or rpm signatures, so Your
arguments (rpm security) make sense and just go for mtree.
what I see now at mirrors are mtree files but no signatures, so looks
like that tool/scripts for mtree automated signing after builds is
needed (?). (especially file: /pub/Owl/current/i386/i386.mtree)
And while it needs some work, I think that also adding line
'rpm --sgin package' (and correct .rpmrc settings for key) is easy and
wont do any harm, while it can be benefit at some point (rpm code
reviewed and fixed) - besides rpms are much more recognized and also used.
For example i use some rpms from Owl in other distributions.
> > 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.)
i can prepare this simple script for wider use (after mtree
clarifications) - but rather every admin can create it in 5mins.
--
radoslaw.stachowiak.........................................http://alter.pl/
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.
