>I think that is a little entitled. They should be happy google isn't just straight up emailing full-disclisure.
Google has literally billions of dollars in profits (in part because they use FFmpeg in a bunch of commercial products like Youtube and Chrome), and one of the largest software workforces in the world, including expertise on secure software and vulnerability remediation.
If anyone can afford to contribute back a fix instead of just raising a report, and has the ethical responsibility to do so, it's Google.
I'm not sure why this is an unpopular idea, but contribute back to your upstream dependencies. If they're a dependency, they're part of *your code*.
> Not to mention they just have a vested interest in getting the problem solved. Even if we don't talk about money.
Correct me if im wrong, but based on the report this looks like something that would affect regular users of ffmpeg but not google's use.
FWIW I tried replicating it and didn't get the same result. I end up with a failed conversion, exit code 69[0]. Same thing when I run with my installed version of ffmpeg.
But I think Google would still be concerned. Even if they're running ffmpeg in a sandbox you can escape sandboxes. The sandbox is a security layer, not what makes the thing safe. You should be using it as a layer of defense for unknown vulns, and try to resolve vulns. I mean Google is much more likely to have an attacker trying to chain a vuln with a sandbox escape than the average user.
Btw:
So my version does have that codec, as others are reporting.[0] Will expire soon https://0x0.st/KL6K.log
[DISCLOSURE]: I AM NOT A SECURITY PROFESSIONAL. If I am wrong please correct me
Security vulnerability finding is a contribution. On the open market the type of service google is providing here would cost hundreds of thousands of dollars if not millions.