I think it makes sense to think about the "bad guy". If I was a bad guy that scans bug trackers and creates exploits to abuse them then I'd probably do everything to learn about these early, so will try to get in all the early "heads up" channels I can and try to put contributors in as spies. I'd profit from any sort of delay, because it gives me more time to exploit or sell exploits. Also there's a good chance that the fewer people know about it the higher the value is.
Maybe embargoes sense in a different era, maybe they didn't.
That said I think it's also not something where it needs to be a hard yes or no. I think reducing the time frame is the biggest thing. Eg. there is a difference between embargoes that are hours, days, weeks, months and someone noticing an issue informing some security@ list or mark something as a security issue in a bug tracker and waiting for devs who can release patches to wake up or something.
I'd argue like so many situations it's maybe not a once size fits all.
Since curl's policy is mentioned. Something that appears to be hard is to judge severity. There are so many instances of low severity bugs or bugs that weren't at all considered to be relevant to security when reported, but ended up being things like RCEs. Sometimes it's also combinations of low severity bugs, sometimes it's later changes, sometimes it's even a fix that turns out to be bad. So in a way there is a certain degree of gut feeling involved.
But all doesn't mean embargoes help and they might make things a lot worse. Just like how there is that random guy working somewhere unpaid on the foundation of everything, it might also be some random guy looking through an open source project fixing a critical bug. This seems to be true for projects with millions of users and projects with five users.
reezer | 6 hours ago
I think it makes sense to think about the "bad guy". If I was a bad guy that scans bug trackers and creates exploits to abuse them then I'd probably do everything to learn about these early, so will try to get in all the early "heads up" channels I can and try to put contributors in as spies. I'd profit from any sort of delay, because it gives me more time to exploit or sell exploits. Also there's a good chance that the fewer people know about it the higher the value is.
Maybe embargoes sense in a different era, maybe they didn't.
That said I think it's also not something where it needs to be a hard yes or no. I think reducing the time frame is the biggest thing. Eg. there is a difference between embargoes that are hours, days, weeks, months and someone noticing an issue informing some security@ list or mark something as a security issue in a bug tracker and waiting for devs who can release patches to wake up or something.
I'd argue like so many situations it's maybe not a once size fits all.
Since curl's policy is mentioned. Something that appears to be hard is to judge severity. There are so many instances of low severity bugs or bugs that weren't at all considered to be relevant to security when reported, but ended up being things like RCEs. Sometimes it's also combinations of low severity bugs, sometimes it's later changes, sometimes it's even a fix that turns out to be bad. So in a way there is a certain degree of gut feeling involved.
But all doesn't mean embargoes help and they might make things a lot worse. Just like how there is that random guy working somewhere unpaid on the foundation of everything, it might also be some random guy looking through an open source project fixing a critical bug. This seems to be true for projects with millions of users and projects with five users.
Student | 15 hours ago
A sensible idea.