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 <[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 > > > > > > > > > > >
