101–110 of 394 posts
Earlier quoted context omitted.
But that would still means they didn't intend to fix it, hence not giving bounty is fair.
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
If the (class of) problem is already known, it’s not worth rewarding.
Earlier quoted context omitted.
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…
Not defending GH here (their position is indefensible imo) but, as the article notes, they document these behaviors clearly and publicly: https://docs.github.com/en/pull-requests/collaborating-with-... I don't think they're being underhanded exactly... they're just making a terrible decision. Quoting from the article: > The average user views the separation of private and public repositories as a security boundary, a…
Can this be used to host illegal content? I.e.: fork a popular repo, commit a pirated book to the fork, delete the fork, use the original repo to access the pirated book? What would github do after receiving a DMCA request in that case?
Earlier quoted context omitted.
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…
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…
Lets get back to what we had before when multiple people can find the same bug and exploit if needed. Now we have the one person who finds the bug it gets patched and they don't get paid.
Earlier quoted context omitted.
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…
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…
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 the behaviour flies so against the grain, just publishing it in a help doc is not enough I'd argue. The linked article makes the exact same argument:
> "The average user views the separation of private and public repositories as a security boundary, and understandably believes that any data located in a private repository cannot be accessed by public users. Unfortunately, as we documented above, that is not always true. Whatsmore, the act of deletion implies the destruction of data. As we saw above, deleting a repository or fork does not mean your commit data is actually deleted."
On the other hand, once an API key or password has been published somewhere, you should rotate it anyway.
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
The point of a bug bounty is for companies to find new security problems. If the (class of) problem is already known, it’s not worth rewarding.
At the end it boils down to: is Github being honest and fair in answering the bug bounty reports?
If you think it is, cool.
If you don't, maybe it's not worth playing ball with Github's bug bounty process
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
The point of a bug bounty is for companies to find new security problems. If the (class of) problem is already known, it’s not worth rewarding.