On Fri, Mar 8, 2019 at 2:55 AM Robert Bradshaw <[email protected]> wrote:
> On Fri, Mar 8, 2019 at 2:42 AM Ahmet Altay <[email protected]> wrote: > > > > This sounds good to me. > > > > On Thu, Mar 7, 2019 at 3:32 PM Michael Luckey <[email protected]> > wrote: > >> > >> Thanks for your comments. > >> > >> So to continue here, I ll prepare a PR implementing C: > >> > >> Pass the sign key to the relevant scripts and use that for signing. > There is something similar already implemented [1] > >> > >> We might discuss on that, whether it will work for us or if we need to > implement something different. > >> > >> This should affect at least 'build_release_candidate.sh' and > 'sign_hash_python_wheels.sh'. The release manager is responsible for > selecting the proper key. Currently there is no 'state passed between the > scripts', so the release manager will have to specify this repeatedly. This > could probably be improved later on. > > > > This might become a problem. Is it possible for us to tackle this sooner > than later? > > Requiring a key seems to be a good first step. (Personally, I like to > be very explicit about what I sign.) Supporting defaults (e.g. in a > ~/.beam-release config file) is a nice to have. > +1 > > >> @Ahmet Altay Could you elaborate which global state you are referring > to? Is it only that git global configuration of the signing key? [2] > > > > I was referring to things not related to signing. I do not want to > digress this thread but briefly I was referring to global installations of > binaries with sudo and changes to bashrc file. We can work on those > improvements separately. > > That's really bad. +1 to fixing these (as a separate bug). > Filed https://issues.apache.org/jira/browse/BEAM-6795 with some additional information.
