You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@texera.apache.org by PJ Fanning <fa...@apache.org> on 2026/10/01 14:41:55 UTC
signing key used for create-release-candidate.yml
Hi,
Can this key and its history be explained?
https://github.com/apache/texera/blob/98d3d4b1ec8b02f611801d035c190fa31f56fa47/.github/workflows/create-release-candidate.yml#L231
The usual is that the release manager signs on hardware they control.
Here it appears that an individual committer's private key and
passphrase are stored in GitHub secrets, and any workflow run with
access to those secrets could sign with them. The ASF release-signing
policy (https://infra.apache.org/release-signing.html#automated-release-signing)
allows CI signing only after Infra approves it, and it then expects a
project key that Infra manages, not a committer's personal key.
These ASF Infra KEYS will not have an individual's name assigned to them.
Apache Pekko's CI Signing Key (public part) appears in
https://downloads.apache.org/pekko/KEYS - as a reference.
Unless the secrets.GPG_PRIVATE_KEY was provided by ASF Infra then it
appears that you are in violation of ASF policies.
Thanks,
PJ
Re: signing key used for create-release-candidate.yml
Posted by PJ Fanning <fa...@apache.org>.
Scratch that. It appears that adding repository secrets appears to be allowed at
the moment.
This may or not be an oversight.
On 2026/10/01 20:12:50 PJ Fanning wrote:
> I'm puzzled by how you could even add Repository secrets.
> Only ASF Infra team can do that - at least, that is how most ASF GitHub repos
> are configured.
>
>
> On 2026/10/01 18:51:48 Meng Wang wrote:
> > For point 3 in Xuan's plan, we started a discussion about the
> > reproducible-build requirement for automated signing:
> >
> > https://github.com/apache/texera/discussions/8807
> >
> > We also opened an INFRA ticket for the managed signing key:
> >
> > https://issues.apache.org/jira/browse/INFRA-28480
> >
> > We will first determine whether our release build can satisfy the
> > requirements for automated signing. If not, we can continue signing
> > releases locally on release-manager-controlled hardware instead
> >
> > On Thu, Oct 1, 2026 at 10:02 AM Ian Maxon <im...@apache.org> wrote:
> >
> > > Nice catch PJ, thanks for pointing this out. Part of this is my fault,
> > > I did look at the release scripts back for 1.1.0 and raised some
> > > issues but I didn't notice this one. I am not familiar with running
> > > releases and other things in GHA or otherwise automating them. In
> > > AsterixDB it's done the old way that I recall ASF requiring, which was
> > > that all release build and signing take place on developer-owned
> > > hardware. I had seen other projects do GitHub releases and just sort
> > > of assumed somehow this had been relaxed, and didn't look closely
> > > enough at the details of how specifically that is allowed. Now that I
> > > have read the release signing doc closely, it makes more sense now. I
> > > had initially found it puzzling how automated signing and all that
> > > would work, credibly. Having there be a separate, infra owned key, and
> > > requiring that the build be bit-for-bit reproducible places the
> > > missing pieces in that puzzle, for me at least.
> > >
> > > On Thu, Oct 1, 2026 at 9:48 AM Xuan Gu <xu...@apache.org> wrote:
> > > >
> > > > Hi PJ,
> > > >
> > > > Thank you for raising this.
> > > >
> > > > We had been using automated release signing incorrectly. The release
> > > workflow, added in #4076 (
> > > https://urldefense.com/v3/__https://github.com/apache/texera/pull/4076__;!!CzAuKJ42GuquVTTmVmPViYEvSg!Mr0kGtjnuP0_8KOQBrmdDLV92nCmclBEnRiMUbyZXgbSiaBjsdMWiVQvtP4kNXjtBf4_mBBVLrDnVdmg$
> > > ), signed artifacts in CI using the release manager's personal key stored
> > > in GitHub Secrets. After carefully reviewing the release signing guide at
> > > https://urldefense.com/v3/__https://infra.apache.org/release-signing.html__;!!CzAuKJ42GuquVTTmVmPViYEvSg!Mr0kGtjnuP0_8KOQBrmdDLV92nCmclBEnRiMUbyZXgbSiaBjsdMWiVQvtP4kNXjtBf4_mBBVLizjYGAn$
> > > , we now have a better understanding of the requirements for automated
> > > release signing.
> > > >
> > > > Our plan to address the issue is:
> > > > 1. Stop using personal keys in CI. We are removing the private key and
> > > passphrase from GitHub Secrets and removing the signing step from the
> > > workflow. We will also review the other credentials used by the same
> > > workflow.
> > > > 2. Sign artifacts locally for now. The 1.2.1 RC1 vote has been
> > > cancelled, and RC2 will be signed by the release manager on hardware they
> > > control.
> > > > 3. Request an Infra-managed signing key and Security Team approval,
> > > together with a process to reproduce and validate the artifacts on trusted
> > > hardware before release. We will only return to CI signing once that
> > > process is in place.
> > > >
> > > > Please let us know if any additional action is needed regarding the
> > > releases that have already been published.
> > > >
> > > > Thanks,
> > > > Xuan
> > > >
> > > > On 2026-10-01 14:41 UTC PJ Fanning wrote:
> > > > > Hi,
> > > > > Can this key and its history be explained?
> > > > >
> > > > >
> > > https://urldefense.com/v3/__https://github.com/apache/texera/blob/98d3d4b1ec8b02f611801d035c190fa31f56fa47/.github/workflows/create-release-candidate.yml*L231__;Iw!!CzAuKJ42GuquVTTmVmPViYEvSg!Mr0kGtjnuP0_8KOQBrmdDLV92nCmclBEnRiMUbyZXgbSiaBjsdMWiVQvtP4kNXjtBf4_mBBVLrBhfPB5$
> > > > >
> > > > > The usual is that the release manager signs on hardware they control.
> > > > > Here it appears that an individual committer's private key and
> > > > > passphrase are stored in GitHub secrets, and any workflow run with
> > > > > access to those secrets could sign with them. The ASF release-signing
> > > > > policy (
> > > https://urldefense.com/v3/__https://infra.apache.org/release-signing.html*automated-release-signing__;Iw!!CzAuKJ42GuquVTTmVmPViYEvSg!Mr0kGtjnuP0_8KOQBrmdDLV92nCmclBEnRiMUbyZXgbSiaBjsdMWiVQvtP4kNXjtBf4_mBBVLkad-T-h$
> > > )
> > > > > allows CI signing only after Infra approves it, and it then expects a
> > > > > project key that Infra manages, not a committer's personal key.
> > > > >
> > > > > These ASF Infra KEYS will not have an individual's name assigned to
> > > them.
> > > > >
> > > > > Apache Pekko's CI Signing Key (public part) appears in
> > > > >
> > > https://urldefense.com/v3/__https://downloads.apache.org/pekko/KEYS__;!!CzAuKJ42GuquVTTmVmPViYEvSg!Mr0kGtjnuP0_8KOQBrmdDLV92nCmclBEnRiMUbyZXgbSiaBjsdMWiVQvtP4kNXjtBf4_mBBVLjyg9RhT$
> > > - as a reference.
> > > > >
> > > > > Unless the secrets.GPG_PRIVATE_KEY was provided by ASF Infra then it
> > > > > appears that you are in violation of ASF policies.
> > > > >
> > > > > Thanks,
> > > > > PJ
> > > > >
> > >
> >
>
Re: signing key used for create-release-candidate.yml
Posted by PJ Fanning <fa...@apache.org>.
I'm puzzled by how you could even add Repository secrets.
Only ASF Infra team can do that - at least, that is how most ASF GitHub repos
are configured.
On 2026/10/01 18:51:48 Meng Wang wrote:
> For point 3 in Xuan's plan, we started a discussion about the
> reproducible-build requirement for automated signing:
>
> https://github.com/apache/texera/discussions/8807
>
> We also opened an INFRA ticket for the managed signing key:
>
> https://issues.apache.org/jira/browse/INFRA-28480
>
> We will first determine whether our release build can satisfy the
> requirements for automated signing. If not, we can continue signing
> releases locally on release-manager-controlled hardware instead
>
> On Thu, Oct 1, 2026 at 10:02 AM Ian Maxon <im...@apache.org> wrote:
>
> > Nice catch PJ, thanks for pointing this out. Part of this is my fault,
> > I did look at the release scripts back for 1.1.0 and raised some
> > issues but I didn't notice this one. I am not familiar with running
> > releases and other things in GHA or otherwise automating them. In
> > AsterixDB it's done the old way that I recall ASF requiring, which was
> > that all release build and signing take place on developer-owned
> > hardware. I had seen other projects do GitHub releases and just sort
> > of assumed somehow this had been relaxed, and didn't look closely
> > enough at the details of how specifically that is allowed. Now that I
> > have read the release signing doc closely, it makes more sense now. I
> > had initially found it puzzling how automated signing and all that
> > would work, credibly. Having there be a separate, infra owned key, and
> > requiring that the build be bit-for-bit reproducible places the
> > missing pieces in that puzzle, for me at least.
> >
> > On Thu, Oct 1, 2026 at 9:48 AM Xuan Gu <xu...@apache.org> wrote:
> > >
> > > Hi PJ,
> > >
> > > Thank you for raising this.
> > >
> > > We had been using automated release signing incorrectly. The release
> > workflow, added in #4076 (
> > https://urldefense.com/v3/__https://github.com/apache/texera/pull/4076__;!!CzAuKJ42GuquVTTmVmPViYEvSg!Mr0kGtjnuP0_8KOQBrmdDLV92nCmclBEnRiMUbyZXgbSiaBjsdMWiVQvtP4kNXjtBf4_mBBVLrDnVdmg$
> > ), signed artifacts in CI using the release manager's personal key stored
> > in GitHub Secrets. After carefully reviewing the release signing guide at
> > https://urldefense.com/v3/__https://infra.apache.org/release-signing.html__;!!CzAuKJ42GuquVTTmVmPViYEvSg!Mr0kGtjnuP0_8KOQBrmdDLV92nCmclBEnRiMUbyZXgbSiaBjsdMWiVQvtP4kNXjtBf4_mBBVLizjYGAn$
> > , we now have a better understanding of the requirements for automated
> > release signing.
> > >
> > > Our plan to address the issue is:
> > > 1. Stop using personal keys in CI. We are removing the private key and
> > passphrase from GitHub Secrets and removing the signing step from the
> > workflow. We will also review the other credentials used by the same
> > workflow.
> > > 2. Sign artifacts locally for now. The 1.2.1 RC1 vote has been
> > cancelled, and RC2 will be signed by the release manager on hardware they
> > control.
> > > 3. Request an Infra-managed signing key and Security Team approval,
> > together with a process to reproduce and validate the artifacts on trusted
> > hardware before release. We will only return to CI signing once that
> > process is in place.
> > >
> > > Please let us know if any additional action is needed regarding the
> > releases that have already been published.
> > >
> > > Thanks,
> > > Xuan
> > >
> > > On 2026-10-01 14:41 UTC PJ Fanning wrote:
> > > > Hi,
> > > > Can this key and its history be explained?
> > > >
> > > >
> > https://urldefense.com/v3/__https://github.com/apache/texera/blob/98d3d4b1ec8b02f611801d035c190fa31f56fa47/.github/workflows/create-release-candidate.yml*L231__;Iw!!CzAuKJ42GuquVTTmVmPViYEvSg!Mr0kGtjnuP0_8KOQBrmdDLV92nCmclBEnRiMUbyZXgbSiaBjsdMWiVQvtP4kNXjtBf4_mBBVLrBhfPB5$
> > > >
> > > > The usual is that the release manager signs on hardware they control.
> > > > Here it appears that an individual committer's private key and
> > > > passphrase are stored in GitHub secrets, and any workflow run with
> > > > access to those secrets could sign with them. The ASF release-signing
> > > > policy (
> > https://urldefense.com/v3/__https://infra.apache.org/release-signing.html*automated-release-signing__;Iw!!CzAuKJ42GuquVTTmVmPViYEvSg!Mr0kGtjnuP0_8KOQBrmdDLV92nCmclBEnRiMUbyZXgbSiaBjsdMWiVQvtP4kNXjtBf4_mBBVLkad-T-h$
> > )
> > > > allows CI signing only after Infra approves it, and it then expects a
> > > > project key that Infra manages, not a committer's personal key.
> > > >
> > > > These ASF Infra KEYS will not have an individual's name assigned to
> > them.
> > > >
> > > > Apache Pekko's CI Signing Key (public part) appears in
> > > >
> > https://urldefense.com/v3/__https://downloads.apache.org/pekko/KEYS__;!!CzAuKJ42GuquVTTmVmPViYEvSg!Mr0kGtjnuP0_8KOQBrmdDLV92nCmclBEnRiMUbyZXgbSiaBjsdMWiVQvtP4kNXjtBf4_mBBVLjyg9RhT$
> > - as a reference.
> > > >
> > > > Unless the secrets.GPG_PRIVATE_KEY was provided by ASF Infra then it
> > > > appears that you are in violation of ASF policies.
> > > >
> > > > Thanks,
> > > > PJ
> > > >
> >
>
Re: signing key used for create-release-candidate.yml
Posted by Meng Wang <me...@uci.edu>.
For point 3 in Xuan's plan, we started a discussion about the
reproducible-build requirement for automated signing:
https://github.com/apache/texera/discussions/8807
We also opened an INFRA ticket for the managed signing key:
https://issues.apache.org/jira/browse/INFRA-28480
We will first determine whether our release build can satisfy the
requirements for automated signing. If not, we can continue signing
releases locally on release-manager-controlled hardware instead
On Thu, Oct 1, 2026 at 10:02 AM Ian Maxon <im...@apache.org> wrote:
> Nice catch PJ, thanks for pointing this out. Part of this is my fault,
> I did look at the release scripts back for 1.1.0 and raised some
> issues but I didn't notice this one. I am not familiar with running
> releases and other things in GHA or otherwise automating them. In
> AsterixDB it's done the old way that I recall ASF requiring, which was
> that all release build and signing take place on developer-owned
> hardware. I had seen other projects do GitHub releases and just sort
> of assumed somehow this had been relaxed, and didn't look closely
> enough at the details of how specifically that is allowed. Now that I
> have read the release signing doc closely, it makes more sense now. I
> had initially found it puzzling how automated signing and all that
> would work, credibly. Having there be a separate, infra owned key, and
> requiring that the build be bit-for-bit reproducible places the
> missing pieces in that puzzle, for me at least.
>
> On Thu, Oct 1, 2026 at 9:48 AM Xuan Gu <xu...@apache.org> wrote:
> >
> > Hi PJ,
> >
> > Thank you for raising this.
> >
> > We had been using automated release signing incorrectly. The release
> workflow, added in #4076 (
> https://urldefense.com/v3/__https://github.com/apache/texera/pull/4076__;!!CzAuKJ42GuquVTTmVmPViYEvSg!Mr0kGtjnuP0_8KOQBrmdDLV92nCmclBEnRiMUbyZXgbSiaBjsdMWiVQvtP4kNXjtBf4_mBBVLrDnVdmg$
> ), signed artifacts in CI using the release manager's personal key stored
> in GitHub Secrets. After carefully reviewing the release signing guide at
> https://urldefense.com/v3/__https://infra.apache.org/release-signing.html__;!!CzAuKJ42GuquVTTmVmPViYEvSg!Mr0kGtjnuP0_8KOQBrmdDLV92nCmclBEnRiMUbyZXgbSiaBjsdMWiVQvtP4kNXjtBf4_mBBVLizjYGAn$
> , we now have a better understanding of the requirements for automated
> release signing.
> >
> > Our plan to address the issue is:
> > 1. Stop using personal keys in CI. We are removing the private key and
> passphrase from GitHub Secrets and removing the signing step from the
> workflow. We will also review the other credentials used by the same
> workflow.
> > 2. Sign artifacts locally for now. The 1.2.1 RC1 vote has been
> cancelled, and RC2 will be signed by the release manager on hardware they
> control.
> > 3. Request an Infra-managed signing key and Security Team approval,
> together with a process to reproduce and validate the artifacts on trusted
> hardware before release. We will only return to CI signing once that
> process is in place.
> >
> > Please let us know if any additional action is needed regarding the
> releases that have already been published.
> >
> > Thanks,
> > Xuan
> >
> > On 2026-10-01 14:41 UTC PJ Fanning wrote:
> > > Hi,
> > > Can this key and its history be explained?
> > >
> > >
> https://urldefense.com/v3/__https://github.com/apache/texera/blob/98d3d4b1ec8b02f611801d035c190fa31f56fa47/.github/workflows/create-release-candidate.yml*L231__;Iw!!CzAuKJ42GuquVTTmVmPViYEvSg!Mr0kGtjnuP0_8KOQBrmdDLV92nCmclBEnRiMUbyZXgbSiaBjsdMWiVQvtP4kNXjtBf4_mBBVLrBhfPB5$
> > >
> > > The usual is that the release manager signs on hardware they control.
> > > Here it appears that an individual committer's private key and
> > > passphrase are stored in GitHub secrets, and any workflow run with
> > > access to those secrets could sign with them. The ASF release-signing
> > > policy (
> https://urldefense.com/v3/__https://infra.apache.org/release-signing.html*automated-release-signing__;Iw!!CzAuKJ42GuquVTTmVmPViYEvSg!Mr0kGtjnuP0_8KOQBrmdDLV92nCmclBEnRiMUbyZXgbSiaBjsdMWiVQvtP4kNXjtBf4_mBBVLkad-T-h$
> )
> > > allows CI signing only after Infra approves it, and it then expects a
> > > project key that Infra manages, not a committer's personal key.
> > >
> > > These ASF Infra KEYS will not have an individual's name assigned to
> them.
> > >
> > > Apache Pekko's CI Signing Key (public part) appears in
> > >
> https://urldefense.com/v3/__https://downloads.apache.org/pekko/KEYS__;!!CzAuKJ42GuquVTTmVmPViYEvSg!Mr0kGtjnuP0_8KOQBrmdDLV92nCmclBEnRiMUbyZXgbSiaBjsdMWiVQvtP4kNXjtBf4_mBBVLjyg9RhT$
> - as a reference.
> > >
> > > Unless the secrets.GPG_PRIVATE_KEY was provided by ASF Infra then it
> > > appears that you are in violation of ASF policies.
> > >
> > > Thanks,
> > > PJ
> > >
>
Re: signing key used for create-release-candidate.yml
Posted by Ian Maxon <im...@apache.org>.
Nice catch PJ, thanks for pointing this out. Part of this is my fault,
I did look at the release scripts back for 1.1.0 and raised some
issues but I didn't notice this one. I am not familiar with running
releases and other things in GHA or otherwise automating them. In
AsterixDB it's done the old way that I recall ASF requiring, which was
that all release build and signing take place on developer-owned
hardware. I had seen other projects do GitHub releases and just sort
of assumed somehow this had been relaxed, and didn't look closely
enough at the details of how specifically that is allowed. Now that I
have read the release signing doc closely, it makes more sense now. I
had initially found it puzzling how automated signing and all that
would work, credibly. Having there be a separate, infra owned key, and
requiring that the build be bit-for-bit reproducible places the
missing pieces in that puzzle, for me at least.
On Thu, Oct 1, 2026 at 9:48 AM Xuan Gu <xu...@apache.org> wrote:
>
> Hi PJ,
>
> Thank you for raising this.
>
> We had been using automated release signing incorrectly. The release workflow, added in #4076 (https://github.com/apache/texera/pull/4076), signed artifacts in CI using the release manager's personal key stored in GitHub Secrets. After carefully reviewing the release signing guide at https://infra.apache.org/release-signing.html, we now have a better understanding of the requirements for automated release signing.
>
> Our plan to address the issue is:
> 1. Stop using personal keys in CI. We are removing the private key and passphrase from GitHub Secrets and removing the signing step from the workflow. We will also review the other credentials used by the same workflow.
> 2. Sign artifacts locally for now. The 1.2.1 RC1 vote has been cancelled, and RC2 will be signed by the release manager on hardware they control.
> 3. Request an Infra-managed signing key and Security Team approval, together with a process to reproduce and validate the artifacts on trusted hardware before release. We will only return to CI signing once that process is in place.
>
> Please let us know if any additional action is needed regarding the releases that have already been published.
>
> Thanks,
> Xuan
>
> On 2026-10-01 14:41 UTC PJ Fanning wrote:
> > Hi,
> > Can this key and its history be explained?
> >
> > https://github.com/apache/texera/blob/98d3d4b1ec8b02f611801d035c190fa31f56fa47/.github/workflows/create-release-candidate.yml#L231
> >
> > The usual is that the release manager signs on hardware they control.
> > Here it appears that an individual committer's private key and
> > passphrase are stored in GitHub secrets, and any workflow run with
> > access to those secrets could sign with them. The ASF release-signing
> > policy (https://infra.apache.org/release-signing.html#automated-release-signing)
> > allows CI signing only after Infra approves it, and it then expects a
> > project key that Infra manages, not a committer's personal key.
> >
> > These ASF Infra KEYS will not have an individual's name assigned to them.
> >
> > Apache Pekko's CI Signing Key (public part) appears in
> > https://downloads.apache.org/pekko/KEYS - as a reference.
> >
> > Unless the secrets.GPG_PRIVATE_KEY was provided by ASF Infra then it
> > appears that you are in violation of ASF policies.
> >
> > Thanks,
> > PJ
> >
Re: signing key used for create-release-candidate.yml
Posted by Xuan Gu <xu...@apache.org>.
Hi PJ,
Thank you for raising this.
We had been using automated release signing incorrectly. The release workflow, added in #4076 (https://github.com/apache/texera/pull/4076), signed artifacts in CI using the release manager's personal key stored in GitHub Secrets. After carefully reviewing the release signing guide at https://infra.apache.org/release-signing.html, we now have a better understanding of the requirements for automated release signing.
Our plan to address the issue is:
1. Stop using personal keys in CI. We are removing the private key and passphrase from GitHub Secrets and removing the signing step from the workflow. We will also review the other credentials used by the same workflow.
2. Sign artifacts locally for now. The 1.2.1 RC1 vote has been cancelled, and RC2 will be signed by the release manager on hardware they control.
3. Request an Infra-managed signing key and Security Team approval, together with a process to reproduce and validate the artifacts on trusted hardware before release. We will only return to CI signing once that process is in place.
Please let us know if any additional action is needed regarding the releases that have already been published.
Thanks,
Xuan
On 2026-10-01 14:41 UTC PJ Fanning wrote:
> Hi,
> Can this key and its history be explained?
>
> https://github.com/apache/texera/blob/98d3d4b1ec8b02f611801d035c190fa31f56fa47/.github/workflows/create-release-candidate.yml#L231
>
> The usual is that the release manager signs on hardware they control.
> Here it appears that an individual committer's private key and
> passphrase are stored in GitHub secrets, and any workflow run with
> access to those secrets could sign with them. The ASF release-signing
> policy (https://infra.apache.org/release-signing.html#automated-release-signing)
> allows CI signing only after Infra approves it, and it then expects a
> project key that Infra manages, not a committer's personal key.
>
> These ASF Infra KEYS will not have an individual's name assigned to them.
>
> Apache Pekko's CI Signing Key (public part) appears in
> https://downloads.apache.org/pekko/KEYS - as a reference.
>
> Unless the secrets.GPG_PRIVATE_KEY was provided by ASF Infra then it
> appears that you are in violation of ASF policies.
>
> Thanks,
> PJ
>