Sounds good - thanks Holden! On Mon, Sep 18, 2017 at 8:21 PM, Holden Karau <hol...@pigscanfly.ca> wrote:
> That sounds like a pretty good temporary work around if folks agree I'll > cancel release vote for 2.1.2 and work on getting an RC2 out later this > week manually signed. I've filed JIRA SPARK-22055 & SPARK-22054 to port the > release scripts and allow injecting of the RM's key. > > On Mon, Sep 18, 2017 at 8:11 PM, Patrick Wendell <patr...@databricks.com> > wrote: > >> For the current release - maybe Holden could just sign the artifacts with >> her own key manually, if this is a concern. I don't think that would >> require modifying the release pipeline, except to just remove/ignore the >> existing signatures. >> >> - Patrick >> >> On Mon, Sep 18, 2017 at 7:56 PM, Reynold Xin <r...@databricks.com> wrote: >> >>> Does anybody know whether this is a hard blocker? If it is not, we >>> should probably push 2.1.2 forward quickly and do the infrastructure >>> improvement in parallel. >>> >>> On Mon, Sep 18, 2017 at 7:49 PM, Holden Karau <hol...@pigscanfly.ca> >>> wrote: >>> >>>> I'm more than willing to help migrate the scripts as part of either >>>> this release or the next. >>>> >>>> It sounds like there is a consensus developing around changing the >>>> process -- should we hold off on the 2.1.2 release or roll this into the >>>> next one? >>>> >>>> On Mon, Sep 18, 2017 at 7:37 PM, Marcelo Vanzin <van...@cloudera.com> >>>> wrote: >>>> >>>>> +1 to this. There should be a script in the Spark repo that has all >>>>> the logic needed for a release. That script should take the RM's key >>>>> as a parameter. >>>>> >>>>> if there's a desire to keep the current Jenkins job to create the >>>>> release, it should be based on that script. But from what I'm seeing >>>>> there are currently too many unknowns in the release process. >>>>> >>>>> On Mon, Sep 18, 2017 at 4:55 PM, Ryan Blue <rb...@netflix.com.invalid> >>>>> wrote: >>>>> > I don't understand why it is necessary to share a release key. If >>>>> this is >>>>> > something that can be automated in a Jenkins job, then can it be a >>>>> script >>>>> > with a reasonable set of build requirements for Mac and Ubuntu? >>>>> That's the >>>>> > approach I've seen the most in other projects. >>>>> > >>>>> > I'm also not just concerned about release managers. Having a key >>>>> stored >>>>> > persistently on outside infrastructure adds the most risk, as >>>>> Luciano noted >>>>> > as well. We should also start publishing checksums in the Spark VOTE >>>>> thread, >>>>> > which are currently missing. The risk I'm concerned about is that if >>>>> the key >>>>> > were compromised, it would be possible to replace binaries with >>>>> perfectly >>>>> > valid ones, at least on some mirrors. If the Apache copy were >>>>> replaced, then >>>>> > we wouldn't even be able to catch that it had happened. Given the >>>>> high >>>>> > profile of Spark and the number of companies that run it, I think we >>>>> need to >>>>> > take extra care to make sure that can't happen, even if it is an >>>>> annoyance >>>>> > for the release managers. >>>>> >>>>> -- >>>>> Marcelo >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe e-mail: dev-unsubscr...@spark.apache.org >>>>> >>>>> >>>> >>>> >>>> -- >>>> Twitter: https://twitter.com/holdenkarau >>>> >>> >>> >> > > > -- > Cell : 425-233-8271 <(425)%20233-8271> > Twitter: https://twitter.com/holdenkarau >
