26 ms·

FFmpeg to Google: Fund us or stop sending bugs

• JamesBarney 1y ago
  I get the idea of publicly disclosing security issues to large well funded companies that need to be incentivized to fix them. But I think open source has a good argument that in terms of risk reward tradeoff, publicly disclosing these for small resource constrained open source project probably creates a lot more risk than reward.
  • Msurrow 1y ago
    In addition to your point, it seems obvious that disclosure policy for FOSS should be “when patch available” and not static X days. The security issue should certainly be disclosed - when its responsible to do so. Now, if Google or whoever really feels like fixing fast is so important, then they could very well contribute by submitting a patch along with their issue report. Then everybody wins.
    • danlitt 1y ago
      > it seems obvious that disclosure policy for FOSS should be “when patch available” and not static X days This is very far from obvious. If google doesn't feel like prioritising a critical issue, it remains irresponsible not to warn other users of the same library.
      • Msurrow 1y ago
        If that’s the case why give the OSS project any time to fix at all before public disclosure? They should just publish immediately, no? Warn other users asap.
        • danlitt 1y ago
          Why do you think it has to be all or nothing? They are both reasonable concerns. That's why reasonable disclosure windows are usually short but not zero.
        • GabrielTFS 1y ago
          Full (immediate) disclosure, where no time is given to anyone to do anything before the vulnerability is publicly disclosed, was historically the default, yes. Coordinated vulnerability disclosure (or "responsible disclosure" as many call it) only exists because the security researchers that practice it believe it is a more effective way of minimizing how much the vulnerability might be exploited before it is fixed.
        • saagarjha 1y ago
          Because it gives maintainers a chance to fix the issue, which they’ll do if they feel it is a priority. Google does not decide your priorities for you, they just give you an option to make their report a priority if you so choose.
        • xign 11mo ago
          Timed disclosure is just a compromise between giving project time and public interests. People have been doing this for years now. Why are people acting like this is new just because ffmpeg is whining? And occasionally you do see immediate disclosures (see below). This usually happens for vulnerabilities that are time-sensitive or actively being exploited where the user needs to know ASAP. It's very context dependent. In this case I don't think that's the case, so there's a standard delayed disclosure to give courtesy for the project to fix it first. Note the word "courtesy". The public interest always overrides considerations for the project's fragile ego after some time. (Some examples of shortened disclosures include Cloudbleed and the aCropalypse cropping bug, where in each case there were immediate reasons to notify the public / users)
      • foolswisdom 1y ago
        Part of the problem is that many of the issues are not really critical, no?
      • afiori 1y ago
        Unless the maintainers are incompetent or uncooperative this does not feel like a good strategy. It is a good strategy on Google's side because it is easier for them to manage
    • derf_ 1y ago
      > ...then they could very well contribute by submitting a patch along with their issue report. I don't want to discourage anyone from submitting patches, but that does not necessarily remove all (or even the bulk of) the work from the maintainers. As someone who has received numerous patches to multimedia libraries from security researchers, they still need review, they often have to be rewritten, and most importantly, the issue must be understood by someone with the appropriate domain knowledge and context to know if the patch merely papers over the symptoms or resolves the underlying issue, whether the solution breaks anything else, and whether or not there might be more, similar issues lurking. It is hard for someone not deeply involved in the project to do all of those things.
    • tpmoney 1y ago
      > In addition to your point, it seems obvious that disclosure policy for FOSS should be “when patch available” and not static X days. So when the xz backdoor was discovered, you think it would have been better to sit on that quietly and try to both wrest control of upstream away from the upstream maintainers and wait until all the downstream projects had reverted the changes in their copies before making that public? Personally I'm glad that went public early. Yes there is a tradeoff between speed of public disclosure and publicity for a vulnerability, but ultimately a vulnerability is a vulnerability and people are better off knowing there's a problem than hoping that only the good guys know about it. If a Debian bug starts tee-ing all my network traffic to the CCP and the NSA, I'd rather know about it before a patch is available, at least that way I can decide to shut down my Debian boxes.
      • Orygin 1y ago
        The XZ backdoor is not a bug but a malicious payload inserted by malicious actors. The security vulnerability would immediately been used as it was created by attackers. This bug is almost certainly too obscure to be found and exploited in the time the fix can be produced by Ffmpeg. On the other hand, this vuln being public so soon means any attacker is now free to develop their exploit before a fix is available. If Google's goal is security, this vulnerability should only be disclosed after it's fixed or a reasonable time (which, according to ffmpeg dev, 90 days is not enough because they receive too many reports by Google).
        • tpmoney 1y ago
          A bug is a bug, regardless of the intent of the insertion. You have no idea if this bug was or wasn't intentionally inserted. It's of course very likely that it wasn't, but you don't and can't know that, especially given that malicious bug insertion is going to be designed to look innocent and have plausible deniability. Likewise, you don't know that the use of the XZ backdoor was imminent. For all you know the intent was to let it sit for a release or two, maybe with an eye towards waiting for it to appear in a particular down stream target, or just to make it harder to identify the source. Yes, just like it is unlikely that the ffmpeg bug was intentional, it's also unlikely the xz backdoor was intended to be a sleeper vulnerability. But ultimately that's my point. You as an individual do not know who else has access or information about the bug/vulnerability you have found, nor do you have any insight into how quickly they intend to exploit that if they do know about it. So the right thing to do when you find a vulnerability is to make it public so that people can begin mitigating it. Private disclosure periods exist because they recognize there is an inherent tradeoff and asymmetry in making the information public and having effective remediations. So the disclosure period attempts to strike a balance, taking the risk that the bug is known and being actively exploited for the benefit of closing the gap between public knowledge and remediation. But inherently it is a risk that the bug reporter and the project maintainers are forcing on other people, which is why the end goal must ALWAYS be public disclosure sooner rather than later.
  • Ygg2 1y ago
    > publicly disclosing these for small resource constrained open source project probably creates a lot more risk than reward. Not publicly disclosing it also carries risk. Library users get wrong impression that library has no vulnerabilities, while numerous bugs are reported but don't appear due to FOSS policy.
  • phoronixrly 1y ago
    You are missing the tiny little fact that apparently a large portion of infosec people are of the opinion that insecure software must not exist. At any cost. No shades of gray.
  • NobodyNada 1y ago
    > publicly disclosing these for small resource constrained open source project probably creates a lot more risk than reward. You can never be sure that you're the only one in the world that has discovered or will discover a vulnerability, especially if the vulnerability can be found by an LLM. If you keep a vulnerability a secret, then you're leaving open a known opportunity for criminals and spying governments to find a zero day, maybe even a decade from now. For this one in particular: AFAIK, since the codec is enabled by default, anyone who processes a maliciously crafted .mp4 file with ffmpeg is vulnerable. Being an open-source project, ffmpeg has no obligation to provide me secure software or to patch known vulnerabilities. But publicly disclosing those vulnerabilities means that I can take steps to protect myself (such as disabling this obscure niche codec that I'm literally never going to use), without any pressure on ffmpeg to do any work at all. The fact that ffmpeg commits themselves to fixing known vulnerabilities is commendable, and I appreciate them for that, but they're the ones volunteering to do that -- they don't owe it to anyone. Open-source maintainers always have the right to ignore a bug report; it's not an obligation to do work unless they make it one. Vulnerability research is itself a form of contribution to open source -- a highly specialized and much more expensive form of contribution than contributing code. FFmpeg has a point that companies should be better about funding and contributing to open-source projects that they rely on, but telling security researchers that their highly valuable contribution is not welcome because it's not enough is absurd, and is itself an example of making ridiculous demands for free work from a volunteer in the open-source community. It sends the message that white-hat security research is not welcome, which is a deterrent to future researchers from ethically finding and disclosing vulnerabilities in the future. As an FFmpeg user, I am better off in a world where Google disclosed this vulnerability -- regardless of whether they, FFmpeg, or anyone else wrote a patch -- because a vulnerability I know about is less dangerous than one I don't know about.
  • arccy 1y ago
    But if open source is reliant on public contributors to fix things, then the bug should be open so anyone can take a stab at fixing it, rather than relying on the closed group of maintainers
• ranger_danger 1y ago
  Wouldn't they just fork it, fix their own bugs and stop contributing at all?
  • wewewedxfgdf 1y ago
    That costs cash and the big tech companies are a little short at the moment.
  • blibble 1y ago
    Google internally maintaining a fork that attempts to track upstream has a ongoing cost that increases over time vs. spamming OSS maintainers with slop reports costs Google nothing
    • esrauch 1y ago
      Is there really slop here though? It sounds like the specific case identified was a real use after free in an obscure file format but which is enabled by default. If it was slop they could complain that it was wasting their time on false or unimportant reports, instead they seem to be complaining that the program reported a legitimate security issue?
      • kastagg 1y ago
        If a maintainer complains about slop bug reports, instead of assuming the worst of the maintainer, it'll often be more productive to put yourself in their shoes and consider the context. An individual case may simply be the nth case in a larger picture (say, the straw that broke the camel's back). Whenever this nth case is observed, if you only consider that single case, a response also informed by detailed personal consideration of the preceding (n-1) cases may appear grossly and irrationally disproportionate, especially when the observer isn't personally that involved. For a human, generating bug reports requires a little labor with a human in the loop, which imposes a natural rate limit on how many reports are submitted, which also imposes a natural triaging of whether it's personally worth it to report the bug. It could be worth it if you're prosocially interested in the project or if your operations depend on it enough that you are willing to pay a little to help it along. For a large company which is using LLMs to automatically generate bug reports, the cost is much lower (indeed it may be longer-term profitable from a standpoint like marketing, finding product niches, refining models, etc.) This can be asymmetric with the maintainer's perspective, where the quality and volume of reports matter in affecting maintainer throughput and quality of life.
