Kenn, I'll pose the question of why would Apache Infra have a supported path for artifact signing that apparently violates Apache policy?
On Wed, May 3, 2023, 12:24 PM Kenneth Knowles <k...@apache.org> wrote: > 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 >>>>>> >>>>>
