www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Deboy <scott.de...@gmail.com>
Subject Re: Official code signing certificate
Date Sun, 24 Jun 2012 01:36:31 GMT
I think we have a bigger process issue here than I first thought:

 - My take is that Infra strongly prefers to build the artifacts they are
responsible for signing
 - The signing process affects the final binaries (metadata files added to
jars, the signing process being a part of the Windows build process
apparently)
 - As someone responsible for reviewing releases, I would prefer to
validate the final (signed) artifacts, since hashes change due to the
signing process affecting the binaries
 - I don't think Infra wants to be pulled in every time a release candidate
is requested

I'm not sure how to reconcile those last two issues.  Thoughts?

Scott

On Sat, Jun 23, 2012 at 2:33 PM, William A Rowe Jr <wrowe@rowe-clan.net>wrote:

> No.  That is the nature of the beast, the validation code doesn't
> understand nested certs.  MS's fault.  Not the CA.
>
> If we had a root cert... but the flippant nature of this dialog suggests
> that even the nature of a foundation wide cert is not being respected.  It
> is in no way comparable to individual pgp keys.
>
> And to the second point, I suggest not.
>
> If we now have 5-7 projects looking for code signing, I'd suggest it is
> time for Sam as VP infra, or his delegate, to re-approach the Symantec team
> and find out the terms and conditions on their code signing service and the
> cost.  Have a couple infra team members act as admins.  As I may be signing
> objects I would prefer not to also be an admin, but would serve if pressed.
>
> You gain a login.  There is some level of client automation that could
> simplify things.  You submit bits.  They come back with unique certs.
>  Admin or the user can revoke a sig later discovered to be viral/bugged/not
> released.
>
> Integration to Maven may be possible.
>
> Reinventing the wheel seems foolish.  This would be an external service
> with minimal infra requirements.
>
>
>
>
>
> Sent from my Verizon Wireless Droid
>
>
> -----Original message-----
> From: Scott Deboy <scott.deboy@gmail.com>
> To: infrastructure-dev@apache.org
> Sent: Sat, Jun 23, 2012 19:12:00 GMT+00:00
> Subject: Re: Official code signing certificate
>
> Will root CAs allow a single organization to request different code signing
> certificates for their different groups in the organization?
>
> If this were possible, I'm not sure how much this affects the workflow, but
> it might.  I also might reduce the exposure mentioned by Sam.
>
> If we agree we need code signing certificates, but disagree on the workflow
> for getting artifacts signed, I would suggest we can move forward with the
> process of requesting the code signing certificates themselves, and in the
> process get an answer to the question as to whether or not PMC-level code
> signing certificates are an option.
>
> Logging Services needs a Java code signing certificate.
>
> Scott
>
> On Sat, Jun 23, 2012 at 11:39 AM, Rob Weir <robweir@apache.org> wrote:
>
>  On Sat, Jun 23, 2012 at 12:33 PM, Sam Ruby <rubys@intertwingly.net>
>> wrote:
>> > On Sat, Jun 23, 2012 at 11:34 AM, Rob Weir <robweir@apache.org> wrote:
>> >>
>> >> OK.  I agree that this would be much harder for Infra to do code
>> >> signing than it would be for the PMC's to do this.
>> >
>> > I'll note that I said nothing of the sort.
>> >
>> > To recap: any and all requests for the ASF infrastructure team to
>> > provide a web service to sign an arbitrary binary on behalf of the ASF
>> > will be rejected.  Instead, projects are encouraged to design a
>> > process by which [P]PMCs can request a build of an specified tag from
>> > source with the expectation that the outcome will be a signed binary
>> > that the project can evaluate and chose to release.
>> >
>>
>> Great.  Thanks for being so definitive on that.
>>
>> As we all know the PMC's are the ones that already build releases,
>> review releases, vote on releases, sign releases, support users with
>> the releases and maintain the releases.    So there is some synergy to
>> having what amounts merely to a different signing technology devolve
>> to the project level as well, where the release diligence already
>> occurs.  But out of an abundance of caution  I thought it was
>> important that we checked with Infra first.  That being done, no
>> further questions from me.
>>
>> Thanks again for your time.
>>
>> -Rob
>>
>> > - Sam Ruby
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message