• lenerdenator 1y ago
  They obviously need to be reminded that the only reason Google has to care about FLOSS projects is when they can effectively use them to create an advertising panopticon under the company's complete control.
• ganelonhb 1y ago
  Not too fond of maintainers getting too uppity about this stuff. I get that it can be frustrating to receive bug report after bug report from people who are unwilling or unable to contribute to the code base, or at the very least to donate to the team. But the way I see it, a bug report is a bug report, no matter how small or big the bug or the team, it should be addressed. I don’t know, I’m not exactly a pillar of the FOSS community with weight behind my words.
  • calcifer 1y ago
    > it can be frustrating to receive bug report after bug report from people As the article states, these are AI-generated bug reports. So it's a trillion-dollar company throwing AI slop over the wall and demanding a 90-day turn around from unpaid volunteers.
    • ikiris 1y ago
      Do you have evidence of ai slop, or are you just spreading fud? The linked bug was acknowledged as real.
      • Gualdrapo 1y ago
        That is completely irrelevant, the gross part is that (if true) they are demanding them to be fixed in a given time. Sounds like the epitome of entitlement to me, to say the least.
        • ikiris 1y ago
          No one is demanding anything, the report itself is a 90 day grace period before being publicly published. If the issues are slop then what exactly is your complaint?
      • ehutch79 1y ago
        google literally tells them it's an ai generated report
• chemotaxis 1y ago
  I am fairly confident that this article is largely AI-generated. More generally, the whole site appears to be heavy on AI slop, e.g.: https://thenewstack.io/how-ai-is-pushing-kubernetes-storage-beyond-its-limits/ https://thenewstack.io/how-ai-is-pushing-kubernetes-storage-... And maybe it's fine to have AI-generated articles that summarize Twitter threads for HN, but this is not a good summarization of the discussion that unfolded in the wake of this complaint. For one, it doesn't mention a reply from Google security, which you would think should be pretty relevant here.
  • BoredPositron 1y ago
    Like the bug report in question... poetic.
    • mrob 1y ago
      The bug report in question is obviously written by a human: https://issuetracker.google.com/issues/440183164?pli=1 https://issuetracker.google.com/issues/440183164?pli=1 It's of excellent quality. They've made things about as easy for the FFmpeg devs as possible without actually fixing the bug, which might entail legal complications they want to avoid. AI was only used to find the bug.
      • BoredPositron 1y ago
        "obviously". You have 0 evidence for your comment. Big sleep is credited as reporter.
        • mrob 1y ago
          Thinking about it, "obviously written by a human" is not actually true. It's more accurate to say "no obvious signs of being written by AI".
• profsummergig 1y ago
  A bunch of people who make era-defining software for free. A labor of love. Another bunch of people who make era-defining software where they extract everything they can. From customers, transactionally. From the first bunch, pure extraction (slavery, anyone?).
  • ivell 1y ago
    Irrespective of what Google does, security research is still useful for all of us. They could adopt a more flexible policy for FOSS though.
    • doctorwho42 1y ago
      Or they could contribute solutions to said bugs? Its not like they would distract that much from their bottom line
      • SR2Z 1y ago
        Google is a major contributor to open-source video, to the point where it would not be viable without them.
        • FridgeSeal 1y ago
          [flagged]
          • SR2Z 1y ago
            Look, I know you're being snarky, but YES. All of the viable open-source video codecs of the past 10 years would not have happened without Google. Not just for technical reasons, but for expensive patent-related legal reasons too. Given that ffmpeg is an open-source video transcoding tool, I don't think you can easily just dismiss this as "big company abuses open source." The ffmpeg devs are volunteers or paid to work on specific parts of the tool. That's why they're unimpressed. What Google is doing here is pretty reasonable.
• immibis 1y ago
  Google might be aiming to replace ffmpeg as the world's best media professor. Remember how Jia Tan (under different names) flooded xz with work before stepping up as a maintainer.
  • favorited 1y ago
    Google, through YouTube and YouTube TV, already runs one of the most significant video processing lines of business in the world. If they had any interest in supplanting FFmpeg with their own software stack, they wouldn't need to muck around with CVEs to do so.
    • immibis 1y ago
      Not for themselves, but for everyone else for some reason. Though it's more likely there's just some team tasked with shoving AI into vulnerability hunting.
• woodruffw 1y ago
  I’m an open source maintainer, so I empathize with the sentiment that large companies appear to produce labor for unpaid maintainers by disclosing security issues. But appearance is operative: a security issue is something that I (as the maintainer) would need to fix regardless of who reports it, or would otherwise need to accept the reputational hit that comes with not triaging security reports. That’s sometimes perfectly fine (it’s okay for projects to decide that security isn’t a priority!), but you can’t have it both ways.
  • Msurrow 1y 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 1y 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 1y ago
        They could be, and the chances of that increase immensely once Google publishes it.
      • cogman10 1y 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.
• prewett 1y ago
  "They could shut down three product lines with an email" If you (Amazon, in this case) can put it that way, it seems like throwing them 10 or 20 thousand a year would simply be a good insurance policy! Any benefits you might get in goodwill and influence are a bonus.
  • kwanbix 1y ago
    How do you think Jeff got a 500 million dollars yacht? Not by writing checks. But on a more serious note, it is crazy that between Google and Amazon they can not fund them with 50k each per year, so that they can pay people to work on this. Specially Google, with Youtube, they can very easily pay them more. 100k~200k easily.
    • BowBun 1y ago
      Double funny considering new-grads who may polish up some UI features or rewrite components for the 10th time will get paid 200-400K TC at these same companies. Evidently these companies value something other than straight labor.
      • kwanbix 1y ago
        Yeah, sadly crazy.
    • doctorwho42 1y ago
      What's wild is the importance and impact of the work/tool. And for google and Amazon, $50k-$100k/yr isn't even a single engineer salary to them ... And they get the tool + community good will, all for a rounding error on any part of their budgets...
      • kwanbix 1y ago
        Exactly. That is why I said easily 100~200k. It will be a rounding error for them. It is actually crazy that Google is not already hiring the main dev to work on ffmpeg with all the use they give it on Youtube. I also wonder if it is maybe used by Netflix also.
• benced 1y ago
  This is dumb. Obscurity doesn’t create security. It’s unfortunate if ffmpeg doesn’t have the money to fix reported bugs but that doesn’t mean they should be ignorant of them. I don’t see any entitlement out of Google either - I expected this article would have a GH issue thread with a whiny YouTube engineer yelling at maintainers.
  • ivell 1y ago
    Agreed that obscurity is not security. However we don't want to make it easy for hackers to get a catalog of vulnerabilities to pick and choose from. I think the issue is public disclosure of vulnerabilities after a deadline. The hobbyists can't just keep up.
  • unsungNovelty 1y ago
    The first thing you can do is actually read the article. The question is not about the security reports but Google's policy on disclosing the vulnerability after x days. It works for crazy lazy corps. But not for OSS projects.
    • GabrielTFS 1y ago
      In practice, it doesn't matter all that much whether the software project containing the vulnerability has the resources to fix it: if a vulnerability is left in the software, undisclosed to the public, the impact to the users is all the same. I, and I think most security researchers do too, believe that it would be incredibly negligent for someone who has discovered a security vulnerability to allow it to go unfixed indefinitely without even disclosing its existence. Certainly, ffmpeg developers do not owe security to their users, but security researchers consider that they have a duty to disclose them, even if they go unfixed (and I think most people would prefer to know an unfixed vulnerability exists than to get hit by a 0-day attack). There's gotta be a point where you disclose a vulnerability, the deadline can never be indefinite, otherwise you're just very likely allowing 0-day attacks to occur (in fact, I would think that if this whole thing never happened and we instead got headlines in a year saying "GOOGLE SAT ON CRITICAL VULNERABILITY INVOLVED IN MASSIVE HACK" people would consider what Google did to be far worse). To be clear, I do in fact think it would be very much best if Google were to use a few millionths of a percent of their revenue to fund ffmpeg, or at least make patches for vulnerabilities. But regardless of how much you criticize the lack of patches accompanying vulnerability reports, I would find it much worse if Google were to instead not report or disclose the vulnerability at all, even if they did so at the request of developers saying they lacked resources to fix vulnerabilities.
