6 ms·

If google bears no role in fixing the issues it finds and nobody else is being paid to do it either, it functionally is just providing free security vulnerabili

If google bears no role in fixing the issues it finds and nobody else is being paid to do it either, it functionally is just providing free security vulnerability research for malicious actors because almost nobody can take over or switch off of ffmpeg.

eddd-ddde 11mo ago
So your claim is that buggy software is better than documented buggy software?
- rsanek 11mo ago
  I think so, yes. Certainly it's more effort to both find and exploit a bug than to simply exploit an existing one someone else found for you.
  - jakeydus 11mo ago
    Yeah it's more effort, but I'd argue that security through obscurity is a super naive approach. I'm not on Google's side here, but so much infrastructure is "secured" by gatekeeping knowledge.
    - Brian_K_White 11mo ago
      I don't think you should try to invoke the idea of naivete when you fail to address the unhappy but perfectly simple reality that the ideal option doesn't exist, is a fantasy that isn't actually available, and among the available options, even though none are good, one is worse than another. "obscurity isn't security" is true enough, as far as it goes, but is just not that far. And "put the bugs that won't be fixed soon on a billboard" is worse. The super naive approach is ignoring that and thinking that "fix the bugs" is a thing that exists.
      - rcxdude 11mo ago
        If I know it's a bug and I use ffmpeg, I can avoid it by disabling the affected codec. That's pretty valuable.
        Brian_K_White 11mo ago
        More fantasy. Presumes the bug only exists in some part of ffmpeg that can be disabled at all, and that you don't need, and that you are even in control over your use of ffmpeg in the first place. Sure, in maybe 1 special lucky case you might be empowered. And in 99 other cases you are subject to a bug without being in the remotest control over it since it's buried away within something you use and don't even have the option not to use the surface service or app let alone control it's subcomponents.
        dotancohen 11mo ago
        The bug in question revolves around support for codec that has never been in wide use, and was only in obscure use over 25 years ago.
        Brian_K_White 11mo ago
        There is no "the bug". The discussion is about what to do with the power of bug-finding tools.
        zamadatix 11mo ago
        "The bug" in question refers to the one found by the bug-finding tool the article claims triggered the latest episode of debate. Nobody is claiming it's the only bug, just that this triggering bug highlighted was a clear example of where there is actually such a clear cut line. Google does contribute some patches for codecs they actually consume e.g. https://github.com/FFmpeg/FFmpeg/commit/b1febda061955c6f4bfbc1a75918b5e75e7d7f80 https://github.com/FFmpeg/FFmpeg/commit/b1febda061955c6f4bfb..., the bug in question was just an example of one the bug finding tool found that they didn't consume - which leads to this conversation.
    - strken 11mo ago
      Given that Google is both the company generating the bug reports and one of the companies using the buggy library, while most of the ffmpeg maintainers presumably aren't using their libraries to run companies with a $3.52 trillion dollar market cap, would you argue that going public with vulnerabilities that affect your own product before you've fixed them is also a naive approach?
      - zamadatix 11mo ago
        Sorry, but this states a lot of assumption as fact to ask a question which only makes sense if it's all true. I feel Google should assist the project more financially given how much they use it, but I don't think Google shipping products using every codec they find bugs for with their open source fuzzer project is a reasonable guess. I certainly doubt YouTube/Chrome let's you upload/compiles ffmpeg with this LucasArts format, as an example. For security issues relevant to their usage via Chrome CVEs etc, they seem to contribute on fixes as needed. E.g. here is one via fuzzing or a codec they use and work on internally https://github.com/FFmpeg/FFmpeg/commit/b1febda061955c6f4bfbc1a75918b5e75e7d7f80 https://github.com/FFmpeg/FFmpeg/commit/b1febda061955c6f4bfb... In regards whether it's a bad idea to publicly document security concerns found regardless whether you plan on fixing them, it often depends if you ask the product manager what they want for their product or what the security concerned folks in general want for every product :).
  - bawolff 11mo ago
    > I think so, yes. Certainly it's more effort to both find and exploit a bug than to simply exploit an existing one someone else found for you. That just means the script kiddies will have more trouble, while more scary actors like foreign intellegence agencies will have free reign.
    - HDThoreaun 11mo ago
      Foreign intelligence has free rein either way. The script kiddies are the only ones that can be stopped by technological solutions.
- user3939382 11mo ago
  it’s not a claim it’s common sense that’s why we have notice periods
  - user3939382 11mo ago
    I like how some coward downvoted with no response when my counterpoint is devestating.
janalsncm 11mo ago
I guess the question that a person at Google who discovers a bug they don’t personally have time to fix is, should they report the bug at all? They don’t necessarily know if someone else will be able to pick it up. So the current “always report” rule makes sense since you don’t have to figure out if someone can fix it. The same question applies if they have time to fix it in six months, since that presumably still gives attackers a large window of time. In this case the bug was so obscure it’s kind of silly.
- kragen 11mo ago
  It doesn't matter how obscure it is if it's a vulnerability that's enabled in default builds.
- rocqua 11mo ago
  This was not a case of stumbling across a bug. This was dedicated security research taking days if not weeks of high paid employees to find. And after all that, they just drop an issue, instead of spending a little extra time on producing a patch.
  - walletdrainer 11mo ago
    It’s possible that this is a more efficient use of their time when it comes to open source security as a whole, most projects do not have a problem with reports like this. If not pumping out patches allows them to get more security issues fixed, that’s fine!
    - rocqua 11mo ago
      From the perspective of Google maybe, but from the perspective of open source projects, how much does this drain them? Making open source code more secure and at the same time less prevalent seems like a net loss for society. And if those researchers could spare some time to write patches for open source projects, that might benefit society more than dropping disclosure deadlines on volunteers.
woodruffw 11mo ago
I don’t think vulnerability researchers are having trouble finding exploitable bugs in FFmpeg, so I don’t know how much this actually holds. Much of the cost center of vulnerability research is weaponization and making an exploit reliable against a specific set of targets. (The argument also seems backwards to me: Google appears to use a lot of not-inexpensive human talent to produce high quality reports to projects, instead of dumping an ASan log and calling it a day. If all they cared about was shoveling labor onto OSS maintainers, they could make things a lot easier for themselves than they currently do!)
- gcr 11mo ago
  Internally, Google maintains their own completely separate FFMpeg fork as well as a hardened sandbox for running that fork. Since they keep pace with releases to receive security fixes, there’s potentially lots of upstreamable work (with some effort on both sides…)
  - woodruffw 11mo ago
    My understanding from adjacent threads in this discussion is that Google does in fact make significant upstream contributions to FFmpeg. Per policy those are often made with personal emails, but multiple people have said that Google’s investment in FFmpeg’s security and codec support have been significant. (But also, while this is great, it doesn’t make an expectation of a patch with a security report reasonable! Most security reports don’t come with patches.)
  - SergeAx 11mo ago
    Shouldn't this fork be publicly available as per GPL license?
Aurornis 11mo ago
This is a weird argument. Basically condoning security through obscurity: If nobody reports the bug then we just pretend it doesn’t exist, right? There are many groups searching for security vulnerabilities in popular open source software who deliberately do not disclose them. They do this to save them for their own use or even to sell them to bad actors. It’s starting to feel silly to demonize Google for doing security research at this point.
- KingMob 11mo ago
  > It’s starting to feel silly to demonize Google for doing security research at this point. Aren't most people here demonizing Google for dedicating the resources to find bugs, but not to fix them?
  - watwut 11mo ago
    And not giving the maintainners reasonable amount of time to fix. This was triggered by recent change of policy on google side.
    - surajrmal 11mo ago
      The timeline is industry standard at this point. The point is make sure folks take security more seriously. If you start deviating from the script, others will expect the same exceptions and it would lose that ability. Sometimes it's good to let something fail loudly to show this is a problem. If ffmpeg doesn't have enough maintainers, then they should fail and let downstream customers know so they have more pressure to contribute resources. Playing superman and trying to prevent them from seeing the problem will just lead to burn out.
      - Orygin 11mo ago
        Is it industry standard to run automatic AI tools and spam the upstream with bug reports? To then expect the bugs to be fixed within a 90 days is a bit much. It's not some lone report of an important bug, it's AI spam that put forth security issues at a speed greater than they have resources to fix it.
raincole 11mo ago
Security by obscurity. In 2025. On HN.
gr4vityWall 11mo ago
> it functionally is just providing free security vulnerability research for malicious actors because almost nobody can take over or switch off of ffmpeg At least, if this information is public, someone can act on it and sandbox ffmpeg for their use case, if they think it's worth it. I personally prefer to have this information be accessible to all users.
xign 11mo ago
Except users can act accordingly to work around the vulnerability. For one, it lets people understand where ffmpeg is at so they can treat it more carefully (e.g. run it in a sandbox). Ffmpeg is also open source. After public disclosure, distros can choose to turn off said codec downstream to not expose this attack vector. There are a lot of things users can do to protect themselves but they need to be aware of the problem first.

eddd-ddde 11mo ago

So your claim is that buggy software is better than documented buggy software?

rsanek 11mo ago
I think so, yes. Certainly it's more effort to both find and exploit a bug than to simply exploit an existing one someone else found for you.
- jakeydus 11mo ago
  Yeah it's more effort, but I'd argue that security through obscurity is a super naive approach. I'm not on Google's side here, but so much infrastructure is "secured" by gatekeeping knowledge.
  - Brian_K_White 11mo ago
    I don't think you should try to invoke the idea of naivete when you fail to address the unhappy but perfectly simple reality that the ideal option doesn't exist, is a fantasy that isn't actually available, and among the available options, even though none are good, one is worse than another. "obscurity isn't security" is true enough, as far as it goes, but is just not that far. And "put the bugs that won't be fixed soon on a billboard" is worse. The super naive approach is ignoring that and thinking that "fix the bugs" is a thing that exists.
    - rcxdude 11mo ago
      If I know it's a bug and I use ffmpeg, I can avoid it by disabling the affected codec. That's pretty valuable.
      - Brian_K_White 11mo ago
        More fantasy. Presumes the bug only exists in some part of ffmpeg that can be disabled at all, and that you don't need, and that you are even in control over your use of ffmpeg in the first place. Sure, in maybe 1 special lucky case you might be empowered. And in 99 other cases you are subject to a bug without being in the remotest control over it since it's buried away within something you use and don't even have the option not to use the surface service or app let alone control it's subcomponents.
        dotancohen 11mo ago
        The bug in question revolves around support for codec that has never been in wide use, and was only in obscure use over 25 years ago.
        Brian_K_White 11mo ago
        There is no "the bug". The discussion is about what to do with the power of bug-finding tools.
        zamadatix 11mo ago
        "The bug" in question refers to the one found by the bug-finding tool the article claims triggered the latest episode of debate. Nobody is claiming it's the only bug, just that this triggering bug highlighted was a clear example of where there is actually such a clear cut line. Google does contribute some patches for codecs they actually consume e.g. https://github.com/FFmpeg/FFmpeg/commit/b1febda061955c6f4bfbc1a75918b5e75e7d7f80 https://github.com/FFmpeg/FFmpeg/commit/b1febda061955c6f4bfb..., the bug in question was just an example of one the bug finding tool found that they didn't consume - which leads to this conversation.
  - strken 11mo ago
    Given that Google is both the company generating the bug reports and one of the companies using the buggy library, while most of the ffmpeg maintainers presumably aren't using their libraries to run companies with a $3.52 trillion dollar market cap, would you argue that going public with vulnerabilities that affect your own product before you've fixed them is also a naive approach?
    - zamadatix 11mo ago
      Sorry, but this states a lot of assumption as fact to ask a question which only makes sense if it's all true. I feel Google should assist the project more financially given how much they use it, but I don't think Google shipping products using every codec they find bugs for with their open source fuzzer project is a reasonable guess. I certainly doubt YouTube/Chrome let's you upload/compiles ffmpeg with this LucasArts format, as an example. For security issues relevant to their usage via Chrome CVEs etc, they seem to contribute on fixes as needed. E.g. here is one via fuzzing or a codec they use and work on internally https://github.com/FFmpeg/FFmpeg/commit/b1febda061955c6f4bfbc1a75918b5e75e7d7f80 https://github.com/FFmpeg/FFmpeg/commit/b1febda061955c6f4bfb... In regards whether it's a bad idea to publicly document security concerns found regardless whether you plan on fixing them, it often depends if you ask the product manager what they want for their product or what the security concerned folks in general want for every product :).
- bawolff 11mo ago
  > I think so, yes. Certainly it's more effort to both find and exploit a bug than to simply exploit an existing one someone else found for you. That just means the script kiddies will have more trouble, while more scary actors like foreign intellegence agencies will have free reign.
  - HDThoreaun 11mo ago
    Foreign intelligence has free rein either way. The script kiddies are the only ones that can be stopped by technological solutions.
user3939382 11mo ago
it’s not a claim it’s common sense that’s why we have notice periods
- user3939382 11mo ago
  I like how some coward downvoted with no response when my counterpoint is devestating.

janalsncm 11mo ago

