[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20020807181615.B555@openwall.com>
Date: Wed, 7 Aug 2002 18:16:15 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: gpg rpm signing - auto upgrade
On Wed, Aug 07, 2002 at 11:40:43AM +0200, Radoslaw Stachowiak wrote:
> *** 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 also exactly what I meant.
> > 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,
There're some, but not for Owl-current/i386 (yes, I know, this is what
most people are using). The Owl-current snapshots for SPARC and Alpha
do have the signatures because they're built offline. So did the 0.1
prerelease because I verified it offline. So will the next release.
> so looks
> like that tool/scripts for mtree automated signing after builds is
> needed (?). (especially file: /pub/Owl/current/i386/i386.mtree)
Yes, I'll need to patch that into my current distworld scripts.
> 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,
I'm not so sure. It could give a false sense of security to those who
haven't been watching this discussion, found out about the RPM feature
and started relying on just it.
> 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.
Yes.
But for Owl RPM is more of a necessary evil for RHL compatibility and
we tried to hide it inside the buildworld/installworld concept. When
RPM is run by our scripts, its temporary file directories are overriden
(because it deals with temporary files unsafely) and only known-safe
options are used. Unfortunately, when you run it manually, you may be
at a higher risk.
I am still hoping that someone will re-do the package manager (for Owl
specifically or otherwise), yet maintain sufficient compatibility with
RPM. But if that doesn't happen for long, we'll have to be patching
the worst known issues in RPM, although that is probably a wrong thing
to do. It really needs to be re-done.
> > > 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.
I think steps 3-4 should be a "make updateworld" or similar. That
would also ensure that RPM is run in the safe way.
I'll consider it.
You may of course share any relevant scripts with other Owl users via
this list.
--
/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.