• palmotea 1y ago
  > Many in the FFmpeg community argue, with reason, that it is unreasonable for a trillion-dollar corporation like Google, which heavily relies on FFmpeg in its products, to shift the workload of fixing vulnerabilities to unpaid volunteers. That's capitalism, they need to quit their whining or move to North Korea. /s The whole point is to maximize value to the shareholders, and the more work they can shove onto unpaid volunteers, the move money they can shove into stock buybacks or dividends. The system is broken. IMHO, there outta be a law mandating reasonable payments from multi-billion dollar companies to open source software maintainers.
• ikiris 1y ago
  Its a special kind of irony to post AI slop complaining about someone's ai slop that isn't actually ai slop just devs whining about being expected to maintain their code instead of being able to extort the messengers to do the work for them.
  • AlexandrB 1y ago
    If they're not being paid, they're under no obligation to "maintain their code". If you don't like it, don't use ffmpeg. It's not "whining" to refuse to do unpaid labor for the benefit of someone else - especially when the someone else is as well-resourced as Google.
• deleted 1y ago
  [deleted]
• righthand 1y ago
  They probably want to drown you in CVEs to force deprecation on the world and everybody into their system like they do with everything else they touch.
• DeepYogurt 1y ago
  We're well past the point that any serious security team should be able to submit a fix along with a bug report.
• justahuman74 1y ago
  Does Google seriously not have a whole team of people who help maintain ffmpeg?
  • adastra22 1y ago
    Yes. But they don’t upstream. Why would they?
    • justahuman74 1y ago
      Great, they can fix the bugs being filed by another part of their company
      • Ferret7446 1y ago
        So would you rather Google have a secure ffmpeg while us plebian individual users continue to have an insecure ffmpeg?
        • GaryBluto 1y ago
          It's frustrating to me how many people are siding with FFmpeg here considering how unprofessional and generally asshole-ish they are being. I feel that this is mostly a kneejerk reaction to AI and Google in general, with people coming up with arguments to support their reaction after already forming an opinion.
          • NoGravitas 1y ago
            It's a volunteer project, they have no requirement to be 'professional'. That's basically the root of the whole issue. A hobby project is not a product, and its developers are not vendors. Free software is not a supply chain.
            • Dylan16807 1y ago
              The word "unprofessional" here is muddying the comment more than it helps. Let's just saying they're being asshole-ish, which is a problem for volunteer projects just as much as non-volunteer ones. The ffmpeg twitter sucks.
• mrs6969 1y ago
  this is why you should release your opensource project with the license of being free only for individual, not for enterprises. enterprise must pay.
  • fph 1y ago
    If it's not free for enterprises then it's not open source, according to the commonly accepted definition.
    • mrs6969 1y ago
      Being open source and being free are entirely different things though. You can view, read the code = open source. The latter is about money.
      • fph 1y ago
        Open source is not only about being able to read the code: the open source definition includes "Free Redistribution" (anyone who has the software can give away copies, and get paid if they want) and "No Discrimination Against Fields of Endeavor", among other requirements. These two requirements combined make it impossible to distribute open source software with the provision that it is only free for individuals.
• warmwaffles 1y ago
  Just mark CVEs as bugs and get to them when you can. In this case, if Google doesn't like it, then so be it. It'll get fixed eventually. Don't like how long it takes? Pay someone to contribute back. Until then, hurry up and wait.
  • adastra22 1y ago
    That’s how you get your open source software removed from distributions and eventually forked.
    • cubefox 1y ago
      Forked by people who are quicker at fixing security vulnerabilities than the original maintainers?
      • adastra22 1y ago
        Sure, for some definition of “vulnerability.” And only doing that, nothing more.
    • warmwaffles 1y ago
      And that's a problem?
• phkahler 1y ago
  From TFA this was telling: Thus, as Mark Atwood, an open source policy expert, pointed out on Twitter, he had to keep telling Amazon to not do things that would mess up FFmpeg because, he had to keep explaining to his bosses that “They are not a vendor, there is no NDA, we have no leverage, your VP has refused to help fund them, and they could kill three major product lines tomorrow with an email. So, stop, and listen to me … ” I agree with the headline here. If Google can pay someone to find bugs, they can pay someone to fix them. How many time have managers said "Don't come to me with problems, come with solutions"
  • skrebbel 1y ago
    How could ffmpeg maintainers kill three major AWS product lines with an email?
    • zxspectrum1982 1y ago
      Easy: ffmpeg discontinues or relicenses some ffmpeg functionality that AWS depends on for those product alines and AWS is screwed. I've seen that happen in other open source projects.
      • portaouflop 1y ago
        Wouldn’t that only affect new versions and current versions are still licensed under the old license ?
      • NewsaHackO 1y ago
        But if it gets relicensed, they would still be able to use the current version. Amazon definitely would be able to fund an independent fork.
        • wewtyflakes 1y ago
          Sounds like it would be a lot of churn for nothing; if they can fund a fork, then they could fund the original project, no?
• deleted 1y ago
  [deleted]
• pjmlp 1y ago
  Fully on FFmpeg team side, many companies approach to FOSS is only doing so when it sounds good on their marketing karma, leech otherwise. Most of them would just pirate in the old days, and most FOSS licences give them clear conscience to behave as always.
  • PeaceTed 1y ago
    This is why many have warned against things like MIT licence. Yes, it gives you source code and does easily get incorporated into a lot of projects but it comes at the cost of potential abuse. Yes, GPL 3 is a lot ideologically but it was trying to limit excessive leeching. Now that I have opened the flood gates of a 20 year old debate, time to walk away.
    • esrauch 1y ago
      Google Project Zero just looks for security issues in popular open source packages, regardless of if Google itself even uses those packages or not. So I'm not sure what GPLv3 really has to do with it in this case, if it under was a "No billion dollar company allowed" non-free-but-source-available license, this same thing would have happened if the project was popular enough for Project Zero to have looked at it for security issues.
      • cestith 1y ago
        The difference is that Google does use it, though. They use it heavily. All of us in the video industry do - Google, Amazon, Disney, Sony, Viacom, or whoever. Companies you may have never heard of build it into their solutions that are used by big networks and other streaming services, too.
        • esrauch 1y ago
          Right, Google absolutely should fund ffmpeg. But opening security issues here is not related to that in any way. It's an obscure file format Google definitely doesn't use, the security issue is irrelevant to Google's usages of it. The critique would make sense if Google was asking for ffmpeg to implement something that Google wanted, instead of sending a patch. But they don't actually care about this one, they aren't actually asking for them to fix it for their benefit, they are sending a notice of a security issue that only affects people who are not Google to ffmpeg.
• andrewstuart 1y ago
  “How dare ffmpeg be so arrogant! Don’t they know who we are? Fork ffmpeg and kill the project! I grant a budget of 30 million to crush this dissent! Open source projects must know who’s boss! I’ll stomp em like a union!” …. overheard at a meeting of CEO and CTO at generic evil mega tech corp recently.
• theoldgreybeard 1y ago
  The vulnerability in question is a Use After Free. Google used AI to find this bug, it would've taken them 3 seconds to fix it. Burning cash to generate spam bug reports to burden volunteer projects when you have the extra cash to burn to just fix the damn issue leaves a very sour taste in my mouth.
  • V__ 1y ago
    Notably, the vulnerability is also in a part which isn't included by default and nobody uses. I'm not sure that even warrants a CVE? A simple bug report would have probably been fine. If they think this is really a CVE, a bug fix commit would have been warranted.
    • immibis 1y ago
      AIUI there's no such thing as "really a CVE". A CVE is merely a standardized identifier for a bug so you can call it "CVE-2025-XXXXX" rather than "that use-after-free Google found in ffmpeg with AI." It doesn't imply anything else about the bug, except that it may impact security. The Linux kernel assigns one to every bugfix that may impact security (which is most kernel bugs) to avoid controversy about whether they should be assigned.
    • dieortin 1y ago
      It is included by default
    • oskarkk 1y ago
      It is included in most builds of ffmpeg, for example in most Linux packages or in Windows build linked to on ffmpeg.org that I use. But yeah, it's a very niche format that nobody uses.
    • deleted 1y ago
      [deleted]
    • esrauch 1y ago
      One problem here is that CVE scoring is basically entirely bugged, something scored 8.7 could be an RCE exploit or a "may be able to waste CPU" issue. That's the difference between "it may or may not be that there's someone who cares" versus "no one should be running this software anywhere in the general vicinity of untrusted inputs".
