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 Twitter: https://twitter.com/holdenkarau
