10 ms·

My takeaway from the article was not that the report was a problem, but a change in approach from Google that they’d disclose publicly after X days, regardless

by Msurrow 11mo ago

My takeaway from the article was not that the report was a problem, but a change in approach from Google that they’d disclose publicly after X days, regardless of if the project had a chance to fix it. To me its okay to “demand” from a for profit company (eg google) to fix an issue fast. Because they have ressources. But to “demand” that an oss project fix something with a certain (possibly tight) timeframe.. well I’m sure you better than me, that that’s not who volunteering works

vadansky 11mo ago
On the other hand as an ffmpeg user do you care? Are you okay not being told a tool you're using has a vulnerability in it because the devs don't have time to fix it? I mean someone could already be using the vulnerability regardless of what Google does.
- wpm 11mo ago
  They could be, and the chances of that increase immensely once Google publishes it.
- cogman10 11mo ago
  Sure but how. Let's say that FFMPEG has a 10 CVE where a very easy stream can cause it to RCE. So what? We are talking about software commonly for end users deployed to encode their own media. Something that rarely comes in untrusted forms. For an exploit to happen, you need to have a situation where an attacker gets out a exploited media file which people commonly transcode via FFMPEG. Not an easy task. This sure does matter to the likes of google assuming they are using ffmpeg for their backend processing. It doesn't matter at all for just about anyone else. You might as well tell me that `tar` has a CVE. That's great, but I don't generally go around tarring or untarring files I don't trust.
  - omnicognate 11mo ago
    AIUI, (lib)ffmpeg is used by practically everything that does anything with video, including such definitely-security-sensitive things as Chrome, which people use to play untrusted content all the time.
    - cogman10 11mo ago
      hmm, didn't realize chrome was using ffmpeg in the background. That definitely makes it more dangerous than I supposed. Looks like firefox does the same.
      - conradev 11mo ago
        Firefox has moved some parsers to Rust: https://github.com/mozilla/mp4parse-rust https://github.com/mozilla/mp4parse-rust
        rebelwebmaster 11mo ago
        Firefox also does a lot of media decoding in a separate process.
      - xxs 11mo ago
        Pretty much anything that has any video uses the library (incl. youtube)
    - godshatter 11mo ago
      Then maybe the Google chrome devs should submit a PR to ffmpeg.
      - omnicognate 11mo ago
        Sure. And fund them.
      - walletdrainer 11mo ago
        Chrome devs frequently do just that, Chrome just doesn’t enable this codec.
  - manquer 11mo ago
    Ffmpeg is a versatile toolkit used in lot of different places. I would be shocked if any company working with user generated video from the likes of zoom or TikTok or YouTube to small apps all over which do not have it in their pipeline somewhere.
    - deaddodo 11mo ago
      There are alternatives such as gstreamer and proprietary options. I can’t give names, but can confirm at least two moderately sized startups that use gstreamer in their media pipeline instead of ffmpeg (and no, they don’t use gst-libav). One because they are a rust shop and gstreamer is slightly better supported in that realm (due to an official binding), the other because they do complex transformations with the source streams at a basal level vs high-level batch transformations/transcoding.
      - manquer 11mo ago
        There are certainly features and use cases where gstreamer is better fit than ffmpeg. My point was it would be hard to imagine eschewing ffmpeg completely, not that there is no value for other tools and ffmpeg is better at everything. It is so versatile and ubiquitous it is hard to not use it somewhere. In my experience there usually is always some scenarios in the stack where throwing in ffmpeg for a step is simpler and easier even if there no proper language binding etc, for some non-core step or other. From a security context that wouldn't matter, As long it touches data, security vulnerabilities would be a concern. It would be surprising, not that it would impossible to forgo ffmpeg completely. It would be just like this site is written Lisp, not something you would typically expect not impossible.
        deaddodo 11mo ago
        I wasn’t countering your point, I just wanted to add that there are alternatives (well, an alternative in the OSS sphere) that are viable and well used outside of ffmpeg despite its ubiquity.
  - adastra22 11mo ago
    Upload a video to YouTube or Vimeo. They almost certainly run it through ffmpeg.
  - conradev 11mo ago
    ffmpeg is also megabytes of parsing code, whereas tar is barely a parser. It would be surprising to find memory corruption in tar in 2025, but not in ffmpeg.
- afiori 11mo ago
  This is a fantastic argument for the universe where Google does not disclose vulnerability until the maintainers had had reasonable time to fix it. In this world the user is left vulnerable because attackers can use published vulnerabilities that the maintainers are to overwhelmed to fix
  - esrauch 11mo ago
    This program discloses security issues to the projects and only discloses them after they have had a "reasonable" chance to fix it though, and projects can request extensions before disclosure if projects plan to fix it but need more time. Google runs this security program even on libraries they do not use at all, where it's not a demand, it's just whitehat security auditing. I don't see the meaningful difference between Google doing it and some guy with a blog doing it here.
    - XorNot 11mo ago
      Google is a multi-billion dollar company, which is paying people to find these bugs in the first place. That's a pretty core difference.
      - thevillagechief 11mo ago
        Corporate Social Responsibility? The assumption is that the work is good for end users. I don't know if that's the case for the maintainers though.
      - tpmoney 11mo ago
        Great, so Google is actively spending money on making open source projects better and more secure. And for some reason everyone is now mad at them for it because they didn't also spend additional money making patches themselves. We can absolutely wish and ask that they spend some money and resources on making those patches, but this whole thing feels like the message most corporations are going to take is "don't do anything to contribute to open source projects at all, because if you don't do it just right, they're going to drag you through the mud for it" rather than "submit more patches"
- AlienRobot 11mo ago
  If you use a trillion dollar AI to probe open source code in ways that no hacker could, you're kind of unearthing the vulnerabilities yourself if you disclose them.
  - walletdrainer 11mo ago
    This particular bug would be easy to find without any fancy expensive tools.
- nemothekid 11mo ago
  >Are you okay not being told a tool you're using has a vulnerability in it because the devs don't have time to fix it? Yes? It's in the license >NO WARRANTY >15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. If I really care, I can submit a patch or pay someone to. The ffmpeg devs don't owe me anything.
  - inkysigma 11mo ago
    Not being told the existence of bugs is different from having a warranty on software. How would you submit a patch on a bug you were not aware of? Google should provide a fix but it's been standard to disclose a bug after a fixed time because the lack of disclosure doesn't remove the existence of the bug. This might have to be rethought in the context of OSS bugs but an MIT license shouldn't mean other people can't disclose bugs in my project.
    - dotancohen 11mo ago
      Google publicly disclosing the bug doesn't only let affected users know. It also lets attackers know how they can exploit the software. Holding public disclosure over the heads of maintainers if they don't act fast enough is damaging not only to the project, but to end users themselves also. There was no pressing need to publicly disclose this 25 year old bug.
      - tpmoney 11mo ago
        How is having a disclosure policy so that you balance the tradeoffs between informing people and leaving a bug unreported "holding" anything over the heads of the maintainers? They could just file public bug reports from the beginning. There's no requirement that they file non-public reports first, and certainly not everyone who does file a bug report is going to do so privately. If this is such a minuscule bug, then whether it's public or not doesn't matter. And if it's not a minuscule bug, then certainly giving some private period, but then also making a public disclosure is the only responsible thing to do.