• section_me 1y ago
  FFmpeg should just dual license at this point. If you're wanting shit fixed. You pay for it (based on usage) or GTFO. Should solve all of the current issues around this.
  • shevy-java 1y ago
    You mean, Google reports a bug, and ffmpeg devs say "GTFO"? Let's assume this is a real bug: is that what you would the ffmpeg developers to say to Google? I absolutely understand the issue that a filthy-rich company tries to leech off of real unpaid humans. I don't understand how that issue leads to "GTFO, we won't fix these bugs". That makes no sense to me.
    • GaryBluto 1y ago
      People would rather spitefully stub their toe after being warned of the table's location by someone they don't like rather than take heed.
• dbl000 1y ago
  I don't understand the rational for announcing that a vulnerability in project X was discovered before the patch is released. I read the project zero blogspot announcement but it doesn't make much sense to me. Google claims this is help downsteam users but that feels like a largely non-issue to me. If you announce a vulnerability (unspecified) is found in a project before the patch is released doesn't that just incentivize bad actors to now direct their efforts at finding a vulnerability in that project?
  • inkysigma 1y ago
    Maybe for a small project? I think the difference here is rather minimal. Everybody "knows" code often has security bugs so this announcement wouldn't technically be new information. For a large project such as ffmpeg, I doubt there is a lack of effort in finding exploits in ffmpeg given how widely it is used. I don't see why actors would suddenly reallocate large amounts of effort especially since a patch is now known to be coming for the issue that was found and thus the usefulness of the bug (even if found) is rather limited.
  • saagarjha 1y ago
    The reason for this policy is that if you don’t keep a deadline upstream can just sit on the report forever while bad actors can find and exploit the vulnerabilities, which harms downstream users because they are left entirely unaware that the vulnerability even exists. The idea behind public disclosure is that downstream is now made aware of the bug and can take appropriate action on their side (for example, by avoiding the software, sponsoring a fix, etc.)
  • Bratmon 1y ago
    "Don't announce an unpatched vulnerability ever" used to be the norm. It caused a massive problem: most companies and organizations would never patch security vulnerabilities, so vulnerabilities would last years or sometimes decades being actively exploited with nobody knowing about it. Changing the norm to "We don't announce unpatched vulnerabilities but there is a deadline" was a massive improvement.
• ironman1478 1y ago
  Never work for free. It's a complete market distortion and leads to bad actors taking advantage of you and your work.
  • samdoesnothing 1y ago
    Yep.
  • PeaceTed 1y ago
    I love the spirit of working for free on a project of passion. But yes it only takes a few bad actors to totally exploit it.
    • kome 1y ago
      use GPL
      • NoGravitas 1y ago
        AGPL at a minimum. Some kind of copyfarleft license if a corporation exploiting your code is a serious concern.
  • gtsop 1y ago
    [dead]
  • shevy-java 1y ago
    That's fine. Are they required to work for Google? I mean, they are independent and can decide on their own.
    • ironman1478 1y ago
      Corporations extract a ton of value from projects like ffmpeg. They can either pay an employee to fix the issues or setup some sort of contract with members of the community to fix bugs or make feature enhancements. There is precedent for this: https://sqlite.org/consortium.html https://sqlite.org/consortium.html
• bogwog 1y ago
  Is it time for FFmpeg to relicense as AGPL? That'd be fun to witness.
  • PeaceTed 1y ago
    Watch places like Amazon and Google suddenly stop updating and trying to find alternatives. Like how Apple stopped using up to date the GNU tools in 2008 because of GPL3. That moved showed me then that Apple did not want you to use your computer as your computer.
    • isr 1y ago
      Well, to continue that timeline. "Big Tech" freezes their version to the last gpl'ed version, and each commences their own (non-trivial effort) to make their own version (assuming the last gpl'ed version was not feature-complete for all their future uses). And of course, they won't share with each other. So another driver would be fear of a slight competitive disadvantage vs other-big-tech-monstrosity having a better version. Now, in this scenario, some tech CEO, somewhere has this brilliant bright spark. "Hey, instead of dumping all these manhours & resources into DIYing it, with no guarantee that we still won't be left behind - why don't we just throw 100k at the original oss project. We'll milk the publicity, and ... we won't have to do the work, and ... my competitors won't be able to use it" I quite like this scenario.
      • halapro 1y ago
        Imagine Google paying only 100k to ffmpeg though. That's like a single 3-month top-SWE pay at Google.
  • Ferret7446 1y ago
    It'll just get forked (see terraform)
    • jeroenhd 1y ago
      Terraform didn't get licensed as AGPL, just some weird proprietary license. It'll still cause Google and many others to panic, but weird and custom licenses are even worse for attracting business than open source ones.
• bhouston 1y ago
  I would suggest that FFmpeg spin up a commercial arm that gets support contracts with Google, Amazon, etc, but with a tight leash so that it does not undermine the open source project. Would need clean guidance as to what the commercial arm does and does not. Probably could pull in millions per year.
  • portaouflop 1y ago
    If it just were that simple. The reality is that this is a very slippery slope and you won’t get a support contract just like that with a “tight leash”
  • garciasn 1y ago
    While I don't think FFmpeg's response is a great one ("fund us or stop submitting bugs"); I think Google is being pretty shitty here. For a company that prides itself in its engineering prowess and contributions to the OSS community (as they like to remind me all the time) to behave this way is just all around shitty. Submit the bug AND the patch and be done with it; don't make it someone else's problem when it's an OSS library/tool. A for-profit vendor? Absolutely. But this? Hell naw.
  • shevy-java 1y ago
    In general it is not good when companies get too much power. See how shopify is eating away the ruby infrastructure right now after RubyCentral panicked when shopify blackmailed the community by taking away funding. Of course it is their money, but the whole ecosystem suddenly submitting to one huge company, really really sucks to no ends. Hobbyists are at the weakest here.
  • astrange 1y ago
    If FFmpeg had a commercial operation it would constantly be getting sued for IP issues.
  • tpmoney 1y ago
    According to https://xcancel.com/argvee/status/1986194861855478213#m https://xcancel.com/argvee/status/1986194861855478213#m, google is a customer of fflabs.eu (https://fflabs.eu https://fflabs.eu) which is just such a "support contracts" arm. Certainly the fflabs.eu site claims at the bottom that Netflix, Google and Meta are all customers of theirs and the site also claims that their team is comprised of a number of ffmpeg contributors including the "lead maintainer" (https://fflabs.eu/about/ https://fflabs.eu/about/). Additionally, a search of the git commits shows a regular stream of commits from `google.com` addresses. So as near as I can tell, Google does regularly contribute code to the project, they are a customer of the project maintainer's commercial support company (and that fact is on the support company's website) and they submit high quality bug reports for vulnerabilities. What are we mad about again?
• aweiher 1y ago
  Please bro, please, fix our bugs bro, just this one bug bro, last one I swear, you and I will make big money, you are the best bro, I love you bro. -- big tech companies
• ksynwa 1y ago
  What is the point of Google's Project Zero? I'm not being dismissive. I understand the imperetive of identifying and fixing vulnerabilities. I also understand the detrimental impact that these problems can potentially have on Google. What I don't understand is the choice to have a public facing project about this. Can anyone shine a light on this?
  • rsanek 1y ago
    I would imagine it's mostly a PR/marketing thing. That way the researchers can point to being part of something other people know about, and Google gets positive PR (though maybe not in this case) for spending resources on making software in general more secure.
    • dkdcio 1y ago
      you could not imagine and just read sources like https://en.wikipedia.org/wiki/Project_Zero https://en.wikipedia.org/wiki/Project_Zero
  • khuey 1y ago
    Project Zero's public existence came out of the post-Snowden period where Google was publicly pissed at the NSA/etc for spying on them (e.g. by tapping their fiber links).
  • jeroenhd 1y ago
    A lot of their research involves stuff they personally benefit from if they were secure. ffmpeg, libxml2, various kinds of mobile device firmware, Linux kernels and userspace components, you name it. Their security team gaining experience on other projects can teach them some more diversity in terms of (malware) approaches and vulnerability classes, which can in turn be used to secure their own software better. For other projects there's some vanity/reputation to be gained. Having some big names with impressive resumes publicly talk about their work can help attract talent. Lastly, Google got real upset that the NSA spied on them (without their knowledge, they can't help against warrants of course). Then again, there's probably also some Silicon Valley bullshit money being thrown around. Makes you wonder why they don't invest a little bit more to pay someone to submit a fix.
