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. >> @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).
