Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Or perhaps you’re a FAANG security researcher and your time will be better spent serving the OSS community as a whole by submitting as many useful bug reports as possible, instead of slightly fewer reports with patches included.

In this particular case it’s hardly obvious which patch you should submit. You could fix this particular bug (and leave in place the horrible clunky codec that nobody ever uses) OR you could just submit a patch that puts it behind a compile flag. This is really a decision for the maintainers, and submitting the latter (much better!) patch would not save the maintainers any meaningful amount of time anyway.



I don’t understand how it helps the community to publicly release instructions for attacking people, unless you’re trying to incentivize a company to fix their crap. In this case, there is no company to incentivize, so just report it privately.

You can say publicly that “there is an ABC class vulnerability in XYZ component” so that users are aware of the risk.


It’s OSS so somebody who cares will fix it, and if nobody cares then it doesn’t really matter.

This also informs users that it’s not safe to use ffmpeg or software derived from it to open untrusted files, and perhaps most importantly releasing this tells the distro package maintainers to disable the particular codec when packaging.


Right, I just don’t see why they need to publish the actual exploit.


They have not, neither have they indicated that they’re planning to do so.


I thought that was how the 90 day disclosure timeline worked?


After 90 days they just disclose the vulnerability. From there, developing an exploit is still a fairly complex task.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: