The sad thing here is, Git's got a builtin check-ref-format command that rejects this on sight.

Posted Dec 10, 2024 7:54 UTC (Tue) by excors (subscriber, #95769)
In reply to: The sad thing here is, Git's got a builtin check-ref-format command that rejects this on sight. by jthill
Parent article: Abusing Git branch names to compromise a PyPI package

I think that's not correct. The only part of <that mess> check-ref-format objects to is the ":", but that's not actually part of the branch name. The GitHub pull request is displaying "repositoryname:branchname", and the branch name passed into ${{github.ref}} will be "refs/heads/$({curl,...)" which check-ref-format accepts.

(check-ref-format does reject spaces, which is presumably why the branch name uses ${IFS} instead. It also rejects ASCII control characters, '~', '^', '?', '*', '[', '..', '//', '@{', '\', etc, and says "These rules make it easy for shell script based tools to parse reference names, pathname expansion by the shell when a reference name is used unquoted (by mistake), and also avoid ambiguities in certain reference name expressions" [I think it meant to say "*avoid* pathname expansion"?]. But if it's meant to be safe when mistakenly used unquoted, why does it still allow '$'?)

The sad thing here is, Git's got a builtin check-ref-format command that rejects this on sight.

Posted Dec 10, 2024 9:24 UTC (Tue) by jthill (subscriber, #56558) [Link]

I see you're correct. Yow. That's painful. I've probably made this mistake myself then.

Unless I'm still blindspotting, $branchname expanded, quoted or not, still won't be expanded again unless rescanned, like the expansion being passed to bash -c or something instead of the var being passed in the environment for the invoked bash to expand just the once itself.