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 <[email protected]> To: Graham Leggett <[email protected]> CC: Tony Stevenson <[email protected]>, Apache Infrastructure <[email protected]>, [email protected]
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.
