incubator-bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Mahé <bm...@apache.org>
Subject Fwd: Re: An ASF yum repository?
Date Mon, 27 Feb 2012 20:32:01 GMT
Forwarding to the real bigtop-dev mailing list. There is a typo in the CC.

-------- Original Message --------
Subject: 	Re: An ASF yum repository?
Date: 	Mon, 27 Feb 2012 16:30:28 +0000
From: 	Steve Loughran <stevel@apache.org>
To: 	Graham Leggett <minfrin@sharp.fm>
CC: 	Tony Stevenson <pctony@apache.org>, Apache Infrastructure
<infrastructure@apache.org>, bigtop-dev@apache.org



On 24/02/12 22:21, Graham Leggett wrote:

>
> Perhaps a workflow might be:
>
> - Someone responsible for packaging, makes an RPM build, and signs that RPM with their
PGP key that is listed in the PMC KEYS file, and checks it into the dist repository into some
kind of "incoming" directory tree in the svnpubsub driven svn repo. The RPM is now queued
for handling.
>
> - A process, running on a machine, perhaps kicked by an irc message, or cron, or responds
somehow to an svn checkin script, updates a copy of the repo. This process can run in a VM
somewhere, it doesn't need to be a server, and doesn't theoretically need to be a Redhat machine
either (only requirement is that rpmsign binaries are available and a copy of yum to reindex
the repo).
>
> - We walk the "incoming" directory tree, looking for RPMs, and verify the signatures
on each RPM using the rpmsign command, against the list of keys published by the PMC KEYS
file.
>
> - If the signed signature is valid, we add an additional signature signed by the official
ASF yum repository signing key, and then svn checkin the newly signed binary (now containing
two signatures) and svn move the RPM out of the "incoming" directory in svn to the official
yum repository path in svn.
>
> - If the signed signature is not valid, we might ignore the RPM in the incoming directory
and leave it for next time, perhaps the KEYS file needs updating, or some human intervention
is involved. Perhaps the script can moan on an irc channel, or send an email.
>
> - We're done.
>
> Does this sound like a workflow people could live with?
>
> To me, it looks suitably low tech, end users sign an RPM in the normal way and check
it into an "incoming" directory tree and at that point the automated script takes over. The
ASF yum repository signing key doesn't need to sit on a server anywhere, it can sit on whatever
VM is being used to do the signing. All we need is a) a suitable VM to run this, somewhere,
b) an ASF yum repository signing key, and c) the script.
>


OK, can we make bigtop the pilot -assuming the fallback is still "if the 
pilot fails the beta can still ship with  a signed announcement 
containing the SHA1 checksums of the files" -which it is should be
doing anyway for the sake of completeness.

What do we need to do here then?

1. Collect the keys of everyone who is (or soon plans to be) the RMs for 
Bigtop; that's currently Roman Shaposhnik, unless there are other 
volunteers.

Roman has keys in the server signed by various ASF people;
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x13971DA39475BD5D

I'll verify w/ Paolo Castanga that he did the signing; he drops his 
child off in my street for school regularly, so an F2F signing is trivial.

2. submit this list to -someone- to make it the normative "who can 
release RPMs to the release dir"

3. Try a pre-release run through to verify that that this works; don't 
mirror this run; just check that the chained auth works.

4. In the march release, Roman follows the same process, this time the 
files get mirrored out.

One more thing, what should be the process for verifying the artifacts?

The most rigorous would be for a staging place for the RPMs, and 1+ 
person does an install from the staging repo, with only the ASF key on 
their trust list. A CentOS VM can do this with ease.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message