Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Anyone can access deleted and private repository data on GitHub

trufflesecurity.com

Post reply on HN
Print view View original

351–360 of 394 posts

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

#351

Post by dumbo-octopus »

8organicbits wrote: post #349
dumbo-octopus wrote: post #343

Earlier quoted context omitted.

Who said anything about that? We’re talking about side channels and eventual^TM deletion. Given enough time no information will remain anywhere, sure. But that’s not very relevant.

I think we are trying to define the word "delete". You found an archaic definition and are trying to use it in a modern technical setting. You've claimed that modern databases delete without actually removing data but haven't pointed to which systems you are talking about. I'm familiar with tombstoning, either as a "soft-delete" or as part of an eventual deletion process. But I've never seen that called deletion as t…

I used the first definition of delete I found which, while arguably “archaic”, matches the modern technical term almost exactly. We’d typically call that a well known word with a clear meaning.

And sure, the DELETE FROM statement in postgres - or any other standards compliment sql db I know.

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

#353

Post by HenryBemis »

andersa wrote: 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…

Imho there is an issue with the word "delete". Apparently for anyone who is hosting someone else's (private and/or sensitive and/or worthy) data is to hide it from view, but keep it around "just in case" or "because we can" or "what are you gonna do about it"?

I 'love' it when I see the words "hide", "archive", "remove", and other newspeak to avoid using the word "delete", since 'they' never actually delete (plus there are 1-2-5-10-forever years' of backups where your 'deleted' info can be retrieved relatively easy).

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

#354

Post by Perseids »

reisse wrote: post #303
pcthrowaway wrote: post #218

Earlier quoted context omitted.

OK but say a company has a private, closed source internal tool, and they want to open-source some part of it. They fork it and start working on cleaning up the history to make it publishable. After some changes which include deleting sensitive information and proprietary code, and squashing all the history to one commit, they change the repo to public. According to this article, any commit on either repo which was m…

> After some changes which include deleting sensitive information and proprietary code, and squashing all the history to one commit, they change the repo to public. I know this might look like a valid approach on the first glance but... it is stupid for anyone who knows how git or GitHub API works? Remote (GitHub's) reflog is not GC'd immediately, you can try to get commit hashes from events history via API, and then…

> it is stupid for anyone who knows how git or GitHub API works?

You need to know how git works and GitHub's API. I would say I have a pretty good understanding about how (local) git works internally, but was deeply surprised about GitHub's brute-forceable short commit IDs and the existence of a public log of all reflog activity [1].

When the article said "You might think you’re protected by needing to know the commit hash. You’re not. The hash is discoverable. More on that later." I was not able to deduce what would come later. Meanwhile, data access by hash seemed like a non-issue to me – how would you compute the hash without having the data in the first place? Checking that a certain file exists in a private branch might be an information disclosure, but gi not usually problematic.

And in any case, GitHub has grown so far away from its roots as a simple git hoster that implicit expectations change as well. If I self-host my git repository, my mental model is very close to git internals. If I use GitHub's web interface to click myself a repository with complex access rights, I assume they have concepts in place to thoroughly enforce these access rights. I mean, GitHub organizations are not a git concept.

[1] https://www.gharchive.org/

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

#355

Post by 8organicbits »

dumbo-octopus wrote: post #351
8organicbits wrote: post #349

Earlier quoted context omitted.

I think we are trying to define the word "delete". You found an archaic definition and are trying to use it in a modern technical setting. You've claimed that modern databases delete without actually removing data but haven't pointed to which systems you are talking about. I'm familiar with tombstoning, either as a "soft-delete" or as part of an eventual deletion process. But I've never seen that called deletion as t…

I used the first definition of delete I found which, while arguably “archaic”, matches the modern technical term almost exactly. We’d typically call that a well known word with a clear meaning. And sure, the DELETE FROM statement in postgres - or any other standards compliment sql db I know.

In technical writing you often don't want to use the dictionary for definitions, similar to how words in a contract can have unexpected meaning in a legal setting.

For Postgres you've got to consider vacuum. Auto vacuum is enabled by default. Deleted rows are removed unless you go out of your way to make it do something different.

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

#356

Post by Already__Taken »

hmottestad wrote: post #11

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',…

it's a bit of that you have to know the sha, and that's quite unique. it's apparently unique enough for Google photos to "private" share without logins

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

#357

Post by Cpoll »

tptacek wrote: post #142
Cpoll wrote: post #139

Earlier quoted context omitted.

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.

Like I said: if you can't revoke the thing you committed, you need to get in touch with Github and have them remove it. That's a thing they do.

Sure, but the whole point of the article is that people don't know their "private" forks aren't private. You can't get in touch with GitHub if you've never had any indication that anything's wrong.

The solution for that is better UX.

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

#358

Post by giobox »

schrodinger wrote: post #236
Cpoll wrote: post #139

Earlier quoted context omitted.

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) o…

There's an entire custom UX flow for forking on GH that is not part of git at all. I think its very fair here to discuss "fork" in the specific sense Github uses it, as its what has lead to some of the issues discussed. There are absolutely means of providing fork functionality that don't have some of the problems we are discussing, but that's not how GH chose to build it.

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

#359

Post by UweSchmidt »

dumbo-octopus wrote: post #340
UweSchmidt wrote: post #328

Earlier quoted context omitted.

I understand that you describe the status quo in many systems today. However, besides the technical aspect you talked about the "absolute best you could expect when asking for a delete in the UI^". I think this where I, other posters in the thread, most people, and probably the GDPR and other legislature, would disagree. We expect significantly more effort to clean up deleted data. This includes, for example, the abi…

> GDPR and other legislature Nope. GDPR allows deleted data to be retained in backups so long as there is an expiration process in place. Doesn’t matter how long it is. But certainly nobody has a right to forcing a company to pull all of their backups from cold storage and trove through them all any time any deletion request takes place. That’d be the quickest path to Distributed Denial of Bank Account Funds imaginab…

Interesting point about the GDPR; I will soften my point to mean that lawmakers have started (late) to regulate data retention / deletion and the rights of users in general and that might be a trend for the future.

However I would like to avoid the impression that with the description of the technical status quo the topic is settled. To do so I would go back to my previous point: Imagine some truly illegal pictures are in that cold storage backup, and one day you might have to restore that data. (Since aparently the user's wish to delete data is not quite as respected as certain other hard legal requirements regarding content)

What solutions to mitigate the situation could a company, or backup tool/web framework etc. reasonably come up with? Maybe check the restored data against a list of hashes/IDs of to-be-deleted-data?

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

#360

Post by yencabulator »

K0balt wrote: post #284
malfist wrote: post #84

Earlier quoted context omitted.

It's a bug bounty, not a "only if we have time to fix it" bounty. He found a security problem, they decided not to act on it, but it was still an acknowledged security problem

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.

Don't blame Git for Github decisions.

Github chooses to store all "Github forks" in the same repository, and allow accessing things in that repository even when they are not reachable by the refs in the namespace of one "fork". That is purely a Github decision.

Post reply on HN