I think this needs to be fixed. It's true that there are barriers to
publication, but the signature is what we use to authenticate Apache
releases.

If Patrick's key is available on Jenkins for any Spark committer to use,
then the chance of a compromise are much higher than for a normal RM key.

rb

On Fri, Sep 15, 2017 at 12:34 PM, Sean Owen <so...@cloudera.com> wrote:

> Yeah I had meant to ask about that in the past. While I presume Patrick
> consents to this and all that, it does mean that anyone with access to said
> Jenkins scripts can create a signed Spark release, regardless of who they
> are.
>
> I haven't thought through whether that's a theoretical issue we can ignore
> or something we need to fix up. For example you can't get a release on the
> ASF mirrors without more authentication.
>
> How hard would it be to make the script take in a key? it sort of looks
> like the script already takes GPG_KEY, but don't know how to modify the
> jobs. I suppose it would be ideal, in any event, for the actual release
> manager to sign.
>
> On Fri, Sep 15, 2017 at 8:28 PM Holden Karau <hol...@pigscanfly.ca> wrote:
>
>> That's a good question, I built the release candidate however the Jenkins
>> scripts don't take a parameter for configuring who signs them rather it
>> always signs them with Patrick's key. You can see this from previous
>> releases which were managed by other folks but still signed by Patrick.
>>
>> On Fri, Sep 15, 2017 at 12:16 PM, Ryan Blue <rb...@netflix.com> wrote:
>>
>>> The signature is valid, but why was the release signed with Patrick
>>> Wendell's private key? Did Patrick build the release candidate?
>>>
>>


-- 
Ryan Blue
Software Engineer
Netflix

Reply via email to