Live data from Hacker News

Anyone can access deleted and private repository data on GitHub

trufflesecurity.com

321–330 of 394 posts

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

#322

Earlier quoted context omitted.

If you run a DELETE FROM in any modern sql engine, which is the absolute best you could expect when asking for a delete in the UI^, the data is nowhere near gone. It’s still in all the backups, all the WALs, all the transactions that started before yours, etc. It’s marked for eventual removal, and that’s it. Just as the definition of delete I provided says. ^ (more likely they’ll just update the table to set a delete…

> eventual removal To me, the idea that the deletion takes time to complete doesn't negate the idea that the data will be gone once the process completes. WAL archive and backups are external systems. You could argue that nothing supports deletion because an external backup could exist, but that's not a useful conversation.

Going back to the point of the the thread, we agree the deleted data is not erased. The user is unable to access it through normal mechanisms, but the existence of side channels that could reveal it does not negate the idea that it has truly been “deleted”, especially when one looks at the historical context surrounding that word.

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

#323
post #189

This walks like a dark pattern and quacks like a dark pattern. People's entire livelihoods are at stake and they don't care. Most likely because plausible deniability and obscure TOS rights of how and when the code is used is more valuable to them than the reputation hit. It is hard to imagine this is very hard to fix.

> People's entire livelihoods are at stake No they aren't.

Sure they are. If somebody has a proprietary product that they happened to organize as a fork of an open source base at some point, it is exposed. The git organization aside, that is a very common business model.

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

#324
Doesn't this kind of make sense? We are not dealing with personal property. We are dealing with term licensed software.

Github is a software distributing network. Like the app store, or Steam. They grant you access to licensed content, which you self license, and then they facilitate access for you. Based on the honor system. But some things can just be assumed to be true for the sake of simplicity and liability.

For example, If I make a repo public and then take it private the hashes that were obtained while it was open are still open. If I make a repo that's closed and open it, the whole thing is open.

If you fork a public repo and make private commits on it to a software distributor like Github, that is probably just going to end in a violation of the license. In this scenario, Github is saving you from yourself.

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

#325
post #316

Earlier quoted context omitted.

Disagree. If you're using a service, understand how it works. Not everything needs to be designed for idiots and lazy people, it's ok for some tools and services, especially those aimed at technical people and engineers to require reading to use properly and to be surprising or unintuitive at first glance.

There's got to be a word for these kinds of ridiculous arguments which use personal responsibility as a cudgel against a systematic fix. I agree generally that interfaces have been dumbing down too far, but "private is actually not private and it's on you for not knowing that, idiot B)" is a weird place to be planting that flag.

There should probably also be a word for the belief that when a system doesn't work how you want it to, that is so obviously a systematic problem that needs fixing rather than, for example, evidence of differing goals or priorities that it is reasonable to describe anyone who thinks otherwise as ridiculous.

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

#326

I learned about it years ago when I accidentally pushed secrets to the repo. When after rebasing and force pushing to the branch I was still able to access that commit, we decided to stop using GitHub.

Hopefully you have since learned to read the documentation of the tools you use, or at least enough of it to understand the basic data model you are working with. Rebasing won't even (immediately) remove the commits from your local repo. And force pushing isn't some magic operation either. Further, even if you had managed to delete the secrets from the repo you have to assume that others already copied them and rotat…

Yes, the credentials were invalidated promptly, before trying to remove them from GitHub. That said, we were using different version control system and GitHub was new to us. This was many years ago.

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

#328

Earlier quoted context omitted.

Imagine the data that was deleted is of the highest level of illegality you can imagine. Under no circumstance can your service be associated with that content. - What was your "definition of delete" again? - You mentioned some of the convenient technical defaults your frameworks and tools provide out-of-the-box, can you think of ways to improve the situation? (You might re-run delete requests after restoring a backu…

We are missing the point here. The GP was claiming that delete meant something other than adding a mark to an item that you want to eventually be removed from the system. It doesn’t.

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 ability to delete datasets from backups, as well as a general accountability of how often and where all the data is stored and if, and when a deletion process is complete.

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

#329

Earlier quoted context omitted.

> eventual removal To me, the idea that the deletion takes time to complete doesn't negate the idea that the data will be gone once the process completes. WAL archive and backups are external systems. You could argue that nothing supports deletion because an external backup could exist, but that's not a useful conversation.

Going back to the point of the the thread, we agree the deleted data is not erased. The user is unable to access it through normal mechanisms, but the existence of side channels that could reveal it does not negate the idea that it has truly been “deleted”, especially when one looks at the historical context surrounding that word.

What? I don't agree with that.

Can you point to an example of a modern database that "supports deletion" but keeps the data around forever? Maybe I've just used different tools than you. Knowing modern data retention concerns I'd be surprised if such a thing existed.

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

#330
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…

Honest question. Submitting these types of bugs only to get a: "we have determined it is known low risk issue..." seems like they really don't want to pay for someone else's time and dedication in making their product safer. If they knew about this, was this disclosed somewhere? If not I don't see them playing a fair game. What's the motivation to do this if in the end they can have the final decision to award you or…

It's not just GitHub and it's not just because they don't want to pay bug hunters. In my career, I have escalated multiple bugs to my employer(s) in which the response was 'working as intended'. And they wouldn't have to pay me another cent if they acknowledged the issue.

In my experience, there was two reasons for this behavior:

1. They don't want to spin dev cycles on something that isn't directly related to revenue (e.g. security) 2. Developers don't have the same mindset as someone who's whole job is security. So they think something is fine when it's really not.

Post reply on HN