Mailing-List: contact infrastructure-dev-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: infrastructure-dev@apache.org
Received-SPF: pass (nike.apache.org: domain of bimargulies@gmail.com
 designates 209.85.213.178 as permitted sender)
References: 
 <CALhtWkdNUc5dFkAu8T82hy-7dQ8OK75fObtyPVszHXv5_9BifQ@mail.gmail.com>
 <CAOGo0VYreHcmqKnjQhQLDQthD0rGOGr2bTpK0aWUB1s3HJp_=Q@mail.gmail.com>
 <010d01cc6e4e$8cc384f0$a64a8ed0$@acm.org>
 <1439461.d19pAP07g8@dilbert.dankulp.com>
From: Benson Margulies <bimargulies@gmail.com>
In-Reply-To: <1439461.d19pAP07g8@dilbert.dankulp.com>
Mime-Version: 1.0 (iPhone Mail 8L1)
Date: Thu, 8 Sep 2011 16:19:07 -0400
Message-ID: <3329741425779036418@unknownmsgid>
Subject: Re: Signing jars
To: "infrastructure-dev@apache.org" <infrastructure-dev@apache.org>
Content-Type: text/plain; charset=UTF-8

any of us could write the plugin.

the problem is that the eclipse p2 metadata has to be created (or.
poked) post-signature.

On Sep 8, 2011, at 3:48 PM, Daniel Kulp <dkulp@apache.org> wrote:

>
>
> 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
>
>
>
> 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
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com