publish-package-repository: environment secrets resolve empty at v0.1.17

[jmgilman]

Summary

publish-package-repository.yml reads its aggregate signing and R2 credentials from the packages-production environment:

    environment: packages-production
...
          gpg-private-key: ${{ secrets.PACKAGE_REPOSITORY_GPG_PRIVATE_KEY }}
          gpg-passphrase: ${{ secrets.PACKAGE_REPOSITORY_GPG_PASSPHRASE }}
          apk-private-key: ${{ secrets.PACKAGE_REPOSITORY_APK_PRIVATE_KEY }}

In a new adopter organization at v0.1.17 those expressions resolve to empty strings, and every publication fails at setup-package-repository with:

Error: GPG_PASSPHRASE is empty

The same three values resolve correctly in a non-reusable job in the same repository that selects the same environment, so the stored secrets are fine. Something about the reusable-workflow path is not receiving environment secrets.

Evidence

Adopter: componere/pkgs, receiver pinned to 0dee66ff6c4cc7e28d7bb65e97a37d701e0eff4a (v0.1.17), environment packages-production holding all five secrets, required reviewer, deployment_branch_policy: {protected_branches: true, custom_branch_policies: false}.

1. The secrets are correct at rest. A temporary direct job in the same repository, selecting the same environment, printing only lengths:

gpg_passphrase_len=32
gpg_private_key_len=4756
apk_private_key_len=4324
r2_key_id_len=32

2. Three receiver runs, same failure, with GPG_PRIVATE_KEY, GPG_PASSPHRASE, and APK_PRIVATE_KEY all empty in the action's env group:

• repository_dispatch from the producer release, with secrets: inherit
• workflow_dispatch with secrets: inherit removed, matching the documented caller in operate-a-native-package-repository.md
• workflow_dispatch with secrets: inherit restored and a dummy repository-level secret added, to rule out an entirely empty inherited secret set

3. secrets: inherit is load-bearing but not sufficient. The documented caller template omits it, but meigma/pkgs commit 3193b8a5 is titled "fix(release): inherit publication secrets", so that repository hit the same failure and fixed it by adding secrets: inherit. Adding it here did not help.

4. The only difference from a working caller is the pinned SHA. componere/pkgs/.github/workflows/publish.yml and meigma/pkgs/.github/workflows/publish.yml differ by exactly one line:

-    uses: meigma/release/.github/workflows/publish-package-repository.yml@583937edadfbae183e49f16df46b98e0b36807ba # v0.1.16
+    uses: meigma/release/.github/workflows/publish-package-repository.yml@0dee66ff6c4cc7e28d7bb65e97a37d701e0eff4a # v0.1.17

meigma/pkgs published successfully at v0.1.16 today. Yet git diff v0.1.16 v0.1.17 -- .github/workflows/publish-package-repository.yml .github/actions/setup-package-repository/ is empty — those files are byte-identical between the two tags, and both declare environment: packages-production and read the same secret names.

Two possible causes, which I cannot separate from outside

1. A v0.1.17 regression somewhere in the release unit outside those two files that changes how the receiver job is composed.
2. A GitHub platform change to environment-secret resolution in reusable workflows, landing between meigma's 04:22Z success and componere's 17:30Z failure.

meigma/pkgs has a repository_dispatch run from 15:59Z still waiting for approval. Approving it settles this: if it fails identically at v0.1.16, cause 2; if it succeeds, cause 1.

Why this matters for adopters

This is the last step of the documented onboarding path, and it fails after the producer release is already public — the producer's GitHub Release, image, cask, and manifest all published successfully first. The only workaround I can see is moving the aggregate keys to repository-level secrets so secrets: inherit delivers them, which contradicts the guide's stated boundary that "aggregate private keys stay in the central protected environment."

Suggested changes

1. Determine which cause applies, and if it is a regression, fix it and yank or document v0.1.17 for the package-repository path.
2. Either way, make setup-package-repository fail with a message that names the likely cause. GPG_PASSPHRASE is empty reads as "the operator forgot to set a secret," which sent me to re-set correct secrets twice before I probed resolution directly.
3. Consider having the receiver assert all five environment values up front and report which are empty together, rather than failing on the first one.
4. State explicitly in operate-a-native-package-repository.md whether secrets: inherit is required in the caller. The template omits it and meigma/pkgs needs it; adopters currently have to guess.

[jmgilman]

Cause isolated: this is cross-organization, not a v0.1.17 regression

I pinned componere/pkgs temporarily to v0.1.16 — the exact SHA that meigma/pkgs published with successfully at 04:22Z today — and it fails identically:

GPG_PRIVATE_KEY:
GPG_PASSPHRASE:
APK_PRIVATE_KEY:
Error: GPG_PASSPHRASE is empty

