You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by Danny McCormick via dev <de...@beam.apache.org> on 2023/05/03 18:40:00 UTC
[Proposal] Automate Release Signing
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
Re: [Proposal] Automate Release Signing
Posted by Kenneth Knowles <ke...@apache.org>.
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 <de...@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 <ke...@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 <
> dannymccormick@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 <ro...@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 <ke...@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 <ke...@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 <ro...@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
>
Re: [Proposal] Automate Release Signing
Posted by Robert Bradshaw via dev <de...@beam.apache.org>.
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 <ke...@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 <da...@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 <ro...@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 <ke...@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 <ke...@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 <de...@beam.apache.org> wrote:
>>>>>>
>>>>>> +1 to this as well.
>>>>>>
>>>>>> On Wed, May 3, 2023 at 3:10 PM Robert Burke <ro...@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 <de...@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 <de...@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
Re: [Proposal] Automate Release Signing
Posted by Kenneth Knowles <ke...@apache.org>.
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 <da...@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 <kl...@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 <ro...@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 <ke...@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 <ke...@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 <de...@beam.apache.org>
>>>> wrote:
>>>>
>>>>> +1 to this as well.
>>>>>
>>>>> On Wed, May 3, 2023 at 3:10 PM Robert Burke <ro...@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
>>>>>>>>
>>>>>>>
Re: [Proposal] Automate Release Signing
Posted by Danny McCormick via dev <de...@beam.apache.org>.
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 <kl...@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 <ro...@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 <ke...@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 <ke...@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 <de...@beam.apache.org>
>>> wrote:
>>>
>>>> +1 to this as well.
>>>>
>>>> On Wed, May 3, 2023 at 3:10 PM Robert Burke <ro...@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
>>>>>>>
>>>>>>
Re: [Proposal] Automate Release Signing
Posted by Robert Burke <ro...@frantil.com>.
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 <ke...@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 <ke...@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 <de...@beam.apache.org>
>> wrote:
>>
>>> +1 to this as well.
>>>
>>> On Wed, May 3, 2023 at 3:10 PM Robert Burke <ro...@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
>>>>>>
>>>>>
Re: [Proposal] Automate Release Signing
Posted by Kenneth Knowles <ke...@apache.org>.
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 <ke...@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 <de...@beam.apache.org>
> wrote:
>
>> +1 to this as well.
>>
>> On Wed, May 3, 2023 at 3:10 PM Robert Burke <ro...@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
>>>>>
>>>>
Re: [Proposal] Automate Release Signing
Posted by Kenneth Knowles <ke...@apache.org>.
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 <de...@beam.apache.org>
wrote:
> +1 to this as well.
>
> On Wed, May 3, 2023 at 3:10 PM Robert Burke <ro...@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 <de...@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
>>>>
>>>
Re: [Proposal] Automate Release Signing
Posted by John Casey via dev <de...@beam.apache.org>.
+1 to this as well.
On Wed, May 3, 2023 at 3:10 PM Robert Burke <ro...@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 <de...@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
>>>
>>
Re: [Proposal] Automate Release Signing
Posted by Robert Burke <ro...@frantil.com>.
+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 <de...@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
>>
>
Re: [Proposal] Automate Release Signing
Posted by Jack McCluskey via dev <de...@beam.apache.org>.
+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 <de...@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
>