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 <[email protected]> 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 <[email protected]> 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 > > > >
