Understandable

Also note that the embargo stuff is kinda backwards now: initially it was always the maintainers of the software (often proprietary) who requested embargoes and didn't want security researchers to publish, in order for them to be able to fix it first. And I remember that this was even a hotly debated topic not too long ago (keywords "responsible disclosure" vs. "full disclosure"). The fact that embargoes are now requested by the security reporters is a perversion of the entire process.

I don't begrudge security researchers wanting to earn money with their job, it just shouldn't be at the expense of the maintainers and users of the software they are analyzing.

> These days I almost never accept embargoes either on my projects. I consider that the standard rule is no embargo, and that when it's really critical (i.e. about once a year), anyway, each time it's different and each time you find a good reason for breaking your own rules, thus in this case you can make an exception and accept an embargo of the suitable time (including waiting for a distro maintainer to be back at work etc). So I prefer to say "no to embargoes unless *I* consider the case special enough to derogate to that rule". Then this is negotiated with those I'm relying on and we can collectively act for the best of our users. For now this has simplified our task (maintainers and distro packagers), significantly reduced the overhead caused by this ridiculous theater and resulted in delivering important fixes very quickly to exposed users.

Fully agree with that sentiment. And once security fixes are out, there's always the time between the fixes being out and them being installed, so even with an embargo there will always be a window in which some systems will be potential subjects to exploitation.