I guess the question that a person at Google who discovers a bug they don’t personally have time to fix is, should they report the bug at all? They don’t necessarily know if someone else will be able to pick it up. So the current “always report” rule makes sense since you don’t have to figure out if someone can fix it. The same question applies if they have time to fix it in six months, since that presumably still gives attackers a large window of time. In this case the bug was so obscure it’s kind of silly.

kragen 11mo ago
It doesn't matter how obscure it is if it's a vulnerability that's enabled in default builds.
rocqua 11mo ago
This was not a case of stumbling across a bug. This was dedicated security research taking days if not weeks of high paid employees to find. And after all that, they just drop an issue, instead of spending a little extra time on producing a patch.
- walletdrainer 11mo ago
  It’s possible that this is a more efficient use of their time when it comes to open source security as a whole, most projects do not have a problem with reports like this. If not pumping out patches allows them to get more security issues fixed, that’s fine!
  - rocqua 11mo ago
    From the perspective of Google maybe, but from the perspective of open source projects, how much does this drain them? Making open source code more secure and at the same time less prevalent seems like a net loss for society. And if those researchers could spare some time to write patches for open source projects, that might benefit society more than dropping disclosure deadlines on volunteers.

woodruffw 11mo ago

I don’t think vulnerability researchers are having trouble finding exploitable bugs in FFmpeg, so I don’t know how much this actually holds. Much of the cost center of vulnerability research is weaponization and making an exploit reliable against a specific set of targets. (The argument also seems backwards to me: Google appears to use a lot of not-inexpensive human talent to produce high quality reports to projects, instead of dumping an ASan log and calling it a day. If all they cared about was shoveling labor onto OSS maintainers, they could make things a lot easier for themselves than they currently do!)

gcr 11mo ago
Internally, Google maintains their own completely separate FFMpeg fork as well as a hardened sandbox for running that fork. Since they keep pace with releases to receive security fixes, there’s potentially lots of upstreamable work (with some effort on both sides…)
- woodruffw 11mo ago
  My understanding from adjacent threads in this discussion is that Google does in fact make significant upstream contributions to FFmpeg. Per policy those are often made with personal emails, but multiple people have said that Google’s investment in FFmpeg’s security and codec support have been significant. (But also, while this is great, it doesn’t make an expectation of a patch with a security report reasonable! Most security reports don’t come with patches.)
- SergeAx 11mo ago
  Shouldn't this fork be publicly available as per GPL license?

Aurornis 11mo ago

This is a weird argument. Basically condoning security through obscurity: If nobody reports the bug then we just pretend it doesn’t exist, right? There are many groups searching for security vulnerabilities in popular open source software who deliberately do not disclose them. They do this to save them for their own use or even to sell them to bad actors. It’s starting to feel silly to demonize Google for doing security research at this point.

KingMob 11mo ago
> It’s starting to feel silly to demonize Google for doing security research at this point. Aren't most people here demonizing Google for dedicating the resources to find bugs, but not to fix them?
- watwut 11mo ago
  And not giving the maintainners reasonable amount of time to fix. This was triggered by recent change of policy on google side.
  - surajrmal 11mo ago
    The timeline is industry standard at this point. The point is make sure folks take security more seriously. If you start deviating from the script, others will expect the same exceptions and it would lose that ability. Sometimes it's good to let something fail loudly to show this is a problem. If ffmpeg doesn't have enough maintainers, then they should fail and let downstream customers know so they have more pressure to contribute resources. Playing superman and trying to prevent them from seeing the problem will just lead to burn out.
    - Orygin 11mo ago
      Is it industry standard to run automatic AI tools and spam the upstream with bug reports? To then expect the bugs to be fixed within a 90 days is a bit much. It's not some lone report of an important bug, it's AI spam that put forth security issues at a speed greater than they have resources to fix it.

raincole 11mo ago

Security by obscurity. In 2025. On HN.

gr4vityWall 11mo ago

> it functionally is just providing free security vulnerability research for malicious actors because almost nobody can take over or switch off of ffmpeg At least, if this information is public, someone can act on it and sandbox ffmpeg for their use case, if they think it's worth it. I personally prefer to have this information be accessible to all users.

xign 11mo ago

Except users can act accordingly to work around the vulnerability. For one, it lets people understand where ffmpeg is at so they can treat it more carefully (e.g. run it in a sandbox). Ffmpeg is also open source. After public disclosure, distros can choose to turn off said codec downstream to not expose this attack vector. There are a lot of things users can do to protect themselves but they need to be aware of the problem first.