• HackerThemAll 1y ago
  FFmpeg should stop fixing security bugs reported by Google, MS, Amazon, Meta etc. and instead wait for security patches from them. If FFmpeg maintainers will leave it exposed, those companies will rush to fixing it, because they'd be screwed otherwise. Every single one of them is dependent on FFmpeg exactly as shown in https://xkcd.com/2347/ https://xkcd.com/2347/
  • shevy-java 1y ago
    I understand the problem of corporations leeching off of the community here. I still fail to see why "ffmpeg is not allowed to fix bugs reported by corporations" is a good strategy. To me this sounds not logical.
    • lenerdenator 1y ago
      Because they are making more money in profit than some mid-sized American cities' economies do in a year while contributing nothing back. If they don't want massive security vulnerabilities in their services using FFmpeg, maybe they need to pony up about .1 seconds' worth of their quarterly earnings to the project either in cash or in manpower. It's not FFmpeg's problem if someone uses a vulnerability to pwn YouTube, it's Google's problem. Also, in the article, they mention that Google's using AI to look for bugs and report them, and one of them that it found was a problem in the code that handles the rendering of a few frames of a game from 1995. That sort of slop isn't helping anyone. It's throwing the signal-to-noise ratio of the bug filings way the hell off.
      • tpmoney 1y ago
        If they contribute nothing back, what are all the `google.com` email addresses in the git history doing? If they contribute nothing back, why are they listed as a customer of `fflabs.eu` which is apparently a private consulting company for ffmpeg run by some of the ffmpeg lead maintainers? What do we think the lesson corporations are going to take from this is? 1) "You should file patches with your bug reports" 2) "Even when you submit patches and you hire the developers of OSS projects as consultants, you will still get dragged through the mud if you don't contribute a patch with every bug report you make, so you might as well not contribute anything back at all"
• iscoelho 1y ago
  It’s a reproducible use-after-free in a codec that ships by default with most desktop and server distributions. The recent iOS zero-day (CVE-2025-43300) targeted the rarely used DNG image format. How long before this FFMPEG vulnerability is exploited to compromise legacy devices in the wild, I wonder? I’m not a fan of this grandstanding for arguably questionable funding. (I surely would not fund those who believe these issues are slop.) I’d like to think most contributors already understand the severity and genuinely care about keeping FFMPEG secure.
  • jeffbee 1y ago
    Bugs in little-used corners of the project are a massive red flag, that's how some of the most serious OpenSSL bugs have emerged. If the code is in there, and someone can trigger it with a crafted input, then it is as bad as any other bug.
  • Espressosaurus 11mo ago
    DNG isn't exactly rarely used, it's Adobe's open raw format and lots of image processing programs read and write it. It's not a codec made for one game back in 1994, it's still in very active use today if you're using such a rare and uncommon program as Photoshop.
    • iscoelho 11mo ago
      I agree it is a widely used format, however, it is rarely used on iOS devices.
• vsgherzi 1y ago
  I understand ffmpeg being angry at the workload but this is how it is with large open source projects. Ffmpeg has no obligation to fix any of this. Open source is a gift and is provided as is. If Google demanded a fix I could see this being an issue. As it is right now it just seems like a bad look. If they wanted compensation then they should change the model, there's nothing wrong with that. Google found a bug, they reported it. If it's a valid bug then it's a valid bug end of story. Software owes it to its users to be secure, but again it's up to the maintainers if they also believe that. Maybe this pushes Google to make an alternative, which I'd be excited for.
  • otherme123 1y ago
    >Ffmpeg has no obligation to fix any of this I read this as nobody wants CVEs open on their product, so you might feel forced to fix them. I find it more understandable if we talk about web frameworks: Wordpress don't want security CVEs open for months or years, or users would be upset they introduce new features while neglecting safety. I am a nobody, and whenever I found a bug I work extra to attach a fix in the same issue. Google should do the same.
    • vsgherzi 1y ago
      Why is there an onus on Google to fix this? Bug bounty hunters aren’t required to submit a patch even when the target is open source. Now should Google? Probably, it would be nice but no one has to. The gift from Google is the discovery of the bug.
  • themafia 1y ago
    > Google found a bug That does not impact their business or their operations in any way whatsoever. > If it's a valid bug then it's a valid bug end of story. This isn't a binary. It's why CVEs have a whole sordid scoring system to go along with them. > Software owes it to its users to be secure ffmpeg owes me nothing. I haven't paid them a dime.
    • jeroenhd 1y ago
• ChrisMarshallNY 1y ago
  Looks like this was a security issue. I don't consider a security issue to be a "standard bug." I need to look at it, and [maybe] fix it, regardless of who reported it. But in my projects, I have gotten requests (sometimes, demands) that I change things like the published API (a general-purpose API), to optimize some niche functionality for one user. I'll usually politely decline these, and respond with an explanation as to why, along with suggestions for them to add it, after the fact.
  • cestith 1y ago
    It’s a security issue for a stream type almost nobody uses. It’s a little like saying your graphics program in 2025 is exploitable by a malformed PCX file, or your music player has a security bug only when playing an Impulse Tracker module. Sure, triage it. It shouldn’t be publicly disclosed within a week of the report though, because the fix is still a relatively low priority.
    • jsnell 1y ago
      Security is adversarial. It doesn't matter whether the users intentionally use the vulnerable codec. What matters is whether an adversary can make the users to use it. Given the codec is compiled in by default on Ubuntu, and given that IIUC the bug would already be triggered by ffmpeg's file format probing, it seems pretty likely that the answer to that is yes.
      • cestith 1y ago
        Yes, security is by definition adversarial. Thanks for the most basic lesson. How are you getting ffmpeg to process a stream or file type different from the one you’re expecting? Most use cases of ffmpeg are against known input and known output types. If you’re just stuffing user-supplied files through your tools, then yes you have a different threat model.
        • jsnell 1y ago
          > How are you getting ffmpeg to process a stream or file type different from the one you’re expecting? ... That is how ffmpeg works? With default settings it auto-detects the input codec from the bitstream, and the output codec from the extension. You have to go out of your way to force the input codec and disable the auto-detection, and I don't think most software using ffmpeg as a backend would force the user to manually do it, because users can't be trusted to know those details.
• Seattle3503 1y ago
  > “The position of the FFmpeg X account is that somehow disclosing vulnerabilities is a bad thing. Google provides more assistance to open source software projects than almost any other organization, and these debates are more likely to drive away potential sponsors than to attract them.” This position likely to drive away maintainers. Generally the maintainers need these projects less than the big companies that use them. I'm not sure what Google's endgame is
  • DeepYogurt 1y ago
    I doubt there's an endgame in mind. It's probably small teams trying to optimize their quarterly KPIs
  • strictnein 1y ago
    > FFmpeg X account is that somehow disclosing vulnerabilities is a bad thing I mean, I follow that account and never got this impression from them at all.
• zach_moore 1y ago
  Google is evil.
• skybrian 1y ago
  Here's a thread by Google's head of security that notes the ways they've contributed to FFmpeg over the years: https://x.com/argvee/status/1986194852669964528 https://x.com/argvee/status/1986194852669964528
  • FridgeSeal 1y ago
    Unfortunately, nobody not on Twitter can see anything except the first message, which just appears to be some corporate-deflection-speak. It’s a trillion dollar company. I’m sure they could find rifle through their couch cushions and find more than enough money and under-utilised devs to contribute finance or patches.
    • tom_ 1y ago
      Try xcancel instead: https://xcancel.com/argvee/status/1986194852669964528 https://xcancel.com/argvee/status/1986194852669964528
    • deleted 1y ago
      [deleted]
    • izacus 1y ago
      Google is one of the largest contributors to OSS in the world, so they're already throwing literal millions at OSS?
      • Jyaif 1y ago
        They have thousands of highly paid employees working on open source; they are spending at least 1 billion per year.
      • FridgeSeal 1y ago
        I’m sure they can take a moment of their _busy schedules_ to send a patch then. Especially if they’ve just spent all this cash on some ai tool.
        • 1y ago
