www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: Signing jars
Date Thu, 08 Sep 2011 20:41:07 GMT
Daniel, I think that scenario satisfies chain of custody issues (because the final signer is
attesting that the candidate signatures were verified and trusted) and deals with the authority
being Apache rather than individual committers.  That should satisfy all authentication requirements
for the release.

 - Dennis

-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org] 
Sent: Thursday, September 08, 2011 12:48
To: infrastructure-dev@apache.org
Subject: Re: Signing jars



I honestly keep thinking that this is something we might be able to engage 
Sonatype to write a Nexus plugin to handle, at least for the maven based 
projects.  (and who really cares about the rest.... ;-)   )

Basically, the projects do the releases exactly like they do today.   gpg 
signed jars uploaded to Nexus staging area.  The staging area is closed (at 
which point the gpg sigs are verified and such by Nexus) and the vote called.   
If the vote fails, drop the staging area and restart.  If the vote passes, you 
click on the "Release" button in Nexus.

At this point, Nexus would package all the jars up ALONG with their asc files 
and ship them off to the signing server (via SVN or a webservice or whatever).   
The signing server would verify the gpgs as well (and maybe make sure the keys 
are in an approved list or in the Apache web of trust or something) and then 
sign the jars.   It would ALSO sign the new jars with a new ASF gpg key and 
pass the jars and new asc files back to Nexus which would then deploy them.

Maybe I'm just dreaming, but that would be very low impact for the release 
managers.   :-)

Dan



[ ... ]

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com


Mime
View raw message