Run: componere/pkgs actions run 32588946064. The pin is reverted.

So both candidate causes in the original report are wrong. The receiver files are identical between the two tags, and both tags fail here while one succeeds there. The distinguishing factor is the only remaining difference between the two callers:

Caller	Callee	Same org?	Environment secrets
meigma/pkgs	meigma/release	yes	delivered
componere/pkgs	meigma/release	no	empty

meigma/pkgs calling meigma/release is intra-organization. componere/pkgs calling meigma/release is cross-organization. GitHub does not surface the caller's environment secrets to a reusable workflow owned by a different organization; only secrets that cross the boundary explicitly — passed by name, or via secrets: inherit from the caller's repository and organization scopes — arrive.

Everything I observed fits: the same environment secrets resolve correctly in a direct job in componere/pkgs (gpg_passphrase_len=32, gpg_private_key_len=4756, apk_private_key_len=4324), secrets: inherit is necessary but insufficient because the values are not in a scope that inherit can reach, and the receiver's own files are irrelevant.

Why this is a real gap rather than an adopter mistake

#63 shipped cross-organization support and the release-system docs now describe adopters in their own organizations calling meigma/release. But publish-package-repository.yml reads its aggregate signing keys and R2 credentials from secrets.* while declaring environment: packages-production, which only works when the caller happens to be in the same organization as this repository. Every cross-organization adopter following operate-a-native-package-repository.md will hit this at the last step of onboarding, after their producer release is already public.

The guide's stated boundary — "Keep aggregate private keys only in the central protected environment" — is not achievable cross-organization with the current receiver.

Suggested fix

Declare the credentials as reusable-workflow secrets so they cross the boundary explicitly:

on:
  workflow_call:
    secrets:
      package-repository-gpg-private-key:
        required: true
      package-repository-gpg-passphrase:
        required: true
      package-repository-apk-private-key:
        required: true
      r2-access-key-id:
        required: true
      r2-secret-access-key:
        required: true

The caller then maps them from its own environment. That requires the caller job to select the environment, which a uses: job cannot do, so the documented caller would need the two-job shape: one job with environment: packages-production that has the secrets, calling the reusable workflow with explicit secrets: mappings. Alternatively keep environment: in the callee and document that cross-organization adopters must hold these five values as repository or organization secrets, and state the resulting trust trade-off plainly.

Either way, please also make the failure name the real cause. GPG_PASSPHRASE is empty sent me to re-set correct secrets twice before I probed resolution directly; something like "no aggregate signing credentials were received — cross-organization callers must pass them explicitly" would have saved the entire investigation.

[jmgilman]

Resolved for componere with a local receiver; suggesting this as the supported cross-org shape

The fix that preserves the trust model turned out to need no fork and no secret relocation. setup-release-cli and setup-package-repository already support being referenced as owner/repo/path@ref, so the central repository can run the receiver's steps as a local workflow whose job selects packages-production itself. Environment secrets then resolve natively — same-repo job, no cross-org reusable-workflow boundary — and the aggregate keys stay environment-only, exactly as operate-a-native-package-repository.md requires.

Working example: componere/pkgs/.github/workflows/publish.yml. It mirrors publish-package-repository.yml at 0dee66ff… step for step, with both setup actions pinned to the same release-unit SHA. One behavioral difference: local-build: always is intra-repo-only (action_repository must equal workflow_repository), so the local caller uses the default acquisition mode and downloads the stamped v0.1.17 release-cli from this repository's release, checksum- and attestation-verified — arguably a stronger provenance story than building from source on the runner.

First publication through it succeeded end to end:

{"command":"publish package-repository","ok":true,
 "result":{"state":"published","repository":"componere/incusos-builder","tag":"v0.2.0",
           "artifacts":36,"uploaded":36}}

and all three repositories verified from real clients — apt-get install on Debian (signed-by the aggregate key), dnf install on Fedora with gpgcheck=1 + repo_gpgcheck=1 against both the aggregate and producer keys, and apk add on Alpine with both published keys in /etc/apk/keys.

Suggested upstream change

Rather than fixing the reusable receiver (which cannot reach a cross-org caller's environment secrets no matter what it declares), ship the local shape:

1. Add release-cli init package-repository, emitting this workflow the same way init homebrew-tap and init scoop-bucket emit their scaffolds — pinned to the CLI's stamped source commit, so the pin cannot drift from the CLI that generated it.
2. Update operate-a-native-package-repository.md to make the generated local workflow the documented receiver for cross-organization adopters, and note that the reusable publish-package-repository.yml remains correct only when the central repository lives in the same organization as this one.
3. Keep the maintenance caveat visible: a local receiver must be re-diffed against the upstream receiver when the release unit is bumped. The init scaffold makes that a regenerate instead of a hand-diff.