If this is acceptable per the release policy, huge +1 to automating this step (and not limited to java artifacts alone).
On Wed, May 3, 2023 at 1:14 PM Kenneth Knowles <k...@apache.org> wrote: > > 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 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) using GitHub >>>>>>>>> Actions. >>>>>>>>> >>>>>>>>> To do this, we can follow the guide here 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 after 72 hours. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Danny
