fix(actions): correct casing for owner identifier of approved rust-cache action - #1300
Conversation
…ache` action Signed-off-by: hainenber <dotronghai96@gmail.com>
potiuk
left a comment
potiuk
left a comment
There was a problem hiding this comment.
Confirmed the mechanism rather than just the description: check_asf_allowlist.py:156 matches with fnmatch.fnmatch, which applies os.path.normcase - identity on POSIX. On the Linux runners fnmatch("Swatinem/rust-cache@v2", "swatinem/rust-cache@*") is False, so the lowercase entry really did reject correctly-cased usage. The owner is Swatinem, and #950 is a real consumer hitting it (apache/sedona-spatialbench).
Touching only actions.yml is the complete fix, despite #950 naming approved_patterns.yml: that file carries # This file was generated from actions.yml by gateway/gateway.py. It will be regenerated and committed as part of various workflows. so actions.yml is the single source and the sync regenerates the rest.
On the follow-up you raise: worth doing, and the general form is to make the matching case-insensitive rather than to police the casing of every entry, since GitHub owner and repo identifiers resolve case-insensitively. Opened as #1304. Out of scope for this PR.
LGTM.
…1305) GitHub resolves owner and repository identifiers case-insensitively, so `uses: Swatinem/rust-cache@v2` and `uses: swatinem/rust-cache@v2` name the same action. fnmatch applies os.path.normcase, which is the identity on POSIX, so on the Linux runners an entry whose casing differed from what a consumer wrote rejected a legitimately approved action -- and said only that it was not on the allowlist, which is not what was actually wrong. apache/sedona-spatialbench hit exactly that (#950, entry fixed in #1300). Folds only the owner/repo half. Tags and SHAs are case-sensitive on GitHub, so folding the part after "@" would let an exactly-pinned entry match a ref it never approved; two precision tests pin that, along with one asserting the fold cannot make a different repo match. The trusted-owner check needed the same treatment: `Actions/checkout@v4` was not recognised as belonging to the `actions` owner. Generated-by: Claude Opus 5
2 participants
Closes #950
Not sure if there should be any follow-up acts to prevent similar cases, such as having a sample repo that utilizes all approved GHAs for E2E? :D