- necovek 11mo ago
  As clearly stated, most users of ffmpeg are unaware of them using it. Even them knowing about a vulnerability in ffmpeg, they wouldn't know they are affected. Really, the burden is on those shipping products that depend on ffmpeg: they are the ones who have to fix the security issues for their customers. If Google is one of those companies, they should provide the fix in the given time.
  - tpmoney 11mo ago
    But how are those companies supposed to know they need to do anything unless someone finds and publicly reports the issue in the first place? Surely we're not advocating for a world where every vendor downstream of the ffmpeg project independently discovers and patches security vulnerabilities without ever reporting the issues upstream right?
    - necovek 11mo ago
      If they both funded vulnerability scanning and vulnerability fixing (if they don't want to do it in-house, they can sponsor the upstream team), which is to me the obvious "how", I am not sure why you believe there is only one way to do it. It's about accountability! Who really gets to do it once those who ship it to customers care, is on them to figure out (though note that maintainers will have some burden to review, integrate and maintain the change anyway).
      - tpmoney 11mo ago
        They regularly submit code and they buy consulting from the ffmpeg maintainers according to the maintainer's own website. It seems to me like they're already funding fixes in ffmpeg, and really everyone is just mad that this particular issue didn't come with a fix. Which is honestly not a great look for convincing corporations to invest resources into contributing to upstream. If regular patches and buying dev time from the maintainers isn't enough to avoid getting grief for "not contributing" then why bother spending that time and money in the first place?
- dylan604 11mo ago
  In my case, yes, but my pipeline is closed. Processes run on isolated instances that are terminated without haste as soon as workflow ends. Even if uncaught fatal errors occur, janitor scripts run to ensure instances are terminated on a fast schedule. This isn't something running on my personal device with random content that was provided by unknown someone on the interwebs. So while this might be a high security risk because it possibly could allow RCE, the real-world risk is very low.
- EasyMark 11mo ago
  I have about 100x as much sympathy for an open source project getting time to fix a security bug than I do a multibillion dollar company with nearly infinite resources essentially blackmailing a small team of developers like this. They could -easily- pay a dev to fix the bug and send the fix to ffmpeg.
  - tpmoney 11mo ago
    Since when are bug reports blackmail? If some retro game enthusiast discovered this bug and made a blog post about it that went to the front page of HN, is that blackmail? If someone running a fuzzer found this bug and dumped a public bug report into github is that blackmail? What if google made this report privately, but didn't say anything about when they would make it public and then just went public at some arbitrary time in the future? How is "heads up, here's a bug we found, here's the reproduction steps for it, we'll file a public bug report on it soon" blackmail?
- naasking 11mo ago
  > On the other hand as an ffmpeg user do you care? Are you okay not being told a tool you're using has a vulnerability in it because the devs don't have time to fix it? Yes, because publicly disclosing the vulnerability means someone will have enough information to exploit it. Without public disclosure, the chance of that is much lower.
  - xign 11mo ago
    Public disclosures also means users will know about it and distros can turn off said codec downstream. It's not that hard lol. Information is always better. You may also get third-party contributors who will then be motivated to fix the issue. If no one signs up to do so, maybe this codec should just be permanently shelved. Note that ffmpeg doesn't want to remove the codec because their goal is to play every format known to man, but that's their goal. No one forces them to keep all codecs working.
Lerc 11mo ago
That is standard practice. It is considered irresponsible to not publicly disclose any vulnerability. The X days is a concession to the developers that the public disclosure will be delayed to give them an opportunity to address the issue.
- SpicyLemonZest 11mo ago
  The entire conflict here is that norms about what's considered responsible were developed in a different context, where vulnerability reports were generated at a much lower rate and dedicated CVE-searching teams were much less common. FFmpeg says this was "AI generated bug reports on an obscure 1990s hobby codec"; if that's accurate (I have no reason to doubt it, just no time to go check), I tend to agree that it doesn't make sense to apply the standards that were developed for vulnerabilities like "malicious PNG file crashes the computer when loaded".
  - adastra22 11mo ago
    It is accurate. This is a codec that was added for archival and digital preservation purposes. It’s like adding a Unicode block for some obscure 4000 year old dead language that we have a scant half dozen examples of writing.
  - Lerc 11mo ago
    I think the discussion on what standard practice should be does need to be had. This seems to be throwing blame at people following the current standard. If the obscure coded is not included by default or cannot be triggered by any means other than being explicitly asked for, then it would be reasonable to tag it Won't Fix. If it can be triggered by other means, such as auto file type detection on a renamed file, then it doesn't matter how obscure the feature is, the exploit would affect all. What is the alternative to a time limited embargo. I don't particularly like the idea of groups of people having exploits that they have known about for ages that haven't been publicly disclosed. That is the kind of information that finds itself in the wrong hands. Of course companies should financially support the developers of the software they depend upon. Many do this for OSS in the form of having a paid employee that works on the project. Specifically, FFMPEG seems to have a problem that much of their limitation of resources comes from them alienating contributors. This isn't isolated to just this bug report.
jsnell 11mo ago
> My takeaway from the article was not that the report was a problem, but a change in approach from Google that they’d disclose publicly after X days, regardless of if the project had a chance to fix it. That is not an accurate description? Project Zero was using a 90 day disclosure policy from the start, so for over a decade. What changed[0] in 2025 is that they disclose earlier than 90 days that there is an issue, but not what the issue is. And actually, from [1] it does not look like that trial policy was applied to ffmpeg. > To me its okay to “demand” from a for profit company (eg google) to fix an issue fast. Because they have ressources. But to “demand” that an oss project fix something with a certain (possibly tight) timeframe.. well I’m sure you better than me, that that’s not who volunteering works You clearly know that no actual demands or even requests for a fix were made, hence the scare quotes. But given you know it, why call it a "demand"? [0] https://googleprojectzero.blogspot.com/2025/07/reporting-transparency.html https://googleprojectzero.blogspot.com/2025/07/reporting-tra..., discussed at https://news.ycombinator.com/item?id=44724287 https://news.ycombinator.com/item?id=44724287 [1] https://googleprojectzero.blogspot.com/p/reporting-transparency.html https://googleprojectzero.blogspot.com/p/reporting-transpare...
- joemi 11mo ago
  The fact that details of the issue _will_ be disclosed publicly is an implicit threat. Sure it's not an explicit threat, but it's definitely an implicit threat. So the demand, too, is implicit: fix this before we disclose publicly, or else your vulnerability will be public knowledge.
  - saagarjha 11mo ago
    You should not be threatened by the fact that your software has security holes in it being made public knowledge. If you are, then your goals are fundamentally misaligned with making secure software.
    - joemi 11mo ago
      I don't think that you understand the point of the delayed public disclosure. If it wasn't a threat, then there'd be no need to delay -- it would be publicly disclosed immediately.
Too 11mo ago
Nobody is demanding anything. Google is just disclosing issues. This opens up transparency of ffmpeg’s security posture, giving others the chance to fix it themselves, isolate where it’s run or build on entirely new foundations. All this assuming the reports are in fact pointing to true security issues. Not talking about AI-slop reports.
deleted 11mo ago
[deleted]

by Msurrow 11mo ago

vadansky 11mo ago

On the other hand as an ffmpeg user do you care? Are you okay not being told a tool you're using has a vulnerability in it because the devs don't have time to fix it? I mean someone could already be using the vulnerability regardless of what Google does.

wpm 11mo ago
They could be, and the chances of that increase immensely once Google publishes it.
cogman10 11mo ago
Sure but how. Let's say that FFMPEG has a 10 CVE where a very easy stream can cause it to RCE. So what? We are talking about software commonly for end users deployed to encode their own media. Something that rarely comes in untrusted forms. For an exploit to happen, you need to have a situation where an attacker gets out a exploited media file which people commonly transcode via FFMPEG. Not an easy task. This sure does matter to the likes of google assuming they are using ffmpeg for their backend processing. It doesn't matter at all for just about anyone else. You might as well tell me that `tar` has a CVE. That's great, but I don't generally go around tarring or untarring files I don't trust.
- omnicognate 11mo ago
  AIUI, (lib)ffmpeg is used by practically everything that does anything with video, including such definitely-security-sensitive things as Chrome, which people use to play untrusted content all the time.
  - cogman10 11mo ago
    hmm, didn't realize chrome was using ffmpeg in the background. That definitely makes it more dangerous than I supposed. Looks like firefox does the same.
    - conradev 11mo ago
      Firefox has moved some parsers to Rust: https://github.com/mozilla/mp4parse-rust https://github.com/mozilla/mp4parse-rust
      - rebelwebmaster 11mo ago
        Firefox also does a lot of media decoding in a separate process.
    - xxs 11mo ago
      Pretty much anything that has any video uses the library (incl. youtube)
  - godshatter 11mo ago
    Then maybe the Google chrome devs should submit a PR to ffmpeg.
    - omnicognate 11mo ago
      Sure. And fund them.
    - walletdrainer 11mo ago
      Chrome devs frequently do just that, Chrome just doesn’t enable this codec.
- manquer 11mo ago
  Ffmpeg is a versatile toolkit used in lot of different places. I would be shocked if any company working with user generated video from the likes of zoom or TikTok or YouTube to small apps all over which do not have it in their pipeline somewhere.
  - deaddodo 11mo ago
    There are alternatives such as gstreamer and proprietary options. I can’t give names, but can confirm at least two moderately sized startups that use gstreamer in their media pipeline instead of ffmpeg (and no, they don’t use gst-libav). One because they are a rust shop and gstreamer is slightly better supported in that realm (due to an official binding), the other because they do complex transformations with the source streams at a basal level vs high-level batch transformations/transcoding.
    - manquer 11mo ago
      There are certainly features and use cases where gstreamer is better fit than ffmpeg. My point was it would be hard to imagine eschewing ffmpeg completely, not that there is no value for other tools and ffmpeg is better at everything. It is so versatile and ubiquitous it is hard to not use it somewhere. In my experience there usually is always some scenarios in the stack where throwing in ffmpeg for a step is simpler and easier even if there no proper language binding etc, for some non-core step or other. From a security context that wouldn't matter, As long it touches data, security vulnerabilities would be a concern. It would be surprising, not that it would impossible to forgo ffmpeg completely. It would be just like this site is written Lisp, not something you would typically expect not impossible.
      - deaddodo 11mo ago
        I wasn’t countering your point, I just wanted to add that there are alternatives (well, an alternative in the OSS sphere) that are viable and well used outside of ffmpeg despite its ubiquity.
- adastra22 11mo ago
  Upload a video to YouTube or Vimeo. They almost certainly run it through ffmpeg.
- conradev 11mo ago
  ffmpeg is also megabytes of parsing code, whereas tar is barely a parser. It would be surprising to find memory corruption in tar in 2025, but not in ffmpeg.
afiori 11mo ago
This is a fantastic argument for the universe where Google does not disclose vulnerability until the maintainers had had reasonable time to fix it. In this world the user is left vulnerable because attackers can use published vulnerabilities that the maintainers are to overwhelmed to fix
- esrauch 11mo ago
  This program discloses security issues to the projects and only discloses them after they have had a "reasonable" chance to fix it though, and projects can request extensions before disclosure if projects plan to fix it but need more time. Google runs this security program even on libraries they do not use at all, where it's not a demand, it's just whitehat security auditing. I don't see the meaningful difference between Google doing it and some guy with a blog doing it here.
  - XorNot 11mo ago
    Google is a multi-billion dollar company, which is paying people to find these bugs in the first place. That's a pretty core difference.
    - thevillagechief 11mo ago
      Corporate Social Responsibility? The assumption is that the work is good for end users. I don't know if that's the case for the maintainers though.
    - tpmoney 11mo ago
      Great, so Google is actively spending money on making open source projects better and more secure. And for some reason everyone is now mad at them for it because they didn't also spend additional money making patches themselves. We can absolutely wish and ask that they spend some money and resources on making those patches, but this whole thing feels like the message most corporations are going to take is "don't do anything to contribute to open source projects at all, because if you don't do it just right, they're going to drag you through the mud for it" rather than "submit more patches"
AlienRobot 11mo ago
If you use a trillion dollar AI to probe open source code in ways that no hacker could, you're kind of unearthing the vulnerabilities yourself if you disclose them.
- walletdrainer 11mo ago
  This particular bug would be easy to find without any fancy expensive tools.
nemothekid 11mo ago
>Are you okay not being told a tool you're using has a vulnerability in it because the devs don't have time to fix it? Yes? It's in the license >NO WARRANTY >15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. If I really care, I can submit a patch or pay someone to. The ffmpeg devs don't owe me anything.
- inkysigma 11mo ago
  Not being told the existence of bugs is different from having a warranty on software. How would you submit a patch on a bug you were not aware of? Google should provide a fix but it's been standard to disclose a bug after a fixed time because the lack of disclosure doesn't remove the existence of the bug. This might have to be rethought in the context of OSS bugs but an MIT license shouldn't mean other people can't disclose bugs in my project.
  - dotancohen 11mo ago
    Google publicly disclosing the bug doesn't only let affected users know. It also lets attackers know how they can exploit the software. Holding public disclosure over the heads of maintainers if they don't act fast enough is damaging not only to the project, but to end users themselves also. There was no pressing need to publicly disclose this 25 year old bug.
    - tpmoney 11mo ago
      How is having a disclosure policy so that you balance the tradeoffs between informing people and leaving a bug unreported "holding" anything over the heads of the maintainers? They could just file public bug reports from the beginning. There's no requirement that they file non-public reports first, and certainly not everyone who does file a bug report is going to do so privately. If this is such a minuscule bug, then whether it's public or not doesn't matter. And if it's not a minuscule bug, then certainly giving some private period, but then also making a public disclosure is the only responsible thing to do.
necovek 11mo ago
As clearly stated, most users of ffmpeg are unaware of them using it. Even them knowing about a vulnerability in ffmpeg, they wouldn't know they are affected. Really, the burden is on those shipping products that depend on ffmpeg: they are the ones who have to fix the security issues for their customers. If Google is one of those companies, they should provide the fix in the given time.
- tpmoney 11mo ago
  But how are those companies supposed to know they need to do anything unless someone finds and publicly reports the issue in the first place? Surely we're not advocating for a world where every vendor downstream of the ffmpeg project independently discovers and patches security vulnerabilities without ever reporting the issues upstream right?
  - necovek 11mo ago
    If they both funded vulnerability scanning and vulnerability fixing (if they don't want to do it in-house, they can sponsor the upstream team), which is to me the obvious "how", I am not sure why you believe there is only one way to do it. It's about accountability! Who really gets to do it once those who ship it to customers care, is on them to figure out (though note that maintainers will have some burden to review, integrate and maintain the change anyway).
    - tpmoney 11mo ago
      They regularly submit code and they buy consulting from the ffmpeg maintainers according to the maintainer's own website. It seems to me like they're already funding fixes in ffmpeg, and really everyone is just mad that this particular issue didn't come with a fix. Which is honestly not a great look for convincing corporations to invest resources into contributing to upstream. If regular patches and buying dev time from the maintainers isn't enough to avoid getting grief for "not contributing" then why bother spending that time and money in the first place?
dylan604 11mo ago
In my case, yes, but my pipeline is closed. Processes run on isolated instances that are terminated without haste as soon as workflow ends. Even if uncaught fatal errors occur, janitor scripts run to ensure instances are terminated on a fast schedule. This isn't something running on my personal device with random content that was provided by unknown someone on the interwebs. So while this might be a high security risk because it possibly could allow RCE, the real-world risk is very low.
EasyMark 11mo ago
I have about 100x as much sympathy for an open source project getting time to fix a security bug than I do a multibillion dollar company with nearly infinite resources essentially blackmailing a small team of developers like this. They could -easily- pay a dev to fix the bug and send the fix to ffmpeg.
- tpmoney 11mo ago
  Since when are bug reports blackmail? If some retro game enthusiast discovered this bug and made a blog post about it that went to the front page of HN, is that blackmail? If someone running a fuzzer found this bug and dumped a public bug report into github is that blackmail? What if google made this report privately, but didn't say anything about when they would make it public and then just went public at some arbitrary time in the future? How is "heads up, here's a bug we found, here's the reproduction steps for it, we'll file a public bug report on it soon" blackmail?
naasking 11mo ago
> On the other hand as an ffmpeg user do you care? Are you okay not being told a tool you're using has a vulnerability in it because the devs don't have time to fix it? Yes, because publicly disclosing the vulnerability means someone will have enough information to exploit it. Without public disclosure, the chance of that is much lower.
- xign 11mo ago
  Public disclosures also means users will know about it and distros can turn off said codec downstream. It's not that hard lol. Information is always better. You may also get third-party contributors who will then be motivated to fix the issue. If no one signs up to do so, maybe this codec should just be permanently shelved. Note that ffmpeg doesn't want to remove the codec because their goal is to play every format known to man, but that's their goal. No one forces them to keep all codecs working.

Lerc 11mo ago

That is standard practice. It is considered irresponsible to not publicly disclose any vulnerability. The X days is a concession to the developers that the public disclosure will be delayed to give them an opportunity to address the issue.

SpicyLemonZest 11mo ago
The entire conflict here is that norms about what's considered responsible were developed in a different context, where vulnerability reports were generated at a much lower rate and dedicated CVE-searching teams were much less common. FFmpeg says this was "AI generated bug reports on an obscure 1990s hobby codec"; if that's accurate (I have no reason to doubt it, just no time to go check), I tend to agree that it doesn't make sense to apply the standards that were developed for vulnerabilities like "malicious PNG file crashes the computer when loaded".
- adastra22 11mo ago
  It is accurate. This is a codec that was added for archival and digital preservation purposes. It’s like adding a Unicode block for some obscure 4000 year old dead language that we have a scant half dozen examples of writing.
- Lerc 11mo ago
  I think the discussion on what standard practice should be does need to be had. This seems to be throwing blame at people following the current standard. If the obscure coded is not included by default or cannot be triggered by any means other than being explicitly asked for, then it would be reasonable to tag it Won't Fix. If it can be triggered by other means, such as auto file type detection on a renamed file, then it doesn't matter how obscure the feature is, the exploit would affect all. What is the alternative to a time limited embargo. I don't particularly like the idea of groups of people having exploits that they have known about for ages that haven't been publicly disclosed. That is the kind of information that finds itself in the wrong hands. Of course companies should financially support the developers of the software they depend upon. Many do this for OSS in the form of having a paid employee that works on the project. Specifically, FFMPEG seems to have a problem that much of their limitation of resources comes from them alienating contributors. This isn't isolated to just this bug report.

jsnell 11mo ago

> My takeaway from the article was not that the report was a problem, but a change in approach from Google that they’d disclose publicly after X days, regardless of if the project had a chance to fix it. That is not an accurate description? Project Zero was using a 90 day disclosure policy from the start, so for over a decade. What changed[0] in 2025 is that they disclose earlier than 90 days that there is an issue, but not what the issue is. And actually, from [1] it does not look like that trial policy was applied to ffmpeg. > To me its okay to “demand” from a for profit company (eg google) to fix an issue fast. Because they have ressources. But to “demand” that an oss project fix something with a certain (possibly tight) timeframe.. well I’m sure you better than me, that that’s not who volunteering works You clearly know that no actual demands or even requests for a fix were made, hence the scare quotes. But given you know it, why call it a "demand"? [0] https://googleprojectzero.blogspot.com/2025/07/reporting-transparency.html https://googleprojectzero.blogspot.com/2025/07/reporting-tra..., discussed at https://news.ycombinator.com/item?id=44724287 https://news.ycombinator.com/item?id=44724287 [1] https://googleprojectzero.blogspot.com/p/reporting-transparency.html https://googleprojectzero.blogspot.com/p/reporting-transpare...

joemi 11mo ago
The fact that details of the issue _will_ be disclosed publicly is an implicit threat. Sure it's not an explicit threat, but it's definitely an implicit threat. So the demand, too, is implicit: fix this before we disclose publicly, or else your vulnerability will be public knowledge.
- saagarjha 11mo ago
  You should not be threatened by the fact that your software has security holes in it being made public knowledge. If you are, then your goals are fundamentally misaligned with making secure software.
  - joemi 11mo ago
    I don't think that you understand the point of the delayed public disclosure. If it wasn't a threat, then there'd be no need to delay -- it would be publicly disclosed immediately.

Too 11mo ago

Nobody is demanding anything. Google is just disclosing issues. This opens up transparency of ffmpeg’s security posture, giving others the chance to fix it themselves, isolate where it’s run or build on entirely new foundations. All this assuming the reports are in fact pointing to true security issues. Not talking about AI-slop reports.

deleted 11mo ago

[deleted]