To clarify: I am in favor of automating what we can. There may be flexibility here in that only the source release needs to be signed in this way. But I expect this reduces the utility of the automation, as the release manager will still have to have a functioning published GPG key. Actually it might be clever for us to add this to the committer onboarding steps. You can also automatically sign your git commits with it, if you like.
Kenn On Wed, May 3, 2023 at 12:20 PM Kenneth Knowles <k...@apache.org> wrote: > I don't think we can do this. Having the release signed by the actual > release manager is by design. > > https://www.apache.org/legal/release-policy.html#release-signing > > "All supplied packages MUST be cryptographically signed by the Release > Manager with a detached signature" > > Kenn > > On Wed, May 3, 2023 at 12:14 PM John Casey via dev <dev@beam.apache.org> > wrote: > >> +1 to this as well. >> >> On Wed, May 3, 2023 at 3:10 PM Robert Burke <rob...@frantil.com> wrote: >> >>> +1 to simplifying release processes, since it leads to a more consistent >>> experience. >>> >>> If we continue to reduce release overhead we'll be able to react with >>> more agility when CVEs come a knocking. >>> >>> On Wed, May 3, 2023, 12:08 PM Jack McCluskey via dev < >>> dev@beam.apache.org> wrote: >>> >>>> +1 to automating release signing. As it stands now, this step requires >>>> a PMC member to add a new release manager's GPG key which can add time to >>>> getting a release started. This also results in the public key used to sign >>>> each release changing from one version to the next, as different release >>>> managers have different keys. Making releases easier to perform and >>>> providing a standard signing key for each release both seem like wins here. >>>> >>>> On Wed, May 3, 2023 at 2:40 PM Danny McCormick via dev < >>>> dev@beam.apache.org> wrote: >>>> >>>>> Hey everyone, I'm currently working on improving our release process >>>>> so that it's easier and faster for us to release. As part of this work, >>>>> I'd >>>>> like to propose automating our release signing step (the push java >>>>> artifacts step of build_release_candidate.sh >>>>> <https://beam.apache.org/contribute/release-guide/#run-build_release_candidatesh-to-create-a-release-candidate>) >>>>> using GitHub Actions. >>>>> >>>>> To do this, we can follow the guide here >>>>> <https://infra.apache.org/release-signing.html#automated-release-signing> >>>>> and >>>>> ask the Infra team to add a signing key that we can use to run the >>>>> workflow. Basically, the asks would be: >>>>> >>>>> 1) Add a signing key (and passphrase) as GH Actions Secrets so that we >>>>> can sign the artifacts. >>>>> 2) Allowlist a GitHub Action (crazy-max/ghaction-import-gpg) to use >>>>> the key to sign artifacts. >>>>> 3) Add an Apache token (name and password) as GH Actions Secrets so >>>>> that we can upload the signed artifacts to Nexus. >>>>> >>>>> Please let me know if you have any questions or concerns. If nobody >>>>> objects or raises more discussion points, I will assume lazy consensus >>>>> <https://community.apache.org/committers/lazyConsensus.html> after 72 >>>>> hours. >>>>> >>>>> Thanks, >>>>> Danny >>>>> >>>>
