To Robert: Good point. I didn't click through. There's always the possibility that the two branches of the foundation disagree. In this case INFRA-23996 seems to have the needed authorities.
To Danny: Fabulous. My preference would be the policy be updated so that this is clearly within policy but I'll just poke at that in parallel. I'm comfortable with it. I'm not aware of the threat model that the policy is based on so I have to assume it is just so people can confirm they got the artifact we intended them to get, even if maven or ASF artifact servers are compromised. This does change the attack surface both for better and for worse, but it doesn't cause any inherent contradiction that I can see. Kenn On Wed, May 3, 2023 at 12:34 PM Danny McCormick <dannymccorm...@google.com> wrote: > This approach has the approval of the Apache VP of security - > https://issues.apache.org/jira/browse/INFRA-23996 - and Infra seems > comfortable with it if we have consensus (I have a thread going on this > topic here - https://issues.apache.org/jira/browse/INFRA-24520). @Kenneth > Knowles <k...@google.com> assuming Apache doesn't have objections with > this approach, are you comfortable with this? > > On Wed, May 3, 2023 at 3:28 PM Robert Burke <rob...@frantil.com> wrote: > >> 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 >>>>>>>> >>>>>>>
