Live data from Hacker News

Anyone can access deleted and private repository data on GitHub

trufflesecurity.com

381–390 of 394 posts

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

#381
post #348
post #158

Hubber here (same username on github.com). We in GitHub's OSPO have been working on an open source GitHub App to address the use case where organizations want to keep a private mirror of an upstream public fork so they can review code and remove IP/secrets/keys that get committed and squash history before any of those changes are made public. Getting a beta release this week, in fact - check it out, I'm curious what…

Looks like a promising tool and workflow to mitigate the risks we are discussing here. If you haven’t already done so, it might help the discussion here if you could highlight how this app deals with the issues outlined. Is the intent of the mirror repo creation that it’s more-or-less equivalent to “git clone —mirror”? I took a quick look at the code, and didn’t see a direct correspondence with “git clone —mirror” wh…

That's correct, it's doing a clone into an empty repo rather than using the fork API - code is here: https://github.com/github-community-projects/private-mirrors...

As it pertains to the post, since that private mirror is disconnected, none of the concerns about accessing deleted data apply.

The downside is that you don't get any of GitHub's performance and UI affordances from the fork network. But for the use case of private iterations on work headed for a public upstream, that's a trade-off that seems worth making.

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

#382

Earlier quoted context omitted.

Repeating myself: this almost certainly has nothing at all to do with the money they'd have to give you (I assure you, if there's even a whiff of legitimacy to your report, the people managing the bounty would probably strongly prefer to pay you just to get you off their backs) and everything to do with the warped incentives of paying out stuff like this. People forget that the whole point of a bug bounty is that the…

Yep that's the point I was making, they don't want to pay out on architecture/configuration changes if making those would be expensive/difficult. That doesn't mean the report isn't legitimate (being cluster-admin with no authentication is generally considered not to be a good security idea, in fact it's about as bad as it could get without putting the insecure port on the Internet), but that bug bounties aren't archi…

Yes. Bug bounties are not a panacea, and were never intended to be. They have specific goals, and those goals surprise technologists working outside of the security teams that run the programs. They make a lot more sense when you remind yourself that they (a) direct engineering efforts and (b) create profound incentives; those facts together sharply constrain the problems they can be applied to.

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

#383
post #284

Earlier quoted context omitted.

The property (“bug”) in question is an inherent and intentional property of meekly-tree type storage systems such as git. Calling this a bug is like reporting that telnet sends information unencrypted. The actual bug is in the way that their UX paradigm sets user expectations.

s/meekly/Merkle/g

lol. Someday autocorrect is going to take over my social media entirely.

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

#384

Earlier quoted context omitted.

Why not just create a new public repo and copy all of the source code that you want to it?

Because they haven't read the article and this HN discussion? "Why not just...". Once you already know something it can seem obvious.

What?

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

#385

Unrelated, but another interesting one is any non-admin contributors being able to add (and I believe update) secrets in a private repo for use in GH actions. It can’t be done via the UI, but can be done via the API or VSCode extension. When I looked into it a while back, apparently it is intended behavior, which just seems odd.

You're saying there's a github API that takes as an argument a secret, and creates a git commit containing that secret? I'm very surprised. Can you provide a reference to the API call?

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

#386

Clearly a POLA violation (principle of least astonishment)

So it using uncommon acronyms when you only referencing the thing once.

I found the post you're replying to helpful (and it made me laugh): I've come across the abbreviation POLA many times, with its non-jokey meaning "principle of least authority". I've also come across "principle of least astonishment" (Larry Wall or some other Perl contributor maybe?) but I'd never noticed that was (presumably?) a jokey reference to principle of least authority - I guess because I came across the joke first back was I was barely a programmer and I've never seen it abbreviated.

But maybe it never was a reference to POLA proper - "principle of least privilege" is more widespread I think, outside of the object capability community. And maybe "least astonishment" came first!

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

#387

Users should never be expected to know these gotchas for a feature called "private", documented or not. It's disappointing to see GitHub calling it a feature instead of a bug, to me it just shows a complete lack of care about security. Privacy features should _always_ have a strict, safe default. In the meantime I'll be calling "private" repos "unlisted", seems more appropriate

Yep, I see GitHub as "public only" hosting, and if I want to host something private, I will choose another vendor.

For the benefit of anybody thinking "with gitlab I'm safe from this": If you're saying (and perhaps you're not) that some other git hosting service

- gives you control over gc-ing their hosted remote?

- does not to your knowledge have a third-party public reflog or an events API or brute-forceable short hashes?

if so, especially the second of those seems a fragile assumption, because this is "just" the way git works (I'm not saying the consequences aren't easy to mentally gloss over). Even if gitlab lacks those things curently (but I think for example it does support short hashes), it's easy to imagine them showing up somehow retroactively.

If you're just agreeing with the grandparent post that github's naming ("private") is misleading or that the fork feature encourages this mistake: agreed.

Curious to know if any git hosting service does support gc-ing under user control.

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

#388

Unrelated, but another interesting one is any non-admin contributors being able to add (and I believe update) secrets in a private repo for use in GH actions. It can’t be done via the UI, but can be done via the API or VSCode extension. When I looked into it a while back, apparently it is intended behavior, which just seems odd.

You're saying there's a github API that takes as an argument a secret, and creates a git commit containing that secret? I'm very surprised. Can you provide a reference to the API call?

To clarify, it doesn’t create a commit and is only usable within actions. I have always used the GH action VSCode extension for it, but I believe from the API, you would call the below endpoint using a classic/non-fine grained PAT that has the “repo” grant.

https://docs.github.com/en/rest/actions/secrets?apiVersion=2....

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

#389

Earlier quoted context omitted.

Sometimes I wonder if all the security features GitHub slathers on top of `git` lull people into a false sense of security when fundamentally they're working in a fully distributed version control system with no centralized authority. If your key is leaked the solution is to invalidate the key not just synthetically alter your version of history to pretend it never happened.

Unless you specifically know and understand the ramifications of this GitHub idiosyncrasy, you have no way to tell that your key was possibly leaked. GitHub never informs you that someone accessed a commit created in your private fork.

Your key is leaked the moment you leak it.

It's thinking of posted-publicly-but-unclear-if-exploited as "possibly leaked" (rather than "definitely leaked") that's the problem here, not GitHub's totally reasonable stance.

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

#390
post #65

Earlier quoted context omitted.

> I'll be calling "private" repos "unlisted" The same for “deleted” repos.

"deleted" is just a fancy word "inaccessible to the user"

"Bought" is just a fancy word for "granted a license for usage, subject to terms and conditions, which may be revoked at any time, for any reason, without any warning"
Post reply on HN