+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
