Dear Open Source Developers: It's OK not to embargo

34 points by liberty


reezer

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.

alandekok

If someones can spend $5, and scan a public repository to find security issues, embargoes are pointless.

hsivonen

FWIW, Mozilla went back to deferring the disclosure of test cases for security fixes: https://groups.google.com/a/mozilla.org/g/dev-platform/c/5zZZULnmJRU

So I guess with generally-available LLMs, when it comes to exploit development, there’s still a difference between seeing the fix land and also getting additional information on what the fix is about.

Edited to add: Firefox is different from many other Open Source projects in the sense that instead of distros backporting security fixes, distros take either the upsteam release channel source or the upstream ESR channel source, so there isn’t the kind of coordinated patch under embargo plus coordinated disclose as with some other projects.

Student

A sensible idea.