Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
  b=xsmpDBPwECRzkoyKeq13lXJNuJn/vJTIK6b3gmcjz2vlSzGcaVBdyYIL1av76EKaBTuX5HmR3UWqFNby/4Z0Jnumwsm5WKf54B5mtcaRmbnjSmeUy/XXOfKCVes8leYGdAgTruPogX5Gq/33DSZCtcZbPMOKna6D72FPvKwtR6U=;
Date: Wed, 23 Apr 2008 07:21:06 -0700 (PDT)
From: Matt Benson <gudnabrsam@yahoo.com>
Subject: Re: [all] releases
To: Jakarta Commons Developers List <dev@commons.apache.org>
In-Reply-To: <35363F83-D37C-4887-9651-0C4975C7DAE4@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID: <400979.60629.qm@web55110.mail.re4.yahoo.com>


--- Torsten Curdt <tcurdt@apache.org> wrote:

> > Risks are mitigated to an arguably acceptable
> level by wrappering the
> > entire release process at Apache around the point
> to point secure
> > transport guarantee that signing is meant to
> provide.
> 
> That holds only true if you don't use mirrors and
> people get the  
> releases directly from us.
> 
> > I am generally hesitant to introduce any more
> overhead for folks to
> > step up to RM'ing releases than is strictly
> necessary, given that this
> > community needs a lot more of 'em.
> 
> I agree ...but as said. I am happy to step up and
> just do the signing  
> if that really is the bottleneck.
> 

How would that work logistically?  I publish RC
artifacts, and once they're voted on, you sign the
same artifacts that presumably you personally
reviewed?  Doesn't that necessarily force us -not- to
use the full mvn process?

> > The amount of security rigor applied that would
> cause an unsigned key
> > to be a blocking factor for signing releases would
> probably also
> > discount the above from being acceptable.
> 
> Why is that? I cannot follow that argument

I assumed he meant the fact that you would have to
inspect every artifact personally to be sure there was
no tampering (on my part or otherwise) as they got
from me to you, for instance.  Certainly no offense
was taken; I'm aware this is theoretical.  :)

> 
> > As one data point of the operational reality,
> there were several
> > artifacts released using my key which was unsigned
> for years until a
> > little over a week ago.
> 
> Not good. But now that your key is signed it
> retroactively validates  
> the releases. Actually with all the release
> nitpicking we do I am  
> surprised this hasn't been brought up - or got
> ignored ;)
> 
> Frankly speaking I think the signing is the least
> blocking part in our  
> release process. We have enough PMC members that
> have a cross signed  
> key.
> 
> > Finally, from reading Matt's email at the top of
> the thread I did get
> > the sense that he was keen on getting his key
> signed, so I didn't
> > stress that any further.
> 
> Let's get him signed :)

I have seen mentioned the idea of getting a signing
done without a F2F.  If anyone has ideas on how to
make this secure, I'm all ears.  Otherwise, how many
signatures are needed?  Or does it just depend on how
strongly trusted (how many signatures IT has)  a given
signature is?

-Matt

> 
> cheers
> --
> Torsten
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
> For additional commands, e-mail:
> dev-help@commons.apache.org
> 
> 


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org