• shevy-java 1y ago
  Hmmmmmm. I can understand both points but ... Google is under no obligation to work on FFmpeg. Google leveraging AI to spam ffmpeg devs with bugs that range from real to obscure to wrongly reported may be annoying. But even then I still don't think Google is to be held accountable for reporting bugs nor is it required to fix bugs. Note: I do think Google should help pay for costs and what not. If they were a good company they would not only report bugs but also have had developers fix the bugs, but they are selfish and greedy, everyone knows that. Even then they are not responsible for bugs in ffmpeg. And IF the bug report is valid, then I also see no problem. The article also confuses things. For instance: "Many in the FFmpeg community argue, with reason, that it is unreasonable for a trillion-dollar corporation like Google, which heavily relies on FFmpeg in its products, to shift the workload of fixing vulnerabilities to unpaid volunteers" How could Google do that? It is not Google's decision. That is up to volunteers. If they refuse to fix bug reports reported from Google then this is fine. But it is THEIR decision, not Google. "With this policy change, GPZ announces that it has reported an issue on a specific project within a week of discovery, and the security standard 90-day disclosure clock then starts, regardless of whether a patch is available or not." Well, many opinions here. I think ALL bugs and exploits should be INSTANTLY AND WITHOUT ANY DELAY, be made fully transparent and public. I understand the other side of the medal too, bla bla we need time to fix it bla bla. I totally understand it. Even then I believe the only truthful, honest way to deal with this, is 100% transparency at all times. This includes when there are negative side effects too, such as open holes. I believe in transparency, not in secrecy. There can not be any compromise here IMO. "Many volunteer open source program maintainers and developers feel this is massively unfair to put them under such pressure when Google has billions to address the problem." So what? Google reports issues. You can either fix that or not. Either way is a strategy. It is not Google's fault when software can be exploited, unless they wrote the code. Conversely, the bug or flaw would still exist in the code EVEN IF GOOGLE WOULD NOT REPORT IT. So I don't understand this part. I totally understand the issue of Google being greedy, but this here is not solely about Google's greed. This is also how a project deals with (real) issues (if they are not real then you can ask Google why they send out so much spam). That Google abuses AI to spam down real human beings is evil and shabby. I am all for ending Google on this planet - it does so much evil. But either it is a bug, or not. I don't understand the opinion of ffmpeg devs "because it is Google, we want zero bug reports". That just makes no sense. "The fundamental problem remains that the FFmpeg team lacks the financial and developer resources to address a flood of AI-created CVEs." Well, that is more an issue in how to handle Google spamming down people. Sue them in court so that they stop spamming. But if it is a legit bug report, why is that a problem? Are ffmpeg devs concerned about the code quality being bad? If it is about money then even though I think all of Google's assets should be seized and the CEOs that have done so much evil in the last 20 years be put to court, it really is not their responsibility to fix anything written by others. That's just not how software engineering works; it makes no sense. It seems people confuse ethics with responsibilities here. The GPL doesn't mandate code fixing to be done; it mandates that if you publish a derivative etc... of the code, that code has to be published under the same licence and made available to people. That's about it, give or take. It doesn't say corporations or anyone else HAS to fix something. "On the other hand, security experts are certainly right in thinking that FFmpeg is a critical part of the Internet’s technology framework and that security issues do need to be made public responsibly and addressed." I am all for that too, but even stricter - all security issues are to be made public instantly, without delay, fully and completely. I went to open source because I got tired of Microsoft. Why would I want to go back to evil? Not being transparent here is no valid excuse IMO. "The reality is, however, that without more support from the trillion-dollar companies that profit from open source, many woefully underfunded, volunteer-driven critical open-source projects will no longer be maintained at all." Wait - so it is Google's fault if projects die due to lack of funding? How does that explanation work? You can choose another licence model. Many choose BSD/MIT. Others choose GPL. And so forth. "For example, Wellnhofer has said he will no longer maintain libxml2 in December. Libxml2 is a critical library in all web browsers, web servers, LibreOffice and numerous Linux packages. We don’t need any more arguments; we need real support for critical open source programs before we have another major security breach." Yes, that is a problem - the funding part. I completely agree. I still don't understand the "logic" of trying to force corporations to have to do so when they are not obliged. If you don't want corporations to use your code, specify that in the licence. The GPL does not do that. I am confused about this "debate" because it makes no real sense to me from an objective point of view. The only part that I can understand pisses off real humans is when Google uses AI as a pester-spam attack orgy. Hopefully a court agrees and spits up any company with more than 100 developers into smaller entities the moment they use AI to spam real human beings.
• egypturnash 1y ago
  The Tragedy of the Bazaar.
• deepriverfish 1y ago
  why don't they just ignore Goole and work at their own pace?
• lamontcg 1y ago
  They should set up a foundation/LLC if they don't have one already and require a support contract for fixing any bugs in niche codecs. Target the 95%-98% use cases for "free" work. If someone gives them a CVE on something ancient, just note it with an issue tracker and that the problem is currently unsponsored. Have default build flags to omit all the ancient/buggy stuff. If nobody is willing to pay to fix all the ancient crap, then nobody should be using it. But if someone is willing to pay, then it gets fixed.
  • woodruffw 1y ago
    https://fflabs.eu https://fflabs.eu Edit: Notably, Google is a paying client of FFmpeg's consulting entity.
• mclanett 1y ago
  What happens if ffmpeg ignores (after triage) the minor CVEs?
  • gowld 1y ago
    Life goes on.
• firefax 1y ago
  Is it unreasonable to ask that if a massive company funds someone to find a CVE in an open source project, they should also submit a patch? Google is a search company. Seems kind of... evil... to pay your devs to find holes in something with nothing to do with searching, then refuse to pay them to fix the problem they noticed.
  • tpmoney 1y ago
    Google contributes to ffmpeg on a fairly regular basis https://git.ffmpeg.org/gitweb/ffmpeg.git/search/HEAD?s=@google.com;st=author https://git.ffmpeg.org/gitweb/ffmpeg.git/search/HEAD?s=@goog... No it's not "unreasonable" to ask for patches along with bug fixes, but it is unreasonable to be mad if they don't. They could just not file the bug reports at all, and that is an objectively worse outcome.
    • rossjudson 1y ago
      Note that most open source contributions by Googlers are, as recommended by policy, done under their own personal accounts. There's a required registry internally mapping from their personal account to their @google.com identity. The nice thing is that the open source contributions done by a Googler aren't necessarily tied to their Google identity.
    • firefax 1y ago
      >No it's not "unreasonable" to ask for patches along with bug fixes, but it is unreasonable to be mad if they don't Your stance seems to be is that it is unreasonable to be annoyed by someone who is being unreasonable. When I searched for synonyms for "unreasonable" in a major English language thesarus, the following synonyms were listed: indefensible, mindless, reasonless, senseless, unjustified, untenable, unwarranted So yes, it absolutely is valid for the FFMPEG crew to feel trolled by Project Zero.
      • Dylan16807 1y ago
        > Your stance seems to be is that it is unreasonable to be annoyed by someone who is being unreasonable. No, that's not their stance. You talked about whether ffmpeg was reasonable. They talked about whether ffmpeg was unreasonable. You never accused google of being unreasonable, and they never mentioned it either. So this idea of "responding to google being unreasonable" is a brand new premise. And I'm pretty sure they would disagree with that premise.
• vzaliva 1y ago
  Is it me or the linked article seems to be heavily co-authored by AI. The cadence is very monotonic and dull.
• erikerikson 1y ago
  There are some rhetorical slights of hand. If Google does the work to find and report vulnerabilities, great. Nice contribution regardless of who provides it. The OSS developer can ignore it by accepting the consequences that will be. They are not forced to fix it except by themselves. The many large corporations should be funding these tools they depend on to increase time allocations and thus ability to be responsive but this isn't an either/or. These type of thinking erode the communities of such projects and minds of the contributors. FWIW I've totally been that developer trapped in that perspective so I empathize, there are simply better mental stances available.
• renewiltord 1y ago
  Amusing. I suppose the intended optional behavior is for Google to fix internally then run the public PR. Less optimal for us normal users since the security issue will be visible publicly in the PR until merging, though it won't affect Google (who will carry the fixed code before disclosure).
• kentonv 1y ago
  Honestly, I kind of think that ffmpeg should just document that it's not secure and that you're expected to run it in a sandbox if you plan to use it on possibly-malicious input. All the big cloud users and browsers are doing this already, so it would hardly even change anything. ffmpeg is complaining that security bugs are such a drag that it's driving people away from their hobby/passion projects. Well, if fixing security bugs isn't your passion, why not just say that? Say it's not your priority, and if someone else wants it to be a priority, they can write the patches. Problem solved?
  • arcfour 1y ago
    Why be reasonable when you can just grandstand (about people that do actually provide you with funding) on Twitter? Surely that's more fun, right?
• dbg31415 1y ago
  This whole thing is sure a tangle. Open source projects want people to use their work. Google wants bugs -- especially security ones -- found and fixed fast. Both goals make sense. The tension starts when open source developers expect payment for fixes, and corporations like Google expect fixes for free. Paying for bug fixes sounds fair, but it risks turning incentives upside down. If security reports start paying the bills, some maintainers might quietly hope for more vulnerabilities to patch. That's a dangerous feedback loop. On the other hand, Google funding open source directly isn't automatically better. Money always comes with strings. Funding lets Google nudge project priorities, intentionally or not -- and suddenly the "open" ecosystem starts bending toward corporate interests. There's no neat solution. Software wants to be used. Bugs want to be found and fixed. But good faith and shared responsibility are supposed to be the glue that holds the open source world together. Maybe the simplest fix right now is cultural, not technical: fewer arguments on Twitter, more collaboration, and more gratitude. If you rely on open source, donate to the maintainers who make your life easier. The ecosystem stays healthy when we feed it, not when we fight over it.
