they probably used the publish token in a pull-request-target workflow or something?

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.

And a labeling action which requires `pull_request_target`: https://github.com/actions/labeler#create-workflow

These types of features are not worth it and need to be removed from the marketplace.

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.

specified: repo location, slightly-difficult-to-preimage hash

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.

In some cases, you can also use forks to read commits from private forks[0], but GitHub considers these linked commit networks working as intended.

[0]: https://trufflesecurity.com/blog/anyone-can-access-deleted-a...

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.

Because GitHub only cares about AI.

And maintaining high level of service availability!

With zero down time!