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 17:41:32 GMT
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.


Mime
View raw message