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 >>>> >>>
