Hi @puerco,
We allowlist carabiner-dev/actions/* on the Apache Software Foundation's GitHub org-wide allowlist for use in ASF projects (apache/infrastructure-actions). We have a workflow constraint here that I'd like to discuss, with two related asks.
Context
ASF's allowlist pins every approved action to its exact commit SHA. Because ampel/verify@v1.2.0 calls sibling sub-actions:
- uses: carabiner-dev/actions/install/ampel@2a11d59a135c5e291f305f249a92ad7903e3ee0f # v1.1.7
- uses: carabiner-dev/actions/install/bnd@2a11d59a135c5e291f305f249a92ad7903e3ee0f # v1.1.7
…each release of actions/ampel/verify requires us to also allowlist the previous version's SHA for the install/* siblings. This is a known GitHub limitation (sibling refs in composite actions can't resolve "self at the same commit"): https://github.com/orgs/community/discussions/26245#discussioncomment-15601440
The result is that every release of your action requires ASF to allowlist 2× SHAs per sibling involved, which scales poorly against our 1000-pattern org cap (we're at 332/1000 today). See discussion at apache/infrastructure-actions#831 and the tracking issue at apache/infrastructure-actions#852.
Asks
-
Enable immutable releases on this repository. GitHub's immutable releases feature prevents tags from being moved after publication, which makes a version tag as trustworthy as a SHA from a supply-chain perspective. Settings → General → "Immutable releases" (org-level or repo-level depending on your plan).
-
Pin sibling sub-action refs by tag rather than previous-version SHA. Once immutability is on, you could change:
- uses: carabiner-dev/actions/install/ampel@2a11d59a135c5e291f305f249a92ad7903e3ee0f # v1.1.7
to (at the v1.2.0 release):
- uses: carabiner-dev/actions/install/ampel@v1.2.0
This would let us allowlist one pattern per release rather than two, and would also be more readable for consumers reading your action source.
Why this matters to ASF
We have ~200 Apache projects consuming actions through this allowlist. Each extra pattern per release of every multi-sibling action ecosystem multiplies our maintenance and brings us closer to the cap. Immutable releases would benefit every downstream consumer that does SHA-pinning verification, not just ASF.
What we'll do on our side
If you adopt this, we'll update our verifier (gateway/gateway.py) to accept tag-pinning when the tag points to an immutable release, so the existing carabiner-dev/actions/* allowlist entries continue to work and future releases need fewer additions. That work is tracked at apache/infrastructure-actions#852.
Happy to discuss if there are constraints I'm missing — for example if you already considered immutable releases and have reasons not to enable them. Thanks for maintaining these actions, they're widely used in our supply-chain tooling.
Hi @puerco,
We allowlist
carabiner-dev/actions/*on the Apache Software Foundation's GitHub org-wide allowlist for use in ASF projects (apache/infrastructure-actions). We have a workflow constraint here that I'd like to discuss, with two related asks.Context
ASF's allowlist pins every approved action to its exact commit SHA. Because
ampel/verify@v1.2.0calls sibling sub-actions:…each release of
actions/ampel/verifyrequires us to also allowlist the previous version's SHA for theinstall/*siblings. This is a known GitHub limitation (sibling refs in composite actions can't resolve "self at the same commit"): https://github.com/orgs/community/discussions/26245#discussioncomment-15601440The result is that every release of your action requires ASF to allowlist 2× SHAs per sibling involved, which scales poorly against our 1000-pattern org cap (we're at 332/1000 today). See discussion at apache/infrastructure-actions#831 and the tracking issue at apache/infrastructure-actions#852.
Asks
Enable immutable releases on this repository. GitHub's immutable releases feature prevents tags from being moved after publication, which makes a version tag as trustworthy as a SHA from a supply-chain perspective. Settings → General → "Immutable releases" (org-level or repo-level depending on your plan).
Pin sibling sub-action refs by tag rather than previous-version SHA. Once immutability is on, you could change:
to (at the v1.2.0 release):
This would let us allowlist one pattern per release rather than two, and would also be more readable for consumers reading your action source.
Why this matters to ASF
We have ~200 Apache projects consuming actions through this allowlist. Each extra pattern per release of every multi-sibling action ecosystem multiplies our maintenance and brings us closer to the cap. Immutable releases would benefit every downstream consumer that does SHA-pinning verification, not just ASF.
What we'll do on our side
If you adopt this, we'll update our verifier (
gateway/gateway.py) to accept tag-pinning when the tag points to an immutable release, so the existingcarabiner-dev/actions/*allowlist entries continue to work and future releases need fewer additions. That work is tracked at apache/infrastructure-actions#852.Happy to discuss if there are constraints I'm missing — for example if you already considered immutable releases and have reasons not to enable them. Thanks for maintaining these actions, they're widely used in our supply-chain tooling.