upvote

points

by yetanotherjosh12 hours ago |
comments
upvoteby sheept6 hours ago|
next
[-]
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...

reply
upvoteby sozforex4 hours ago|
parent|
[-]
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.
reply
upvoteby edelbitter7 hours ago|
prev|
next
[-]
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.

reply
upvoteby cedws4 hours ago|
prev|
next
[-]
Because GitHub only cares about AI.
reply
upvoteby eviks3 hours ago|
parent|
[-]
And maintaining high level of service availability!
reply
upvoteby rvz1 hours ago|
parent|
[-]
With zero down time!
reply
upvoteby ZeWaka12 hours ago|
prev|
[-]
they probably used the publish token in a pull-request-target workflow or something?
reply
upvoteby ghost_pepper11 hours ago|
parent|
[-]
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
reply
upvoteby riknos31410 hours ago|
parent|
next
[-]
> 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.

reply
upvoteby hombre_fatal5 minutes ago|
parent|
[-]
"pull_request_target" vs "pull_request" is also bad naming. At least give it a dangerous name, else people will weigh them equally and use whichever they tried first and it seemed to work.
reply
upvoteby qudat8 hours ago|
parent|
prev|
[-]
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.

reply