i will detail how we control access to the jenkins infra tomorrow. we're pretty well locked down, but there is absolutely room for improvement.
this thread is also a good reminder that we (RMs + pwendell + ?) should audit who still has, but does not need direct (or special) access to jenkins. regarding the release pipeline and associated tooling, i wasn't involved much during the rollout of the current system. i'm all for a bit more involvement on my end, as well as better/moar documentation. also, tweaking the build/release process to allow individual RMs to inject their own keys is fine by me. shane On Fri, Sep 15, 2017 at 5:12 PM, Holden Karau <hol...@pigscanfly.ca> wrote: > Also continuing the discussion from the vote threads, Shane probably has the > best idea on the ACLs for Jenkins so I've CC'd him as well. > > > On Fri, Sep 15, 2017 at 5:09 PM Holden Karau <hol...@pigscanfly.ca> wrote: >> >> Changing the release jobs, beyond the available parameters, right now >> depends on Josh arisen as there are some scripts which generate the jobs >> which aren't public. I've done temporary fixes in the past with the Python >> packaging but my understanding is that in the medium term it requires access >> to the scripts. >> >> So +CC Josh. >> >> On Fri, Sep 15, 2017 at 4:38 PM Ryan Blue <rb...@netflix.com> wrote: >>> >>> 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 >> >> -- >> Twitter: https://twitter.com/holdenkarau > > -- > Twitter: https://twitter.com/holdenkarau --------------------------------------------------------------------- To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
