91–100 of 394 posts
I don’t use GitHub for anything serious, rather my own Gitea. However: > Any commits made to your private fork after you make the “upstream” repository public are not viewable. Does that mean a private repo that has never been or will be public isn’t accessible? That scenario wasn’t mentioned.
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…
For companies like Microsoft, which a CSRB audit showed that their security culture 'inadequate', the risk of disclosure with a POC is about the only tool we have to enforce their side of the Shared Responsibility Model.
Even the largest IT spender in the world, the US government has moved more from the carrot to the stick model. If they have to do it so do we.
Unfortunately as publishing a 'bad practices' list by us doesn't invoke the risk of EULA busting gross negligence claims, responsible disclosure is one of the few tools we have.
Most of this report is just noise. GitHub repos are public. Public stuff can be shared. Public stuff shared previously and then deleted is "still available", but it was shared previously and not really subject to security analysis. The one thing they seem to be able to show is that commits in private branches show up in the parent repository if you know the SHAs. And that seems like a real vulnerability. But AFAICT i…
People are so preoccupied with putting the code on GitHub. It’s like it doesn’t exist before it’s on GitHub. If you’re not gonna share it then it hardly matters. Use a backup drive. Git is distributed. You don’t have to put your dotfiles on GitHub. Local is enough.
Earlier quoted context omitted.
For the first two, git is based on content addressable storage, so it makes sense that anything that is ever public will never disappear. I can sympathize with someone who gets bit by it, as it might not have occurred to them, but it’s part of the model. The third strikes me as counter-intuitive and hard to reason about. P.S. If you publish your keys or access tokens for well known services to GitHub and you are prom…
I agree the 3rd is by far the worst of the offenders. But even the first two should have more visibility. For example, by notifying users during deletion of forked repos that data will still be available. The exact UX here is debatable, but I don't think security warnings buried in the docs is enough. They should be accounting for likely misunderstandings of the model.
I wouldn't mind a disclaimer when you delete a repository that any information that repository ever contained is likely to have already been downloaded and stored. Per the comment I added, I'm not sure it would really help that much, but it would not be harmful.
What would github do after receiving a DMCA request in that case?