www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Signing jars
Date Thu, 08 Sep 2011 14:45:51 GMT
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