Live data from Hacker News

Anyone can access deleted and private repository data on GitHub

trufflesecurity.com

231–240 of 394 posts

Re: Anyone can access deleted and private repository data on GitHub

#231

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…

Putting keys in repos should not be done, full stop. Even if GitHub forks weren’t public, their _private_ repos could one day be compromised. Instead, store keys in a shared vault, .gitignore the .env and have a .env.example with empty keys.

Re: Anyone can access deleted and private repository data on GitHub

#232
post #205
post #191

Earlier quoted context omitted.

Do some companies intend for their platform to feature remote code execution?

Remote code execution is literally a feature of GitHub…

Sandboxed code execution is a bit different than RCE.

Re: Anyone can access deleted and private repository data on GitHub

#233

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…

The bit you quoted is referring to public forks that were deleted. That sounds like a non-issue to me, and I'm not at all surprised that

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

#235
ISTM there’s a straightforward mitigation or two available to GitHub:

1. 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

#236
post #139

Earlier 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.

aside: I think it's questionable to say that forking isn't a git concept. it's just a branch on a different upstream. Those two upstreams could simply be two different folders on your machine, or shared server.

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

#238
post #4

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…

> Conclusion: don't use private forks. Copy the repository instead.

My conclusion would be: don’t use GitHub.

Re: Anyone can access deleted and private repository data on GitHub

#240
post #210

Earlier 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…

What about Save As bit people?
Post reply on HN