191–200 of 394 posts
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
> It's a bug bounty, not a "only if we have time to fix it" bounty It's only a bug if it's not intended
Earlier quoted context omitted.
As the article pointed out, GitHub already publicly documented this vulnerability. My employer doesn't pay out for known security issues, especially if we have mitigating controls. A lot of people spam us with vulnerability reports from security tools we already use. At least half of them turn out to be false positives we are already aware of. In my opinion, running a bug bounty program at all is a net negative for u…
> As the article pointed out, GitHub already publicly documented this vulnerability. I'm honestly not yet convinced that is enough here - I've fallen victim to this without realizing it - the behaviour here is so far removed from how I suspect most user's mental model of github.com works. For me none of the exposed data is sensitive, but the point remains I was totally unawares it would be retrievable like this. If t…
1. GitHub has a nasty privacy/security hole, where commonsense expectations about the meanings of common words are violated by the system.
2. Github has publicly announced that they don't care about this part of user data security (private code), so won't pay people to know tell them what they alreay know and announced.
Github won't pay you to tell them they are wrong when everyone alreay knows.
IMO, the real vulnerability here is the way the Github Events archive exposes the SHA1 hashes of the vulnerable repositories. It would be easy to trawl the entire network to access these deleted/private repositories, but only because they have a list of them. Similar (but less concerning) is the ability to use short SHA1 hashes. You'd have to either be targeting a particular repository (for example, one for which a m…
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.
No, it really isn’t. Anyone who uses that word that way is just factually incorrect, and probably pretty irresponsible depending on the context. Software should not tell lies.
> delete: remove or obliterate (written or printed matter), especially by drawing a line through it or marking it with a delete sign Which is, indeed, what every modern database does.
I believe Kafka make deletion difficult, since it's an append-only log, but Kafka doesn't work well with laws that require deletion of data, so I don't believe it's a popular choice any longer (I.E. isn't modern).
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
git is a "distributed" version control software afterall. It means a peer can't control everything.
Earlier quoted context omitted.
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-...
A fork of a private repo is private. When you make the original repo public, the fork is still a private repo, but the commits can now be accessed by hash.