I mean, the simple solution is to do the same as curl’s dev: If it’s AI, it’s ignored. If it’s a corporation who hasn’t had recent code published in the codebase, it’s ignored. Bugs and vulnerabilities should be human-reported by the community.
That’s the way forward for FOSS - ignore the corps. Then start rebasing on exclusively non-commercial licenses.
AI reports are ignored because they are so frequently crap that they are almost not worth investigating. If these ffmpeg reports are from Project Zero though, they are presumably real. Shipping code with vulnerabilities is always a terrible idea. If Google can find them, attackers can also find them.
I do have to wonder how many of these vulnerabilities are actually in the assembly language parts of the codecs. I had guessed they were more likely to be at the higher levels.
But if you had read the article and attached links then you would have learned that the particular issue under discussion and source of other issues is from Project Big Sleep, which focuses on using generative tooling to confabulate issues. You would also see for yourself that the reported issues are in C.
It looks like they ran the test case and triggered the crash. Therefore the issue is not confabulated.
Also, I’m unconvinced that use of ffmpeg inside of Google services is relevant to this. Google services can sandbox executables as much as they like, and given the amount of transcoding they do (say for youtube), it would surprise me if they’re not using gpu or hardware transcoders instead of ffmpeg anyway. Instead, they may care more about ffmpeg as used in browsers, TV boxes, and that sort of thing. That puts them in the same position as the Amazon person who said the ffmpeg devs could kill 3 major [Amazon] product lines by sending an email.
If a zillion cable boxes get pwned because of a 0-day in ffmpeg, well that’s unfortunate but at least they did their due diligence. But if they get pwned because the vendor knew about the vulnerability and decided to deploy anyway, that potentially puts the vendor on the hook for a ton more liability. That’s what “ffmpeg can kill 3 major product lines” means. So “send the email” (i.e. temporarily flag that codec as vulnerable and withdraw it from the default build), seems like a perfectly good response from ffmpeg.
The Big Sleep article is really good, I read it a week or so ago, sometime after this thread had died down.
I mean, the simple solution is to do the same as curl’s dev: If it’s AI, it’s ignored. If it’s a corporation who hasn’t had recent code published in the codebase, it’s ignored. Bugs and vulnerabilities should be human-reported by the community.
That’s the way forward for FOSS - ignore the corps. Then start rebasing on exclusively non-commercial licenses.
AI reports are ignored because they are so frequently crap that they are almost not worth investigating. If these ffmpeg reports are from Project Zero though, they are presumably real. Shipping code with vulnerabilities is always a terrible idea. If Google can find them, attackers can also find them.
I do have to wonder how many of these vulnerabilities are actually in the assembly language parts of the codecs. I had guessed they were more likely to be at the higher levels.
But if you had read the article and attached links then you would have learned that the particular issue under discussion and source of other issues is from Project Big Sleep, which focuses on using generative tooling to confabulate issues. You would also see for yourself that the reported issues are in C.
It looks like they ran the test case and triggered the crash. Therefore the issue is not confabulated.
Also, I’m unconvinced that use of ffmpeg inside of Google services is relevant to this. Google services can sandbox executables as much as they like, and given the amount of transcoding they do (say for youtube), it would surprise me if they’re not using gpu or hardware transcoders instead of ffmpeg anyway. Instead, they may care more about ffmpeg as used in browsers, TV boxes, and that sort of thing. That puts them in the same position as the Amazon person who said the ffmpeg devs could kill 3 major [Amazon] product lines by sending an email.
If a zillion cable boxes get pwned because of a 0-day in ffmpeg, well that’s unfortunate but at least they did their due diligence. But if they get pwned because the vendor knew about the vulnerability and decided to deploy anyway, that potentially puts the vendor on the hook for a ton more liability. That’s what “ffmpeg can kill 3 major product lines” means. So “send the email” (i.e. temporarily flag that codec as vulnerable and withdraw it from the default build), seems like a perfectly good response from ffmpeg.
The Big Sleep article is really good, I read it a week or so ago, sometime after this thread had died down.
deleted by creator