71–80 of 394 posts
> Any commits made to your private fork after you make the “upstream” repository public are not viewable.
Does that mean a private repo that has never been or will be public isn’t accessible? That scenario wasn’t mentioned.
Microsoft: It's the EUs fault! Also Microsoft: It's a feature!
I reported this on their HackerOne many years ago (2018 it seems) and they said it was working as intended. Conclusion: don't use private forks. Copy the repository instead. Here is their full response from back then: > Thanks for the submission! We have reviewed your report and validated your findings. After internally assessing the finding we have determined it is a known low risk issue. We may make this functional…
What does "private fork" mean in this context? I created a fork of a project by cloning it to my own machine and set origin to an empty private repository on GitHub. I manually merge upstream changes on my machine. Is my repository accessible?
What I don't know is if in 3 months you DO set your remote origin to that fork to for instance, pull upstream patches into your private repo, you're still not pushing, only pulling, so I would THINK they'd still never get your changes, but I don't know if git does some sort of log sync when you do a pull as well.
Maybe that would wind up having the commit hash available.
I reported this on their HackerOne many years ago (2018 it seems) and they said it was working as intended. Conclusion: don't use private forks. Copy the repository instead. Here is their full response from back then: > Thanks for the submission! We have reviewed your report and validated your findings. After internally assessing the finding we have determined it is a known low risk issue. We may make this functional…
What does "private fork" mean in this context? I created a fork of a project by cloning it to my own machine and set origin to an empty private repository on GitHub. I manually merge upstream changes on my machine. Is my repository accessible?
Earlier quoted context omitted.
Not defending GH here (their position is indefensible imo) but, as the article notes, they document these behaviors clearly and publicly: https://docs.github.com/en/pull-requests/collaborating-with-... I don't think they're being underhanded exactly... they're just making a terrible decision. Quoting from the article: > The average user views the separation of private and public repositories as a security boundary, a…
Based on some (admittedly not very thorough) search, this documentation was posted in 2021, three years after my report.
>This is such an enormous attack vector for all organizations that use GitHub that we’re introducing a new term: Cross Fork Object Reference (CFOR) Have we stopped naming vulnerabilities cute and fuzzy names and started inventing class names instead? Does this have a logo? Has this issue been identified anywhere else?
chatgpt: Create a logo image of a fork impaling a small gnome named "code"
Surprised at the comments minimizing this. I've used github for a long time, would not have expected these results, and was unnerved by them. I'd recommend reading the article yourself. It does a good job explaining the vulnerabilities.
For the first two, git is based on content addressable storage, so it makes sense that anything that is ever public will never disappear. I can sympathize with someone who gets bit by it, as it might not have occurred to them, but it’s part of the model. The third strikes me as counter-intuitive and hard to reason about. P.S. If you publish your keys or access tokens for well known services to GitHub and you are prom…
this isn't quite right
content addressable storage is just a mean of access it does
- not imply content cannot be deleted
- not imply content cannot be access managed
you could apply this to a git repo itself (like making some branches private and some not) but more important forks are not git ops, they are more high level github ops and could very well have appropriate measurements to make sure this cannot happen
e.g. if github had implemented forks like a `git clone` _non of this vulnerabilities would have been a thing_
similar implemented different access rights for different subsets of fork networks (or even the same git repo) technically isn't a problem either (not trivial but quite doable)
and I mean commits made to private repositories being public is always a security vulnerability no matter how much github claims it's intended
The biggest gotcha here is probably that if you start of with a private repo and a private fork, making the repo public also makes the fork "public". GitHub may very well say that this is working as intended, but if it truly is then you should be forced to make both the repo and fork public at the same time. Essentially "Making repo R public will make the following forks public as well 'My Fork', 'Super secret fork',…