With this policy change, it seems like we could get really close to a release process that is just "choose a daily build that looked good". The main barrier being any place we bake the version into the artifacts.
On Wed, May 3, 2023 at 2:51 PM Robert Bradshaw via dev <dev@beam.apache.org> wrote: > 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 >