• qwertytyyuu 1y ago
  bug reports are still good... but yeah they really should contribute to development too
• honktown 1y ago
  It'd be a silly license or condition, but, a license that says employees of companies in the S&P500 cant file bugs without an $X contribution, and cant expect a response in under Y days without a larger one, would be a funny way to combat it. Companies have no problem making software non-free or AGPL when it becomes inconvenient so maybe they can put up or shut up.
  • tpmoney 1y ago
    Where in this bug report was there any expectation for a response? They filed a private bug report and have a policy of making private reports public in 90 days whether or not they get a response. How did the OSS world go from "with enough eyes all bugs are shallow" to "filing a bug report is demanding I respond to you"?
  • Aurornis 1y ago
    > cant file bugs without an $X contribution, and cant expect a response in under Y days A license to define that nobody can expect a response? Or file bugs? None of this has anything to do with the issue. They can just turn off Google’s access to the bug tracker. No license needed. However Google is free to publish security research they find. It would be most concerning if projects started including “Nobody is allowed to do security research on this project” licenses. Who would benefit from that?
• w_for_wumbo 1y ago
  The message sounds like a human warning of someone is being fed-up with feeling taken advantage of. They see the profit being made, and they're not even getting drops of it. If this isn't addressed, it makes this repo a target for actors that don't care about the welfare of Amazon, Google etc. It seems quite predictable that someone will see this as a human weakness and try to exploit it, my question is whether we'll get them the support they need before the consequence hits, or whether we'll claim this was a surprise after the fact.
  • tpmoney 1y ago
    > They see the profit being made, and they're not even getting drops of it. Doesn't google routinely contribute to ffmpeg? Certainly there's a lot of commits from `@google.com` email addresses here: https://git.ffmpeg.org/gitweb/ffmpeg.git?a=search&h=HEAD&st=author&s=%40google.com https://git.ffmpeg.org/gitweb/ffmpeg.git?a=search&h=HEAD&st=...
• gverrilla 1y ago
  People volunteer to make billionaires even more profit - crazy world. Who even have the time and resources to volunteer so much??? I don't get all this at all.
  • kastagg 1y ago
    The mixture of motivations includes a desire to contribute something to humanity, a desire to make a mark or achieve recognition, or a desire to gain experience that might enhance your ability to get hired. It can be a hobby like model trains and it can be a a social context like joining a club or going to church. But it's safe to say that nobody is volunteering "to make billionaires even more profit."
• noduerme 1y ago
  I remember Rebel Assault 2... how did an AI bot even discover a specific vulnerability in ASM that surfaces when playing the first 10-20 frames of some video from that?
• hitekker 1y ago
  [flagged]
  • taviso 1y ago
    why would you post such a patently absurd accusation.
    • hitekker 1y ago
      I saw that tweet and thought it looked crazy. To me, it sounds like a death threat. Especially given that it's posted on X.com, after a really heated argument, with no clarification afterwards. If you didn't actually post that tweet, that's great! I'm happy to be corrected
      • taviso 1y ago
        If you hear a rumor that sounds too crazy to be true on social media, maybe don't repeat it as fact. Imagine how you would feel reading something like that.
        • ffmpeger 1y ago
          It's not a rumor, you literally wrote that on X. The average person would understand it as a threat.
          • Dylan16807 1y ago
            You felt the need to make a new account for that bad take? Jeez.
  • Scion9066 1y ago
    Popped in that context means hacked. Like in the same usage of pop in "popping a shell". I do not think he meant it as any kind of physical/death threat.
• est 1y ago
  So Chromium is going to drop video support because ffmpeg is full of bugs, just like libxlst ? /s
• dboreham 1y ago
  So many of these threads recently. The abstract pattern is: people are surprised that many other people who one might reasonably expect should give you money or resources, or otherwise behave in a cooperative reasonable way, are psychopaths and don't do that.
• tonymet 1y ago
  Given the cost of discovering these issues, and the massive risk of exploitation, it’s likely that Google/Amazon/etc have them fixed in their private forks. Fixing a private fork takes 1/5-1/10 the time of shepherding a PR to meet the maintainers expectations. And why spend 5x dev time to contribute fixes to your competitor?
• alberth 1y ago
  Similar event happened 2-years ago, but with Microsoft https://news.ycombinator.com/item?id=39912916 https://news.ycombinator.com/item?id=39912916
  • Dylan16807 1y ago
    That was not similar. The Microsoft dev was demanding things and rightfully shamed over it. Everyone giving Google the same shame over reporting an exploitable bug with no expectations is being ridiculous.
• lynx97 1y ago
  2025 is the year where I finally have to ask myself: "What is Google actually doing for me?" and the answer is "Nothing". I am no longer able to search with Lynx. I had to move to startpage.com for that. I never used, and never will, gmail or any other of their oservices, except for YouTube (which they bought). YouTube search is finally totally unusable, pushing short form content onto me which I really really don't care about. I have to click the "Show me less shorts" button on my iPhone every few weeks, because the stuff keeps coming back. I don't care about their AI summaries, I was always happy (when I was still able to use Google in my daily workflow) with the excerpt they were giving me since what, 2002? I don't have an Android phone, because their Accessibility was lacking behind for almost two decades. They dropped the "Don't be evil" motto. ... Where do I even stop? Google used to be great. Now, all they do for me is to maintain storage for my TV-replacement, YouTube. I say maintain storage, because that is all they do. I can't even meaningfully search that content. I have given up on them. It is over.
• linuxhansl 1y ago
  I used to be paid for a decade to work on open source software - by my employer. We always upstreamed fixes. This is the only way. Filing bugs, etc, is also has some value, but if a big company uses a piece of open source software and makes money with it (even indirectly), they can contribute engineering time (or money).
• alvinveroy 1y ago
  [dead]
• deleted 1y ago
  [deleted]
• aiiizzz 1y ago
  The death of ffmpeg has been foretold.
• bfkwlfkjf 1y ago
  And this is why Stallman invented copyleft. Stallman was right.
  • izacus 1y ago
    ffmpeg is copyleft by Stallmans design.
• halapro 1y ago
  So what if ffmpeg has open CVEs? What is Google going to do? Swap it? Leave them open, let Google ship products with CVE'd dependencies, and then they'll be forced to act. Why would Google act if they got smart guys working for them for free? Stop fixing Google-reported bugs.
  • magicalhippo 1y ago
    > So what if ffmpeg has open CVEs? Part of the issue is that FFmpeg is almost a meta-project. It contains so many possible optional dependencies. Which is great for features, nit so great if you quickly want to know if you're exposed to the latest CVE.
• 22c 1y ago
  Sidenote from the article, but TIL Mark Atwood is no longer at Amazon.
• 0xDEAFBEAD 1y ago
  How about a hybrid open source license, where the software is free for anyone to use unless they're a commercial entity with $1B or greater in annual revenue? Google might even prefer this deal, if it means more maintainer activity and fewer vulnerabilities.
• nektro 1y ago
  FFmpeg is a great project but their twitter is embarrassing and should not be news
  • u_sama 1y ago
    Why, their Twitter seems reasonable and combative towards companies who want to exploit their results without contribution ?
    • zgk7iqea 1y ago
      google is a customer of fflabs and has enrolled them in summer of code. They also provide free fuzzing. ffmpeg is a foss, gpl-licensed project. nobody has any obligation to contribute, thus it isn't exploitation.
    • arcfour 1y ago
      This take sounds great until you realize this is literally Google using their resources to help an open source project (by reporting issues in it that ALREADY EXIST and NEED to be fixed OR users made aware if not fixed) AND they also help them by upstreaming patches (just not for this specific issue) regularly AND with monetary support. So...your entire premise is patently false and wrong.
• wjholden 1y ago
  This is not the first article I've seen where developers say they're getting overwhelmed by AI-generated bug reports. Maybe this is a new way people can volunteer to help open source. If anyone is struggling to triage bug reports in a Rust open source project, please contact me and I will see if this is something I can donate some recurring time to.
• isaacfrond 1y ago
  Only accepting bugs with a fix is not a solution. Because who is going to vet the patches? Are you going to accept a Chinese patch for some obscure security issue? This is how real security problems are introduced.
  • homebrewer 1y ago
    Why not? The three letters are not going to send their backdoored patches under a pseudonym people like you would find suspicious. They would send it (and very likely are doing that already) under the name of "James Smith". You really should check out much much code in e.g. the Linux kernel is written outside of "the West". It's not the 90s anymore.
