271–280 of 394 posts
This is not new. Many people have noticed this before, e.g. https://hikari.noyu.me/blog/2020-05-05-github-private-repos-...
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
Earlier quoted context omitted.
This is not clickbait. It's well-explained and fairly presents the facts and GH's position. Based on the reaction here, it's clear many people are not aware of these footguns. If anything, the article is a public service.
Based on the comments, many have known since 2018. GitHub has made multiple statements about it. It's been written about multiple times, and now truffle is reposting old content with a name like IDOR to try to invent a new vuln class that doesn't exist. The title of the post is misleading, a specific set of repos leak data under specific circumstances - not every repo. The first two sentences of the post immediately…
And many more haven't known. It wouldn't be sitting on the front page with 1300+ upvotes otherwise. This is, effectively, not some ho-hum old news -- even if it was for you. And that's what so many are complaining about. The hypocrisy of violating POLA so blatantly and then shrugging it off, pointing to some explanation buried in the docs that they know damn well most people won't read, and saying "Hey the info is right there, on you if you didn't RTFM".
Earlier quoted context omitted.
Yep, I see GitHub as "public only" hosting, and if I want to host something private, I will choose another vendor.
Or commit an ecryptfs. Clone and mount, unmount and commit
i read headlines like the above with the implied "not just to the employees there anymore"
In response to the end of the article "it’s important to note that some of these issues exist on other version control system products." I actually have experience helping someone with an issue on BitBucket with PII data that you can't rotate. Once we eliminated the references in the tree and all forks (they were all private thankfully), we reached out to BitBucket support, and they were able to garbage collect those…
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…
There seems to be no such thing as a "private fork" on GitHub in 2024 [1]: > A fork is a new repository that shares code and visibility settings with the upstream repository. All forks of public repositories are public. You cannot change the visibility of a fork. [1] https://docs.github.com/en/pull-requests/collaborating-with-...
Earlier quoted context omitted.
I think you are referring to tombstoning. That's usually a temporary process that may immediately delete the underlying data, keeping a tombstone to ensure the deletion propagates to all storage nodes. A compaction process purges the underlying data (if still present) and the tombstones after a suitable delay. It's a fancy delete that takes some time to process, but the data is eventually gone. You could turn off the…
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…
- 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 backup; transaction should resolve in a timely fashion, failed deletes can be communicated to the user quickly etc.)
Surprised at the comments minimizing this. I've used github for a long time, would not have expected these results, and was unnerved by them. I'd recommend reading the article yourself. It does a good job explaining the vulnerabilities.
> I've used github for a long time, would not have expected these results, and was unnerved by them. So you've used it heavily, but haven't read the docs or thought about how forks work, and are now surprised. This seems like a learning opportunity, read the docs for stuff you use heavily, read the man pages and info pages for tools you rely on. None of this seemed surprising to me, perhaps because I've made PRs, see…
However in UX/DX the question isn't whether users can develop the right intuition based on how they interact with software over time and reading through the documentation but how to shorten the time and effort necessary for that, ideally so that a single glance is enough.
Do you think reading all the documentation for every feature of every tool you use in your life is a good use of your time and something that should be expected of everyone? As someone developing software used by other people, I don't.