+1. Thanks for coming up with a solution, everyone! I think the manually signed RC as a work around will work well, and it will be an improvement for the rest to be updated.
On Mon, Sep 18, 2017 at 8:25 PM, Patrick Wendell <patr...@databricks.com> wrote: > 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 >> > > -- Ryan Blue Software Engineer Netflix
