Manually signing seems a good compromise for now, but note that there are two places that this needs to happen, the artifacts that goes to dist.a.o as well as the ones that are published to maven.
On Tue, Sep 19, 2017 at 8:53 AM, Ryan Blue <rb...@netflix.com.invalid> wrote: > +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 > -- Luciano Resende http://twitter.com/lresende1975 http://lresende.blogspot.com/
