Morally seems even worse, Crowdsec did it by accident, GitHub knows about it for years now.
Anyone can access deleted and private repository data on GitHub
321–330 of 394 posts
Re: Anyone can access deleted and private repository data on GitHub
#322Earlier 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.
Re: Anyone can access deleted and private repository data on GitHub
#323This 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.
Re: Anyone can access deleted and private repository data on GitHub
#324Github 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
#325Earlier 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.
Re: Anyone can access deleted and private repository data on GitHub
#326I 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…
Re: Anyone can access deleted and private repository data on GitHub
#327... yeah if is push your keys to GitHub.
Re: Anyone can access deleted and private repository data on GitHub
#328Earlier 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.
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
#329Earlier 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.
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
#330I 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…
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.