251–260 of 394 posts
Earlier quoted context omitted.
In which case, yeah, thats a vulnerability. They shouldn't allow a short hash to match up against anything but public data.
It's common to use short hash in pull request, and then modify or rebase the commits. The solutions are: * Force people to use the full hash. * Get use to a lot of dead links. * Claim that it's a feature, not a bug.
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
Come on, this is not surprising. "Private repositories" were never private as I said before. [0] [0] https://news.ycombinator.com/item?id=23057769
Well, duh. That's not a reason to avoid every "private" feature in every product on the planet.
A failure in the system is still surprising. I could equally say "all software has bugs, so it's not surprising if your self-hosted solution leaks data". But that would be too dismissive, as you are being.
Earlier quoted context omitted.
> If you published a key Why would anyone think that a private fork is "published"!? This is the footgun here: The UI is telling you that nobody can see the secrets you committed to your private copy , but actually it is widely accessible. A similar example of UI-vs-reality mismatch that I've noticed recently is the Azure Store Account "public" visibility. By default, it uses your authenticated account for RBAC acces…
Putting keys in repos should not be done, full stop. Even if GitHub forks weren’t public, their _private_ repos could one day be compromised. Instead, store keys in a shared vault, .gitignore the .env and have a .env.example with empty keys.
I do see this regularly in my work. All but one dev team I’ve worked with over the last few years has done this.
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…
To be fair, in the true git sense, if a "fork" is really just a branch, deleting the original completely would also mean deleting every branch (fork) completely obviously not a fan of this policy though
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.
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-...
Am I the only one who finds this conceptually confusing?