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://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 > >
