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
> 

Reply via email to