Earlier quoted context omitted.
If you published a key, you must assume someone copied it and that deleting references to it is not sufficient. You must rotate that key now, and should check whether it was used improperly. This is pretty basic incident response. The thing about exposing commits that were only ever in a private repo is pretty indefensible, but not garbage collecting public commits on delete shouldn't matter.
> If you published a key Why would anyone think that a private fork is "published"!? This is the footgun here: The UI is telling you that nobody can see the secrets you committed to your private copy , but actually it is widely accessible. A similar example of UI-vs-reality mismatch that I've noticed recently is the Azure Store Account "public" visibility. By default, it uses your authenticated account for RBAC acces…
Anyone can access deleted and private repository data on GitHub
231–240 of 394 posts
Re: Anyone can access deleted and private repository data on GitHub
#232Re: Anyone can access deleted and private repository data on GitHub
#233Earlier quoted context omitted.
If you published a key, you must assume someone copied it and that deleting references to it is not sufficient. You must rotate that key now, and should check whether it was used improperly. This is pretty basic incident response. The thing about exposing commits that were only ever in a private repo is pretty indefensible, but not garbage collecting public commits on delete shouldn't matter.
> If you published a key Why would anyone think that a private fork is "published"!? This is the footgun here: The UI is telling you that nobody can see the secrets you committed to your private copy , but actually it is widely accessible. A similar example of UI-vs-reality mismatch that I've noticed recently is the Azure Store Account "public" visibility. By default, it uses your authenticated account for RBAC acces…
1. Public "forks" are just namespaced branches that share an underlying repo
2. They don't run the garbage collector all the time
I'd be surprised if those weren't true.
Like I said, the behavior with private forks sounds indefensible.
The OP is mixing together multiple things. Being able to access deleted public data isn't that surprising and definitely isn't a security issue as far as leaking keys is concerned (it was already public. Assume it has been cloned). Being able to access private forks is a footgun/issue. They should be garbage collecting as part of public repo creation so that unreferenced commits from private forks aren't included.
Re: Anyone can access deleted and private repository data on GitHub
#234Re: Anyone can access deleted and private repository data on GitHub
#2351. If a URL would be in the “[t]his commit does not belong to any branch of this repository, and may belong to a fork outside of the repository” and that URL uses a shortened commit hash, return 404 instead. Assuming no information leakage via timing, this would make semi-brute-force probing via short hashes much harder.
GitHub is clearly already doing the hard work for this.
2. A commit that was never public should not become public unless it is referenced in a public repository.
This would require storing more state.
Re: Anyone can access deleted and private repository data on GitHub
#236Earlier quoted context omitted.
The problem with this line of argument is that the fundamental workings of git are also surprising to people, such that they routinely attempt to address mistaken hazmat commits by simple reverts. If at bottom this whole story is just that git is treacherous, well, yeah, but not news. There's a deeper problem here, which is that making the UX on hosting sites less surprising doesn't fix the underlying problem. There…
Is "git" relevant here? Forking isn't a git concept, and none of this behaviour has much to do with git; it's all GitHub. Also, you can revoke an API key, but you can't revoke a company-proprietary algorithm that you implemented into a fork of a public project.
I supposed the branding and UI for it could be a counter argument, but then again Github allows regular branch creation / committing / merging in their UI. Their main value add (not downplaying it—it's huge) on top of git (besides ancillary things like CI / linters) is the ability to comment on a branch's diff, i.e. a PR Review.
Re: Anyone can access deleted and private repository data on GitHub
#237Re: Anyone can access deleted and private repository data on GitHub
#238I 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…
My conclusion would be: don’t use GitHub.
Re: Anyone can access deleted and private repository data on GitHub
#239Re: Anyone can access deleted and private repository data on GitHub
#240Earlier quoted context omitted.
No but I think attention should still be raised to it in the hopes they will fix it. The squeaky wheel gets the grease. https://xkcd.com/1053
First step would be to have them acknowledge a documented behavior which was part of their original design 16 years ago, is something that needs to be fixed. As someone who has used git and GitHub extensively over that time, none of what the author documented was a surprise to me. However, I also remember when people were trained to do a "Save As" when preparing a final Word document or Powerpoint for sharing with a…