• trashb 1y ago
  So to me it seems notifications of bugs is good, you want to create visibility of problems. The problem is the pressure to fix the bugs in x amount of time otherwise they will be made public. Additionally flooding the team with so many bugs that they can never keep up. Perhaps the solution is not in do or don't submit but in the way how the patches are submitted. I think a solution would be to have a separate channel for these big companies to submit "flood" bug reports generated by AI, and if those reports won't be disclosed in x amount of time that would also take the pressure of the maintainers, the maintainers can set priories to most pressing issues and keep the backlog of smaller issues that may require attention in the future (or be picked up by small/new contributors).
• deleted 1y ago
  [deleted]
• firesteelrain 1y ago
  There is incentive for people like Dan from ChainGuard to point out these issues. It makes what his company does seem more important
• codeptualize 1y ago
  I think the glaring issue underlying this is that the big companies are not investing enough in the tools they rely on. I agree with some of the arguments that patching up vulnerabilities is important, but it's crazy to put that expectation on unpaid volunteers when you flood them with CVE's some completely irrelevant. Also the solution is fairly simple: Either, you submit a PR instead of an issue. Or, you send a generous donation with the issue to reward and motivate the people who do the work. The amount of revenue they generate using these packages will easily offset the cost of funding the projects, so I really think it's a fair expectation for companies to contribute either by delivering work or funds.
  • Propelloni 1y ago
    The solution is even simpler. The project puts the bug report in its triage backlog. It works through it in its own time, and decides on severity and priority. That's the time-honored method. The compounding factor here is the automated reporting and disclosure process of Google's Project Zero. GPZ automatically discloses bugs after 90 days. Even if Google does not expect bugs to be fixed within this period, the FFmpeg devs clearly feel pressure. But it is an open source project, basically a hobby for most devs. Why accept pressure at all? Continue to proceed in the time-honored method. If and when Youtube explodes because of a FFmpeg bug, Google has only itself to blame. They could have done something but decided to freeload. I really don't see the issue.
    • amelius 1y ago
      Is it legal to disclose security vulnerabilities within such a short period? It certainly does not seem ethically correct.
• bawolff 1y ago
  If ffmpeg doesn't want to recieve bug reports that's their right. They better not complain when google goes full disclosure on them. They are essentially asking for it at this point.
• andriamanitra 1y ago
  As much as I hate to be on Google's side I think they're doing a reasonable thing here. Valid bug reports are valuable contributions on their own, and disclosing security issues is standard practice. Not disclosing them doesn't help anyone. Security through obscurity is not security. If neither FFMPEG nor Google dedicate resources to fixing the issue in 90 days, making it public at least ensures that it gets visibility and thus has a higher chance to get fixed by a third party. I'm sure Google could (and probably should) do even more to help, but FFMPEG directing social media rage at a company for contributing to their project is a bone-headed move. There are countless non-Google companies relying on FFMPEG that do much less for the project, and a shit show like this is certainly not going to encourage them to get involved.
  • mrkiouak 1y ago
    As someone who worked as a software engineer at Google on a service that heavily depended on FFmpeg, its absurd that Google posts security bugs (which have the obvious potential outcome of driving more free work) vs just paying an engineer to fix the bug. I promise they are spending more on extra compute for resiliency and redundancy for FFMPEG issues than it would cost for a single SWE to just write a fix and then shepherd through the FFmpeg approval process.
    • mrkiouak 1y ago
      Bonus comment: I was present for conversations about how Google should just write an internal version because of all the stability issues, but that that work would never get prioritized or be considered valuable because it wouldn't get anyone promoted (to be fair, given how widely FFmpeg is used, it would have gotten an L4 or L5 promoted, but it would have been a near sisyphean task over years to get to the point where you could demostrate the ridiculously high XXm-XXXm returns that would come from just helping to improve FFmpeg).
    • cyberrock 1y ago
      As someone who was on a project that stalled for a year because our patchset wasn't accepted by a different open source project (not Linux either), I can tell you from experience that it's not as easy as folks here make it out to be. Some maintainers (and Googlers) really want you to study at their mountaintop monastery before your code is worthy, and scrutiny is even higher now due to AI, as we can see from the complaints about this bug report. Now, I've merged enough open source patches on my personal time to know that most projects aren't like that, but based on this interaction, I seriously wonder if Google's patch would've been accepted without incident. Maybe AmaGoogSoft deserves this, but then what's the threshold? If I'm in charge of Zoom or Discord and one of my engineers finds a bug, should I let them report it and risk a public blow-up? Or does my company's revenue need to be below $1B? $100M? This just poisons the well for everyone.
• nubinetwork 1y ago
  Related https://news.ycombinator.com/item?id=45785291 https://news.ycombinator.com/item?id=45785291
• xnx 1y ago
  This feels like getting upset when someone tells you your shoe is untied.
• gcr 1y ago
  They should consider switching to Affero GPL. Now _that_ would fuck the industry up… I’m only half joking by the way.
• LucavagoHellman 1y ago
  [dead]
• gcr 1y ago
  The bug that ignited this was discovered by an AI security analyst agent. I think it’s more than reasonable to demand that if the AI finds bugs, then the AI should spend a couple cents and output patches.
• h14h 1y ago
  Should Google be doing more to support ffmpeg? Yes. Should Google stop devoting resources to identifying and reporting security vulnerabilities in ffmpeg? I cannot bring myself to a mindset where my answer to this question is also "yes". It would be one thing if Google were pressuring the ffmpeg maintainers in their prioritization decisions, but as far as I can tell, Google is essentially just disclosing that this vulnerability exists? Maybe the CVE process carries prioritization implications I don't fully understand. Eager to be educated if that is the case.
  • 0xpgm 11mo ago
    So clearly there's only one correct answer here? Which is what the ffmpeg folks are driving at
• duxup 1y ago
  I'm amazed any open source volunteers aren't more upfront with "lol yeah I'll get to it, maybe, someday" more often. God bless you guys.
• ratelimitsteve 1y ago
  is this a fundamental problem with the open source model, though? if we work within a model of continuous refinement and improvement but also accept the constraint that there's a fundamental limit to the resources someone is willing to give up in exchange for nothing (whether the resource in question is dev effort for no money or money for no ownership stake in the final product) then you see where something infinite is running up against something infinite and there's just no way to square that.
• elzbardico 1y ago
  Unfortunately, and now even more with GenAI, a lot of Open Source boils down to doing free Labor to rich capitalists get even more rich while making sure we kill a lot of small business our professional class could have started.
• deleted 1y ago
  [deleted]
• insane_dreamer 1y ago
  > it is unreasonable for a trillion-dollar corporation like Google, which heavily relies on FFmpeg in its products, to shift the workload of fixing vulnerabilities to unpaid volunteers. They believe Google should either provide patches with vulnerability reports or directly support the project’s maintenance. This is so basic it shouldn't even have to be said.
  • Dylan16807 1y ago
    The first part is technically true but doesn't apply to this situation. "Shift the workload"? This isn't google's bug, and google doesn't need it fixed. It was never their workload, and has not been shifted. The last part is just wrong. Google does directly support the project's maintenance.
    • insane_dreamer 1y ago
      It wasn't paying the people who it was expecting to fix the bug.
• junthehacker 1y ago
  I think the main issue is the 90 day disclosure. Maybe Google can allow the maintainers to extend that deadline for low / medium impact issues. I see no reason to follow the 90 day timeline if the maintainer is working on it. Especially considering it is very possible for Google to overwhelm a project with thousands of vulnerability reports. Otherwise, I don't think Google should issue a patch, just like in this case, only FFmpeg people know it is an obscure codec that nobody really uses, and maybe the reasonable approach would be to simply remove it. Google don't know that, unless they somehow take over the project. And AFAIK Google is one of the biggest sponsor for SPI, which is the fiscal sponsor for ffmpeg. So not sure where the not paying thing came from.
• deleted 1y ago
  [deleted]
• iamsaitam 11mo ago
  The problem lies in the fact that these companies are generating work for volunteers on a different time-scale and binding them to it by giving them X days before disclosing vulnerabilities. No one wants their project to have security vulnerabilities that might affect a lot of users, which creates pressure in dealing with them. The open source model is broken in this regard, licenses need to address revenue and impose fees on these companies, which can be used as bug bounties. Game engines do this and so should projects like FFMPEG, etc. The details are complex of course, but the current status quo is abusing people's good will.
• T3RMINATED 11mo ago
  [dead]
• SergeAx 11mo ago
  I don't get the logic behind the FFmpeg stance. They have no obligation to fix any bugs, and they are not liable if someone exploits those vulnerabilities, as per the license. Thus, the parties interested in fixes are free to patch bugs at their own expense or pay someone else to do it. Anyways, fixes will end up in the FFmpeg codebase or in other GNU-licensed fork of it, available to cherry-pick.