This is a very worthy article.
I have an impression that I've read it before 2024, but maybe that was a different article describing the same mess with how github exposes private repos.
If git in general would enforce pretending to not know about orphans, it would always need to know what you were meaning to consider the boundary, and/or you would end up waiting for useless duplicate network traffic. The fact that on GitHub, such references are visible irrespective of specified repo is not a bug, its a feature. Its the tools (including but not limited to: GitHub Actions) that cause dangerous misunderstanding in appearing to let you specify something they then never actually enforce.
intended meaning: use this hash if and only if it is accessible from the default branch of that repo
actual meaning: use this hash. start looking at this location. I do not care whether it is accessible through that location by accident, by intent of merely its uploader, or by explicit and persisting intent of someone with write access to the location.
yes, they used pull_request_target for a benchmarking suite. github has a huge warning saying to never use pull_request_target to run user code, but this is just going to keep happening
> github has a huge warning saying to never use pull_request_target to run user code
This is an area where documentation is necessary but not sufficient. Github needs to add some form of automated screening mechanism to either prevent this usage, or at the very least quickly flag usages that might be dangerous.
"pull_request_target" vs "pull_request" is also bad naming. At least give it a dangerous name so people know there's a dangerous quirk to it when reading their config.
[0]: https://trufflesecurity.com/blog/anyone-can-access-deleted-a...