www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Signing jars
Date Thu, 08 Sep 2011 19:48:11 GMT

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.   :-)


On Thursday, September 08, 2011 10:41:32 AM Dennis E. Hamilton wrote:
> Hmm, I think the issue is that certain signatures are handled by the various
> platforms and so there can be an issue about how the signature is
> considered trusted and the signing verified.  I don't know how it works for
> jars, but Microsoft Authenticode signings (is that still the name?) is
> recognized and handled by the platform and applications (such as the
> browser) that have trust controls on signed material.
> A committer's signature is not quite the same thing as a signature with the
> Foundation behind it.
> If that is the only signing, it would definitely appear to be backwards.
> There are general considerations about authenticating material (allegedly)
> downloaded from a publicly-avaialable Apache site (or trusted mirror) that
> make this a wider conversation.  I desist [;<).
> If release candidates are deployable, configurable elements that can be
> installed on computers, sequestering them until release is approved is a
> good idea.  That or don't sign them or don't sign them in a way that has
> them be confused with releases.  This will raise trust warnings on some
> platforms, and that is probably a good thing in that scenario.
>  - Dennis
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Thursday, September 08, 2011 07:46
> To: infrastructure-dev@apache.org
> Subject: Re: Signing jars
> On 3 September 2011 19:05, Sander Temme <sctemme@apache.org> wrote:
> > On Sep 2, 2011, at 2:40 AM, William A. Rowe Jr. wrote:
> >> On 9/2/2011 7:34 AM, Benson Margulies wrote:
> >>> 3) The signing daemon wakes up and notices new jars in the
> >>> directory.
> >>> It makes copies in a nearby directory, signs them, and checks them
> >>> in.
> >>> 
> >>> 5) I stage the whole thing for a release vote.
> >> 
> >> I believe this is backwards.
> >> 
> >> The 'signing tool' should only sign releases.
> > 
> > Yes.  If you sign candidates, they become indistinguishable from real
> > releases.
> However, that's what we do with detached GPG sigs.
> The sigs are produced as part of the release candidate, and checked as
> part of the release voting.
> If the vote succeeds, then the candidate files are published,
> otherwise the files are deleted.
> However, anyone following the developer lists can take a copy of the
> RC and publish it on their own website.
> It's quite difficult to distinguish the files from the actual release,
> because we don't generally publish any corroborating details on the
> ASF download pages. [1]
> So why are we trying to be more careful with the embedded sigs?
> What is it about such sigs that makes it important not to sign the
> release candidates?
> If we allow RC signing, then most if not all of the issues disappear.
> [1] AIUI In the case of httpd and Tomcat, failed RCs never get
> released - the next RC gets a new version - so this offers some
> protection, as the ASF website only mentions proper releases.
> > S.
Daniel Kulp
Talend - http://www.talend.com

View raw message