Thanks for the reminder :) On Tue, Sep 19, 2017 at 9:02 AM Luciano Resende <luckbr1...@gmail.com> wrote:
> 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/ > -- Twitter: https://twitter.com/holdenkarau
