[HN Gopher] FFmpeg to Google: Fund us or stop sending bugs
___________________________________________________________________
FFmpeg to Google: Fund us or stop sending bugs
Author : CrankyBear
Score : 358 points
Date : 2025-11-11 18:32 UTC (4 hours ago)
(HTM) web link (thenewstack.io)
(TXT) w3m dump (thenewstack.io)
| JamesBarney wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| foolswisdom wrote:
| Part of the problem is that many of the issues are not
| really critical, no?
| afiori wrote:
| 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_ wrote:
| _> ...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.
| Ygg2 wrote:
| > 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 wrote:
| 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 wrote:
| > 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.
| ranger_danger wrote:
| Wouldn't they just fork it, fix their own bugs and stop
| contributing at all?
| blibble wrote:
| 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 wrote:
| 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?
| immibis wrote:
| Probably what they want to do once the original project burns
| out
| dboon wrote:
| Forking puts you in another hell as Google. Now you have to pay
| someone to maintain your fork! Maybe for a project that's well
| and fully complete that's OK. But something like FFmpeg is
| gonna get updated all the time, as the specs for video codecs
| are tweaked or released.
|
| Their choice becomes to: - maintain a complex fork, constantly
| integrating from upstream. - Or pin to some old version and
| maybe go through a Herculean effort to rebase when something
| they truly must have merges upstream. - Or genuinely fork it
| and employ an expert in this highly specific domain to write
| what will often end up being parallel features and security
| patches to mainline FFmpeg.
|
| Or, of course, pay someone in doing OSS to fix it in mainline.
| Which is the beauty of open source; that's genuinely the least
| painful option, and also happens to be the one that benefits
| the community the most.
| inerte wrote:
| If you're going to fix the bug, why not in the main project?
| ranger_danger wrote:
| Any time I have tried to fix a bug in an open source project
| I was immediately struck down with abusive attitudes about
| how I didn't do something exactly the way they wanted it that
| isn't really documented.
|
| If that's what I have to expect, I'd rather not even interact
| with them at all.
| tanvach wrote:
| If you really care, I would suggest helping with
| documenting how the process should work for others to
| reference going forward.
| ranger_danger wrote:
| I would if people were not abusive to me in the first
| place, but that attitude just turns me off to the entire
| project.
| shevy-java wrote:
| I don't think this is what typically happens. Many of my
| bug reports were handled.
|
| For instance, I reported to the xorg-bug tracker that one
| app behaved oddly when I did --version on it. I was batch-
| reporting all xorg-applications via a ruby script.
|
| Alan Coopersmith, the elderly hero that he is, fixed this
| not long after my report. (It was a real bug; granted, a
| super-small one, but still.)
|
| I could give many more examples here. (I don't remember the
| exact date but I think I reported this within the last 3
| years or so. Unfortunately reporting bugs in xorg-apps is
| ... a bit archaic. I also stopped reporting bugs to KDE
| because I hate bugzilla. Github issues spoiled me, they are
| so easy and convenient to use.)
| wewewedxfgdf wrote:
| That costs cash and the big tech companies are a little short
| at the moment.
| jeffbee wrote:
| They undoubtedly already maintain a fork of the project,
| considering that they have a private compression accelerator
| that nobody else has access to.
| lenerdenator wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| Do you have evidence of ai slop, or are you just spreading
| fud? The linked bug was acknowledged as real.
| Gualdrapo wrote:
| 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 wrote:
| 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 wrote:
| google literally tells them it's an ai generated report
| ikiris wrote:
| That is not the definition of slop.
| blibble wrote:
| if it's unwanted then it is
|
| and the ffmpeg maintainers say it's not wanted
|
| so it's slop
| iscoelho wrote:
| It's a reproducible use-after-free in a codec that ships
| by default with most desktop and server distributions. It
| can be leveraged in an exploit chain to compromise a
| system.
|
| I'm not a Google fan, but if the maintainers are unable
| to understand that, I welcome a fork.
| StopDisinfo910 wrote:
| It's not bug reports. It's CVE.
|
| There is a convergence of very annoying trends happening: more
| and more are garbage found and written using AI and with an
| impact which is questionable at best, the way CVE are published
| and classified is idiotic and platform founding vulnerability
| research like Google are more and more hostile to projects
| leaving very little time to actually work on fixes before
| publishing.
|
| This is leading to more and more open source developers
| throwing the towel.
| ranger_danger wrote:
| CVEs aren't caused by bugs?
| kykat wrote:
| You could argue that, but I think that a bug is the
| software failing to do what it was specified, or what it
| promised to do. If security wasn't promised, it's not a
| bug.
| adastra22 wrote:
| Which is exactly the case here. This CVE is for a hobby
| codec written to support digital preservation of a some
| obscure video files from the 90's that are used nowhere
| else. No security was promised.
| StopDisinfo910 wrote:
| They are not published in project bug trackers and are
| managed completely differently so no, personally, I don't
| view CVE as bug _reports_. Also, please, don 't distrort
| what I say and omit part of my comment, thank you.
|
| Some of them are not even bugs in the traditional sense of
| the world but expected behaviours which can lead to
| unsecure side effects.
| jsnell wrote:
| It seems like you might misunderstand what CVEs are?
| They're just identifiers.
|
| This was a bug, which caused an exploitable security
| vulnerability. The bug was reported to ffmpeg, over their
| preferred method for being notified about vulnerabilities
| in the software they maintain. Once ffmpeg fixed the bug,
| a CVE number was issued for the purpose of tracking (e.g.
| which versions are vulnerable, which were never
| vulnerable, which have a fix).
|
| Having a CVE identifier is important because we can't
| just talk about "the ffmpeg vulnerability" when there
| have been a dozen this year, each with different attack
| surfaces. But it really is just an arbitrary number,
| while the bug is the actual problem.
| StopDisinfo910 wrote:
| I'm not misunderstanding anything. CVE involves a third
| party and it's not just a number. It's a number and an
| evaluation of severity.
|
| Things which are usually managed inside a project now
| have a visibility outside of it. You might justify it as
| you want like the need to have an identifier. It doesn't
| fundamentally change how that impacts the dynamic.
|
| Also, the discussion is not about a specific bug. It's a
| general discussion regarding how Google handles
| disclosure in the general case.
| ikiris wrote:
| The lowered lead times are because devs have an entitled
| additude that others fix their code when they discover bugs
| in it.
|
| The 90 day period is the grace period for the dev, not a
| demand. If they don't want to fix it then it goes public.
| ivell wrote:
| It is super strange to say that who devoted their time and
| effort and then gives away their work for free is somehow
| entitled.
|
| If this keeps up, there won't be anyone willing to maintain
| the software due to burn out.
|
| In today's situation, free software is keeping many
| companies honest. Losing that kind of leverage would be a
| loss to the society overall.
|
| And the public disclosure is going to hurt the users which
| could include defense, banks and other critical
| institutions.
| adastra22 wrote:
| > The lowered lead times are because devs have an entitled
| additude that others fix their code when they discover bugs
| in it.
|
| That's how open source works.
| MyOutfitIsVague wrote:
| When you already work 40+ hours a week and big companies
| suddenly start an AI snowblower that shoots a dozen extra hours
| of work every week at you without doing anything to balance
| that (like, for instance, also opening PRs with patches that
| fix the bugs), the relationship starts feeling like being an
| unpaid employee of their project.
|
| What's the point of just showering these things with bug
| reports when the same tool (or a similar one) can also
| apparently fix the problem too?
| chemotaxis wrote:
| 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-...
|
| 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 wrote:
| Like the bug report in question... poetic.
| profsummergig wrote:
| 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 wrote:
| 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 wrote:
| Or they could contribute solutions to said bugs? Its not like
| they would distract that much from their bottom line
| SR2Z wrote:
| Google is a major contributor to open-source video, to the
| point where it would not be viable without them.
| FridgeSeal wrote:
| Are the contributions in the room with us now?
|
| I don't feel like the ffmpeg devs are unimpressed for no
| reason.
| SR2Z wrote:
| 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.
| degamad wrote:
| Exactly. The call-out is not "please stop doing security
| research". It is, "if you have a lot of money to spend on
| security research, please spend some of it on discovering
| the bugs, and some on fixing them (or paying us to fix
| them), instead of all of it on discovering bugs too fast
| for us to fix them in time".
| adastra22 wrote:
| Is it? I've gotten nothing but headaches from these automated
| CVE-seeking teams.
| viraptor wrote:
| You got lower chances of getting hacked by a random file on
| the internet. At Project Zero level they're also not CVE
| seeking - it doesn't even matter at that scale, it's not an
| independent trying to become known.
| xuhu wrote:
| It's as useful as brute forcing one of your neighbor's 100
| online passwords every day and writing it on the door of a
| random supermarket.
| samdoesnothing wrote:
| It's hard to find an easier good vs evil distinction than
| between Google and literally anybody else.
| criticalfault wrote:
| Microsoft Linux?
| machomaster wrote:
| Vim vs. Emacs
| lern_too_spel wrote:
| Facebook?
| samdoesnothing wrote:
| Probably a tie!
| dzhiurgis wrote:
| > era-defining software for free
|
| chill, nobody knows what ffmpeg is
| immibis wrote:
| 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 wrote:
| 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.
| woodruffw wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| They could be, and the chances of that increase immensely
| once Google publishes it.
| cogman10 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Firefox has moved some parsers to Rust:
| https://github.com/mozilla/mp4parse-rust
| rebelwebmaster wrote:
| Firefox also does a lot of media decoding in a separate
| process.
| godshatter wrote:
| Then maybe the Google chrome devs should submit a PR to
| ffmpeg.
| omnicognate wrote:
| Sure. _And_ fund them.
| manquer wrote:
| 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.
| adastra22 wrote:
| Upload a video to YouTube or Vimeo. They almost certainly
| run it through ffmpeg.
| conradev wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| toast0 wrote:
| The user is vulnerable while the problem is unfixed.
| Google publishing a vulnerability doesn't change the
| existence of the vulnerability. If Google can find it, so
| can others.
|
| Making the vulnerability public makes it easy to find to
| exploit, but it also makes it easy to find to fix.
| tremon wrote:
| If it is so easy to fix, then why doesn't Google fix it?
| So far they've spent more effort in spreading knowledge
| about the vulnerability than fixing it, so I don't agree
| with your assessment that Google is not actively making
| the world worse here.
| toast0 wrote:
| I didn't say it was easy to fix. I said a publication
| made it easy to find it, if someone wanted to fix
| something.
|
| If you want to fix up old codecs in ffmpeg for fun, would
| you rather have a list of known broken codecs and what
| they're doing wrong; or would you rather have to find a
| broken codec first.
| nmz wrote:
| > If Google can find it, so can others.
|
| While true, Only Google has google infrastructure, this
| presupposes that 100% of all published exploits would be
| findable.
| BobaFloutist wrote:
| >If Google can find it, so can others.
|
| What a strange sentence. Google can do a lot of things
| that nobody can do. The list of things that only Google,
| a handful of nation states, and a handful of Google-peers
| can do is probably even longer.
| AlienRobot wrote:
| 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.
| nemothekid wrote:
| > _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 wrote:
| 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.
| janalsncm wrote:
| All the license means is that I can't sue them. It
| doesn't mean I have to like it.
|
| Just because software makes no guarantees about being
| safe doesn't mean I want it to be unsafe.
| gowld wrote:
| If the software makes no guarantees about being safe,
| then you should assume it is unsafe.
| rmunn wrote:
| Have you ever used a piece of software that DID make
| guarantees about being safe?
|
| Every software I've ever used had a "NO WARRANTY" clause
| of some kind in the license. Whether an open-source
| license or a EULA. Every single one. Except, perhaps, for
| public-domain software that explicitly had no license,
| but even "licenses" like CC0 explicitly include "Affirmer
| offers the Work as-is and makes no representations or
| warranties of any kind concerning the Work ..."
| janalsncm wrote:
| Anyone who has seen how the software is sausaged knows
| that. Security flaws will happen, no matter what the
| lawyers put in the license.
|
| And still, we live in a society. We have to use software,
| bugs or not.
| necovek wrote:
| 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.
| dylan604 wrote:
| 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.
| Lerc wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| johneth wrote:
| > That is standard practice.
|
| It's standard practice for commercially-sponsored software,
| and it doesn't necessarily fit volunteer maintained
| software. You can't have the same expectations.
| NegativeK wrote:
| Vulnerabilities should be publicly disclosed. Both closed
| and open source software are scrutinized by the good and
| the bad people; sitting on vulnerabilities isn't good.
|
| Consumers of closed source software have a pretty
| reasonable expectation that the creator will fix it in a
| timely manner. They paid money, and the (generally) the
| creator shouldn't put the customer in a nasty place
| because of errors.
|
| Consumers of open source software should have zero
| expectation that someone else will fix security issues.
| Individuals should understand this; it's part of the deal
| for us using software for free. Organizations that are
| making money off of the work of others should have the
| opposite of an expectation that any vulns are fixed. If
| they have or should have any concern about
| vulnerabilities in open source software, then they need
| to contribute to fixing the issue somehow. Could be
| submitting patches, paying a contractor or vendor to
| submit patches, paying a maintainer to submit patches, or
| contributing in some other way that betters the project.
| The contribution they pick needs to work well with the
| volunteers, because some of the ones I listed would
| absolutely be rejected by some projects -- but not by
| others.
|
| The issue is that an org like Google, with its absolute
| mass of technical and financial resources, went looking
| for security vulnerabilities in open source software with
| the pretense of helping. But if Google (or whoever)
| doesn't finish the job, then they're being a piece of
| shit to volunteers. The rest of the job is reviewing the
| vulns by hand and figuring out patches that can be
| accepted with absolutely minimal friction.
|
| To your point, the beginning of the expectation should be
| that vulns are disclosed, since otherwise we have known
| insecure software. The rest of the expectation is that
| you don't get to pretend to do a nice thing while
| _knowing_ that you're dumping more work on volunteers
| that you profit from.
|
| In general, wasting the time of volunteers that you're
| benefiting from is rude.
|
| Specifically, organizations profiting off of volunteer
| work and wasting their time makes them an extractive
| piece of shit.
|
| Stop being a piece of shit, Google.
| danaris wrote:
| Here's the question:
|
| Why is Google deliberately running an AI process to find
| these bugs if they're just going to dump them all on the
| FFmpeg team to fix?
|
| They have the option to pay someone to fix them.
|
| They also have the option to _not_ spend resources finding
| the bugs in the first place.
|
| If they think these are so damn important to find that it's
| worth devoting those resources to, then _they can damn well
| pay for fixing them too_.
|
| Or they can shut the hell up and let FFmpeg do its thing in
| the way that has kept it one of the https://xkcd.com/2347/
| pieces of everyone's infrastructure for over 2 decades.
| freedomben wrote:
| I would love to see Google contribute here, but I think
| that's a different issue.
|
| Are the bug reports accurate? If so, then they are
| contributing just as if I found them and sent a bug
| report, I'd be contributing. Of course a PR that fixes
| the bug is much better than just a report, but reports
| have value, too.
|
| The alternative is to leave it unfound, which is not a
| better alternative in my opinion. It's still there and
| potentially exploitable even when unreported.
| danaris wrote:
| But FFmpeg _does not have the resources_ to fix these at
| the speed Google is finding them.
|
| It's just not possible.
|
| So Google is dedicating resources to finding these bugs
|
| and feeding them to bad actors.
|
| Bad actors who _might, hypothetically_ have had the
| information before, but _definitely_ do once Google
| publicizes them.
|
| You are talking about an ideal situation; we are talking
| about a real situation that is happening in the real
| world right now, wherein the option of Google reports bug
| > FFmpeg fixes bug _simply does not exist_ at the scale
| Google is doing it at.
| GabrielTFS wrote:
| A solution definitely ought to be found. Google putting
| up a few millionths of a percent of their revenue or so
| towards fixing the bugs they find in ffmpeg would be the
| ideal solution here, certainly. Yet it seems unlikely to
| actually occur.
|
| I think the far more likely result of all the complaints
| is that Google simply completely disengages from ffmpeg
| and stops doing any security work on it. I think that
| would be quite bad for the security of the project - if
| Google can trivially find bugs at a high speed such that
| it overwhelms the ffmpeg developers, I would imagine bad
| actors can also search for them and find those same
| vulnerabilities Google is constantly finding, and if they
| know that those vulnerabilities very much exist, but that
| Google has simply stopped searching for them upon demand
| of the ffmpeg project, this would likely give them
| extremely high motivation to go looking in a place they
| can be almost certain they'll find unreported/unknown
| vulnerabilities in. The result would likely be a lot more
| 0-day attacks involving ffmpeg, which I do not think
| anyone regards as a good outcome (I would consider
| "Google publishes a bunch of vulnerabilities ffmpeg
| hasn't fixed so that everyone knows about them" to be a
| much preferable outcome, personally)
|
| Now, you might consider that possibility fine - after
| all, the ffmpeg developers have no obligation to work on
| the project, and thus to e.g. fix any vulnerabilities in
| it. But if that's fine, then simply ignoring the reports
| Google currently makes is presumably also fine, no ?
| SR2Z wrote:
| Google is a significant contributor to ffmpeg by way of
| VP9/AV1/AV2. It's not like it's a gaping maw of open-
| source abuse, the company generally provides real value
| to the OSS ecosystem at an even lower level than ffmpeg
| (which is saying a lot, ffmpeg is pretty in-the-weeds
| already).
|
| As to why they bother finding these bugs... it's because
| that's how Google does things. You don't wait for
| something to break or be exploited, you load your
| compiler up with santizers and go hunting for bugs.
|
| Yeah this one is kind of trivial, but if the bug-finding
| infrastructure is already set up it would be even more
| stupid if Google just sat on it.
| danaris wrote:
| Then _they can damn well pay for fixing them too_.
| SR2Z wrote:
| That's not a choice. You can decide if Google files bugs
| like this or not, you can't force them to fix them.
| _flux wrote:
| Many people are already developing and fixing FFmpeg.
|
| How many people are actively looking for bugs? Google,
| and then the other guys that don't share their findings,
| but perhaps sell them to the highest bidder. Seems like
| Google is doing some good work by just picking big,
| popular open source projects and seeing if they have
| bugs, even if they don't intend to fix them. And I doubt
| Google was actually using the Lucas Arts video format
| their latest findings were about.
|
| However, in my mind the discussion whether Google should
| be developing FFmpeg (beyond the codec support mentioned
| elsewhere in the thread) or other OSS projects is
| completely separate from whether they should be finding
| bugs in them. I believe most everyone would agree they
| should. They are helping OSS in other ways though, e.g.
| https://itsfoss.gitlab.io/post/google-sponsors-1-million-
| to-... .
| jsnell wrote:
| > 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-
| tra..., discussed at
| https://news.ycombinator.com/item?id=44724287
|
| [1] https://googleprojectzero.blogspot.com/p/reporting-
| transpare...
| joemi wrote:
| 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.
| necovek wrote:
| When you publicize a vulnerability you know someone doesn't
| have the capacity to fix according to the requested
| timeline, you are simultaneously increasing the visibility
| of the vulnerability and name-calling the maintainers. All
| of this increases the pressure on the maintainers, and it's
| fair to call that a "demand" (quotes-included). Note that
| we are talking about humans who will only have their
| motivation dwindle: it's easy to say that they should be
| thick-skinned and ignore issues they can't objectively fix
| in a timely manner, but it's demoralizing to be called out
| like that when everyone knows you can't do it, and you are
| generally doing your best.
|
| It's similar to someone cooking a meal for you, and you go
| on and complain about every little thing that could have
| been better instead of at least saying "thank you"!
|
| Here, Google is doing the responsible work of reporting
| vulnerabilities. But any company productizing ffmpeg usage
| (Google included) should sponsor a security team to resolve
| issues in high profile projects like these too.
|
| Sure, the problem is that Google is a behemoth and their
| internal org structure does not cater to this scenario, but
| this is what the complaint is about: make your internal
| teams do the right thing by both reporting, but also
| helping fix the issue with hands-on work. Who'd argue
| against halving their vulnerability finding budget and
| using the other half to fund a security team that fixes
| highest priority vulnerabilities instead?
| jsnell wrote:
| > When you publicize a vulnerability you know someone
| doesn't have the capacity to fix according to the
| requested timeline
|
| My understanding is that the bug in question was fixed
| about 100 times faster than Project Zero's standard
| disclosure timeline. I don't know what vulnerability
| report your scenario is referring to, but it certainly is
| not this one.
|
| > and name-calling the maintainers
|
| Except Google did not "name-call the maintainers" or
| anything even remotely resembling that. You just made it
| up, just like GP made up the the "demands". It's pretty
| telling that all these supposed misdeeds are just total
| fabrications.
| Too wrote:
| 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.
| m463 wrote:
| if you've ever read about codependency, "need" is a relative
| term.
|
| codependency is when someone accepts too much responsibility,
| in particular responsibility for someone else or other things
| out of their control.
|
| the answer is to have a "healthy neutrality".
| AbrahamParangi wrote:
| If google bears no role in fixing the issues it finds and
| nobody else is being paid to do it either, it functionally is
| just providing free security vulnerability research for
| malicious actors because almost nobody can take over or switch
| off of ffmpeg.
| eddd-ddde wrote:
| So your claim is that buggy software is better than
| documented buggy software?
| rsanek wrote:
| I think so, yes. Certainly it's more effort to both find
| and exploit a bug than to simply exploit an existing one
| someone else found for you.
| jakeydus wrote:
| Yeah it's more effort, but I'd argue that security
| through obscurity is a super naive approach. I'm not on
| Google's side here, but so much infrastructure is
| "secured" by gatekeeping knowledge.
| Brian_K_White wrote:
| I don't think you should try to invoke the idea of
| naivete when you fail to address the unhappy but
| perfectly simple reality that the ideal option doesn't
| exist, is a fantasy that isn't actually available, and
| among the available options, even though none are good,
| one is worse than another.
|
| "obscurity isn't security" is true enough, as far as it
| goes, but is just not that far.
|
| And "put the bugs that won't be fixed soon on a
| billboard" is worse.
|
| The super naive approach is ignoring that and thinking
| that "fix the bugs" is a thing that exists.
| rcxdude wrote:
| If I know it's a bug and I use ffmpeg, I can avoid it by
| disabling the affected codec. That's pretty valuable.
| user3939382 wrote:
| it's not a claim it's common sense that's why we have
| notice periods
| janalsncm wrote:
| I guess the question that a person at Google who discovers a
| bug they don't personally have time to fix is, should they
| report the bug at all? They don't necessarily know if someone
| else will be able to pick it up. So the current "always
| report" rule makes sense since you don't have to figure out
| if someone can fix it.
|
| The same question applies if they have time to fix it in six
| months, since that presumably still gives attackers a large
| window of time.
|
| In this case the bug was so obscure it's kind of silly.
| woodruffw wrote:
| I don't think vulnerability researchers are having trouble
| finding exploitable bugs in FFmpeg, so I don't know how much
| this actually holds. Much of the cost center of vulnerability
| research is _weaponization_ and making an exploit reliable
| against a specific set of targets.
|
| (The argument also seems backwards to me: Google _appears_ to
| use a lot of not-inexpensive human talent to produce high
| quality reports to projects, instead of dumping an ASan log
| and calling it a day. If all they cared about was shoveling
| labor onto OSS maintainers, they could make things a lot
| easier for themselves than they currently do!)
| ryandrake wrote:
| > But appearance is operative: a security issue is something
| that I (as the maintainer) would need to fix regardless of who
| reports it
|
| I think this is the heart of the issue and it boils off all of
| the unimportant details.
|
| If it's a real, serious issue, you want to know about it and
| you want to fix it. Regardless of who reports it.
|
| If it's a real, but _unimportant_ issue, you probably at least
| want to track it, but aren 't worried about disclosure.
| Regardless of who reports it.
|
| If it's invalid, or AI slop, you probably just want to
| close/ignore it. Regardless of who reports it.
|
| It seems entirely irrelevant who is reporting these issues. As
| a software project, ultimately you make the judgment call about
| what bugs you fix and what ones you don't.
| vacuity wrote:
| But if it's a real, serious issue without an easy resolution,
| who is the burden on? It's not that the maintainers wouldn't
| fix bugs if they easily could. FFmpeg is provided "as is"[0],
| so everyone should be responsible for their side of things.
| It's not like the maintainers dumped their software on every
| computer and forced people to use it. Google should be
| responsible for their own security. I'm not adamant that
| Google should share the patch with others, but it would
| hardly be an imposition to Google if they did. And yes, I
| really do intend that you could replace Google with any
| party, big or small, commercial or noncommercial. It's
| painful, but no one has any inherent obligations to provide
| others with software in most circumstances.
|
| [0] More or less. It seems the actual language is shied from.
| Is there a meaningful difference?
| ryandrake wrote:
| Well, it's open source and built by volunteers, so nobody
| is _obligated_ to fix it. If FFmpeg volunteers don 't want
| to fix it or don't have the time/bandwidth to fix it, then
| they won't fix it. Like any other bug or CVE in any other
| open source project. The burden doesn't necessarily need to
| be on anyone.
| lenerdenator wrote:
| They aren't obligated to fix CVEs until they're
| exploited, and then, suddenly, they very much were
| obligated to fix the CVEs, and their image as FLOSS
| maintainers and as a project are very much tarnished.
| grayhatter wrote:
| I feel this comment is far to shallow a take. I would expect
| that you know better than most of HN, exactly how much a
| reputation security has as a cost center. Google uses ffmpeg
| internally, how many millions would they have to spend if they
| were required to not only create, but maintain ffmpeg
| themselves? How significant would that cost be at Google's
| scale?
|
| I dont agree the following framing is accurate, but I can
| mention it because you've already said the important part
| (about how this issue exists, and mearly knowing about it
| doesn't create required work.) But here announcing it, and
| registering a CVE, Google is starting the clock. By some
| metrics, it was already running, but the reputational risk
| clearly was not. This does change priorities, and requires as
| urgent context switch. neither are free actions, especially not
| within FOSS.
|
| To me, being someone who believes everyone, individuals and
| groups, have a responsibility to contribute fairly. I would
| frame it as Google's behavior gives the appearance weaponizing
| their cost center externally, given this is something Google
| could easily fix, but instead they shirked that responsibility
| to unfunded volunteers.
| woodruffw wrote:
| To be clear, I think Google (Apple, Microsoft, etc.) can and
| should fund more of the OSS they depend on. But this doesn't
| change the fact that vulnerability reports don't _create_
| work per se, they just _reveal_ work that the project can
| choose to act on or not.
| grayhatter wrote:
| Hopefully, until that changes, more people with influence
| will keep saying it, and always say it until it stops being
| true, and important.
|
| So thank you for saying the important thing too! :)
| Yokolos wrote:
| I see you didn't read the article.
|
| The problem isn't Google reporting vulnerabilities. It's Google
| using AI to find obscure bugs that affect 2 people on the
| planet, then making a CVE out of it, without putting any effort
| into fixing it themselves or funding the project. What are the
| ffmpeg maintainers supposed to do about this? It's a complete
| waste of everybody's time.
|
| > The latest episode was sparked after a Google AI agent found
| an especially obscure bug in FFmpeg. How obscure? This "medium
| impact issue in ffmpeg," which the FFmpeg developers did patch,
| is "an issue with decoding LucasArts Smush codec, specifically
| the first 10-20 frames of Rebel Assault 2, a game from 1995."
| inkysigma wrote:
| I don't think that's an accurate description of the full
| scope of the problem. The codec itself is mostly unused but
| the code path can possibly be triggered from file fuzzing
| that ffmpeg uses so a maliciously crafted payload (e.g. any
| run of ffmpeg that touches user input without disabling this
| codec) could possibly be exploited.
| prmoustache wrote:
| OTOH they could disclose security issues AND send patches to
| close them.
| prewett wrote:
| "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 wrote:
| 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.
| meesles wrote:
| 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 wrote:
| Yeah, sadly crazy.
| doctorwho42 wrote:
| 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 wrote:
| 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.
| noir_lord wrote:
| > I also wonder if it is maybe used by Netflix also.
|
| They do and it is.
|
| https://netflixtechblog.com/the-making-of-ves-the-cosmos-
| mic...
|
| https://netflixtechblog.com/for-your-eyes-only-improving-
| net...
| kwanbix wrote:
| It is really sad that none of Netflix or Google had hired
| a couple of devs to work full time on ffmpeg.
| noir_lord wrote:
| I'd be amazed if any of the FAANG's isn't putting real
| money through ffmpeg somewhere.
|
| So yeah it'd be nice if they put some real money (to
| ffmpeg - wouldn't be their coffee allowance to any of
| them) into it.
|
| Almost everything that touches video at some point uses
| it.
| themafia wrote:
| > How do you think Jeff got a 500 million dollars yacht? Not
| by writing checks.
|
| A rising tide lifts all yachts. If he had written the check,
| my instinct tells me, he would have enough for two yachts.
| Goodwill is an actual line item on 10Q's and 10K's. I don't
| know why companies think it's worth ignoring.
| jancsika wrote:
| If I had built up 500 million in a savings account to buy a
| yacht, giving 50k of that to FFmpeg devs would put off my
| ability to buy a yacht by nearly a whole day.
|
| Boltzmann brain-wise it clearly doesn't make sense to wait
| that long.
| gowld wrote:
| Cheating on your wife would put off your ability to buy
| that yacht off by 20 years, and yet here we are.
| benced wrote:
| 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 wrote:
| 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 wrote:
| 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.
| palmotea wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| righthand wrote:
| 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 wrote:
| We're well past the point that any serious security team should
| be able to submit a fix along with a bug report.
| justahuman74 wrote:
| Does Google seriously not have a whole team of people who help
| maintain ffmpeg?
| adastra22 wrote:
| Yes. But they don't upstream. Why would they?
| justahuman74 wrote:
| Great, they can fix the bugs being filed by another part of
| their company
| Ferret7446 wrote:
| So would you rather Google have a secure ffmpeg while us
| plebian individual users continue to have an insecure
| ffmpeg?
| dieortin wrote:
| https://github.com/search?q=repo%3AFFmpeg%2FFFmpeg+google.co...
| mrs6969 wrote:
| 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 wrote:
| If it's not free for enterprises then it's not open source,
| according to the commonly accepted definition.
| warmwaffles wrote:
| 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 wrote:
| That's how you get your open source software removed from
| distributions and eventually forked.
| cubefox wrote:
| Forked by people who are quicker at fixing security
| vulnerabilities than the original maintainers?
| adastra22 wrote:
| Sure, for some definition of "vulnerability." And only
| doing that, nothing more.
| warmwaffles wrote:
| And that's a problem?
| phkahler wrote:
| 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 wrote:
| How could ffmpeg maintainers kill three major AWS product lines
| with an email?
| zxspectrum1982 wrote:
| 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 wrote:
| Wouldn't that only affect new versions and current versions
| are still licensed under the old license ?
| NewsaHackO wrote:
| 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 wrote:
| 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?
| arrowleaf wrote:
| If they can fund a fork, they can continue business as
| usual until the need arises
| zrm wrote:
| A fork is more expensive to maintain than
| funding/contributing to the original project. You have to
| duplicate all future work yourselves, third party code
| starts expecting their version instead of your version,
| etc.
| cortesoft wrote:
| They COULD, but history has shown they would rather start
| and maintain their own fork.
|
| It might not make sense morally, but it makes total sense
| from a business perspective... if they are going to pay
| for the development, they are going to want to maintain
| control.
| edoceo wrote:
| If they want that level of control, reimburse for all the
| prior development too. - ie: buy that business.
|
| As it stands, they're just abusing someone's gift.
|
| Like jerks.
| rolandog wrote:
| There should be a "if you use this product in a for-
| profit environment, and you have a yearly revenue of
| $500,000,000,000+ ... you can afford to pay X *
| 100,000/yr" license.
| renewiltord wrote:
| That's the Llama license and yeah, a lot of people prefer
| this approach, but many don't consider it open source. I
| don't either.
|
| In fact, we are probably just really lucky that some
| early programmers were kooky believers in the free
| software philosophy. Thank God for them. So much of what
| I do owes to the resulting ecosystem that was built back
| then.
| zrm wrote:
| There is also the AGPL.
| LexiMax wrote:
| I always like to point out that "Open Source" was a
| deliberate watering-down of the moralizing messaging of
| Free Software to try and sell businesses on the benefits
| of developing software in the open.
|
| > We realized it was time to dump the confrontational
| attitude that has been associated with "free software" in
| the past and sell the idea strictly on the same
| pragmatic, business-case grounds that motivated Netscape.
|
| https://web.archive.org/web/20021001164015/http://www.ope
| nso...
| schainks wrote:
| It still takes expensive humans to do this so they are
| incentivized to use the free labor.
| NewsaHackO wrote:
| Yes, definitely. I was just saying that if the license
| ever did change, they would move to an in-house library.
| In fact, they would probably release the library for
| consumer use as an AWS product.
| mschuster91 wrote:
| I'd guess Prime Video heavily relies on ffmpeg, then you got
| Elastic Transcode and the Elemental Video Services. Probably
| Cloudfront also has special things for streaming that rely on
| ffmpeg.
|
| The "kill it with an email" probably means that whoever said
| this is afraid that some usecase there wouldn't stand up to
| an audit by the usual patent troll mothercluckers. The
| patents surrounding video are so complex, old and plentiful
| that I'd assume full compliance is outright impossible.
| noir_lord wrote:
| AWS MediaConvert as well which is a _huge_ API (in surface
| it covers) which is under Elemental but is kinda it 's own
| thing - willing to _bet_ (though I don 't know) that that
| is ffmpeg somewhere underneath.
|
| The API manual for it is nearly 4000 pages and it can do
| insane stuff[1].
|
| I had to use it at last job(TM), it's not terrible API
| wise.
|
| [1] https://docs.aws.amazon.com/pdfs/mediaconvert/latest/ap
| irefe... CAUTION: _big_ PDF.
| joshkel wrote:
| In a follow-up tweet, Mark Atwood eloborates: "Amazon was
| very carefully complying with the licenses on FFmpeg. One of
| my jobs there was to make sure the company was doing so.
| Continuing to make sure the company was was often the reason
| I was having a meeting like that inside the company."
|
| I interpret this as meaning there was an implied "if you
| screw this up" at the end of "they could kill three major
| product lines with an email."
| phkahler wrote:
| Are you interpreting that as "if we violate the license,
| they can revoke our right to use the software" ?? And they
| use it in 3 products so that would be really bad. That
| would make sense to have a compliance person.
| zxspectrum1982 wrote:
| Google is not paying anyone to find bugs. They are running AIs
| indiscriminately.
| rescbr wrote:
| Still, they are paying for the computing resources needed to
| run the AI/agents etc.
| dtech wrote:
| Someone is making the tools to find these bugs. It's not like
| they're telling ChatGPT "go find bugs lol"
| pimlottc wrote:
| Someone started it running, they are responsible for the
| results.
| rsanek wrote:
| https://en.wikipedia.org/wiki/Project_Zero
| nimih wrote:
| They certainly paid someone to run the so-called AIs.
| dvfjsdhgfv wrote:
| > "Don't come to me with problems, come with solutions"
|
| The problem is, the issue in the article is explicitly named as
| "CVE slop", so if the patch is of the same quality, it might
| require quite some work anyway.
| jeffbee wrote:
| The linked report seems to me to be the furthest thing from
| "slop". It is an S-tier bug report that includes a complete
| narrative, crash artifacts, and detailed repro instructions.
| I can't believe anyone is complaining about what is tied for
| the best bug report I have ever seen.
| https://issuetracker.google.com/issues/440183164?pli=1
| michaelt wrote:
| It's a good quality bug report.
|
| But it's also a bug report about the decoder for "SANM ANIM
| v0" - a format so obscure almost all the search results are
| the bug report itself. Possibly a format exclusive to
| mid-1990s LucasArts games [1]
|
| Pretty crazy that ffmpeg supports the codec in the first
| place, IMHO.
|
| I can understand volunteers not wanting to sink time into
| maintaining a codec to play a video format that hasn't been
| used since the Clinton administration. gstreamer divides
| their plugins into 'good', 'bad' and 'ugly' to give them
| somewhere to stash unmaintained codecs.
|
| [1] https://web.archive.org/web/20250419105551/https://wiki
| .mult...
| jsnell wrote:
| It's a codec that is enabled by default at least on major
| Linux distributions, and that will be processed by ffmpeg
| without any extra flags. Anyone playing an untrusted
| video file without explictly overriding the codec
| autodetection is vulnerable.
|
| The format being obscure and having no real usage doesn't
| help when it's the attackers creating the files. The
| obscure formats are exposing just as much attack surface
| as the common ones.
|
| > Pretty crazy that ffmpeg supports the codec in the
| first place, IMHO.
|
| Yes.
| jeffbee wrote:
| Yeah but as you can see from the bug report ffmpeg
| automatically triggers the codec based on file magic, so
| it is possible that if you run some kind of network
| service or anything that handles hostile data an attacker
| could trigger the bug.
| skhameneh wrote:
| I've been a proponent of upstreaming fixes for open source
| software.
|
| Why? - It makes continued downstream consumption easier, you
| don't have to rely on fragile secret patches. - It gives back
| to projects that helped you to begin with, it's a simple form
| of paying it forward. - It all around seems like the "ethical"
| and "correct" thing to do.
|
| Unfortunately, in my experience, there's often a lot of
| barriers within companies to upstream. Reasons can be
| everything from compliance, processes, you name it... It's
| unfortunate.
|
| I have a very distinct recollection of talks about hardware
| aspirations and upstreaming software fixes at a large company.
| The cultural response was jarring.
| pjmlp wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| NegativeK wrote:
| AGPL, with no CLA that lets the owners relicense. Then we'll
| see if the using corporation fully believes in open source.
|
| There's a reason Google turned into year 2000 Microsoft "it's
| viral!" re. the AGPL. They're less able to ignore the intent
| of the license and lock away their changes.
| iscoelho wrote:
| Google is, at no cost to FFMPEG:
|
| 1) dedicating compute resources to continuously fuzzing the
| entire project
|
| 2) dedicating engineering resources to validating the results
| and creating accurate and well-informed bug reports (in this
| case, a seriously underestimated security issue)
|
| 3) additionally for codecs that Google likely does not even
| internally use or compile, purely for the greater good of
| FFMPEG's user base
|
| Needless to say, while I agree Google has a penny to spare to
| fund FFMPEG, and should (although they already contribute), I
| do not agree with funding this maintainer.
| pjmlp wrote:
| Then they can surely also provide a pull request for said
| CVE.
| SR2Z wrote:
| Where do you draw the line? Do you want Google to just not
| inspect any projects that it can't fully commit to
| maintaining?
|
| Providing a real CVE is a contribution, not a burden. The
| ffmpeg folks can ignore it, since by all indications it's
| pretty minor.
| strictnein wrote:
| Personally, I want the $3.5 Trillion company to do more.
| So the line should be somewhere else.
| SR2Z wrote:
| So you don't have a line, you just want to move the
| goalposts and keep moving them?
| angiolillo wrote:
| > Providing a real CVE is a contribution, not a burden.
|
| Isn't a real CVE (like any bug report) both a
| contribution and a burden?
| SR2Z wrote:
| Only if you subscribe to the "if we stop testing people,
| the number of cases will drop!" philosophy.
| ahepp wrote:
| What is the mission of Project Zero? Is it to build a
| vulnerability database, or is it to fix vulnerabilities?
|
| If it's to fix vulnerabilities, it seems within reason to
| expect a patch. If the reason Google isn't sending a
| patch is because they truly think the maintainers can fix
| it better, then that seems fair. But if Google isn't
| sending a patch because fixing vulns "doesn't scale" then
| that's some pretty weak sauce.
|
| Maybe part of the solution is creating a separate low
| priority queue for bug reports from groups that _could_
| fix it but chose not to.
| saubeidl wrote:
| To build on that - if it "doesn't scale" for one of the
| wealthiest companies in the world, it certainly doesn't
| scale for a volunteer project...
| f33d5173 wrote:
| If you are deliberately shipping insecure software, you
| should stop doing that. In ffmpeg's case, that means
| either patching the bug, or disabling the codec. They
| refused to do the latter because they were proud of being
| able to support an obscure codec. That puts the onus on
| them to fix the bug in it.
| lenerdenator wrote:
| > Providing a real CVE is a contribution, not a burden.
| The ffmpeg folks can ignore it, since by all indications
| it's pretty minor.
|
| Re-read the article. There's CVEs and then there's
| _CVEs_. This is the former, and they 're shoving tons of
| those down the throats of unpaid volunteers while
| contributing nothing back.
|
| What Google's effectively doing is like a food safety
| inspection company going to the local food bank to get
| the food that they operate their corporate cafeteria on
| just to save a buck, then calling the health department
| on a monthly basis to report any and all health
| violations they _think_ they might have seen, while
| contributing nothing of help back to the food bank.
| SR2Z wrote:
| I have read the article. The expectation for a tool like
| ffmpeg is that regardless of what kind of file you put
| into it, it safely handles it.
|
| This is an actual bug in submitted code. It doesn't
| matter that it's for some obscure codec, it's technically
| maintained by the ffmpeg project and is fair game for
| vulnerability reports.
|
| Given that Google is also a major contributor to open-
| source video, this is more like a food manufacturer
| making sure that grocery stores are following health code
| when they stock their food.
|
| Mind you, the grocery store has no obligation to listen
| to them in this metaphor and is free to just let the
| report/CVE sit for a while.
| gnfargbl wrote:
| They could, but there is really no requirement on them to
| do so. The security flaw was discovered by Google, but it
| was not _created_ by them.
|
| Equally there is no requirement on ffmpeg to fix these CVEs
| nor any other.
|
| And, of course, there is no requirement on end-users to run
| software from projects which do not consider untrusted-
| input-validation bugs to be high priority.
| lenerdenator wrote:
| > And, of course, there is no requirement on end-users to
| run software from projects which do not consider
| untrusted-input-validation bugs to be high priority.
|
| What's this even saying?
|
| Then they're free to fork it and never use the upstream
| again.
| FridgeSeal wrote:
| Google is:
|
| - choosing to do this of their own volition
|
| - are effectively just using their resources to throw bug
| reports over the wall unprompted.
|
| - benefiting from the bugs getting fixed, but not
| contributing to them.
| toast0 wrote:
| > - benefiting from the bugs getting fixed, but not
| contributing to them.
|
| I would be very surprised if Google builds this codec when
| they build ffmpeg. If you run a/v codecs (like ffmpeg) in
| bulk, the first thing to do is sandbox the hell out of it.
| The second thing you do is strictly limit the containers
| and codecs you'll decode. Not very many people need to
| decode movies from old LucasArts games, for video codecs,
| you probably only want mpeg 1-4, h.26x, vp8, vp9, av1. And
| you'll want to have fuzzed those decoders as best you can
| too.
|
| Nobody should be surprised that there's a security problem
| in this ancient decoder. Many of the eclectic codecs were
| written to mimic how the decoders that shipped with content
| were written, and most of those codecs were written
| assuming they were decoding a known good file, because why
| wouldn't they be. There's no shame, that's just how it
| is... there's too much to proactively investigate, so
| someone doing fuzzing and writing excellent reports that
| include diagnosis, specific location of the errors, and a
| way to reproduce are providing a valuable contribution.
|
| Could they contribute more? Sure. But even if they don't,
| they've contributed something of value. If the maintainers
| can't or don't want to address it, that'd be reasonable
| too.
| andrewstuart wrote:
| "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 wrote:
| 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__ wrote:
| 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 wrote:
| 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 wrote:
| It is included by default
| oskarkk wrote:
| 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.
| esrauch wrote:
| 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".
| cestith wrote:
| You're right about scoring, at least largely. Let's not
| conflate the CVE system and the CVSS system, though. They
| are related but distinct. CVE is just an identifier system.
| strictnein wrote:
| > 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.
|
| +100000
|
| My favorite 8.x or higher CVEs are the ones where you would
| have to take untrusted user input, bypass all the standard
| ways to ingest and handle that type of data, and pass it
| into some internal function of a library. And then the end
| result is that a regex call becomes more expensive.
| happytoexplain wrote:
| Yes - more than a sour taste. This is hideous behavior. It is
| the polar opposite of everything intelligent engineers have
| understood regarding free-and-open software for decades.
| toast0 wrote:
| Use After Free takes 3 seconds to fix if you defer free until
| the end of the program. If you have to do something else, or
| you don't want to leak memory, then it probably takes longer
| than 3 seconds.
|
| Probably the right solution is to disable this codec. You
| should have to make a choice to compile with it; although if
| you're running ffmpeg in a context where security matters, you
| really should be hand picking the enabled codecs anyway.
| section_me wrote:
| 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 wrote:
| 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.
| dbl000 wrote:
| 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 wrote:
| 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.
| ironman1478 wrote:
| Never work for free. It's a complete market distortion and leads
| to bad actors taking advantage of you and your work.
| samdoesnothing wrote:
| Yep.
| PeaceTed wrote:
| 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.
| shevy-java wrote:
| That's fine. Are they required to work for Google? I mean, they
| are independent and can decide on their own.
| palata wrote:
| Sometimes it's hard: for many kinds of projects, I don't think
| anyone would use them if they were not open source (or at least
| source-available). Just like I wouldn't use a proprietary
| password manager, and I wouldn't use WhatsApp if I had a
| choice. Rather I use Signal because it's open source.
|
| How to get people to use your app if it's not open source, and
| therefore not free?
|
| For some projects, it feels better to have some people use it
| even if you did it for free than to just not do it at all (or
| do it and keep it in a drawer), right?
|
| I am wondering, I haven't found a solution. Until now I've been
| open sourcing stuff, and overall I think it has maybe brought
| more frustration, but on the other hand maybe it has some value
| as my "portfolio" (though that's not clear).
| tatjam wrote:
| You can just use the GPL, then it's free, but your labour
| cannot be so easily profited from by big corps
| palata wrote:
| But it can be profited for not-so-big corps, so I'm still
| working for free.
|
| Also I have never received requests from TooBigTech, but
| I've received a lot of requests from small
| companies/startups. Sometimes it went as far as asking for
| a permissive licence, because they did not want my copyleft
| licence. Never offered to pay for anything though.
| bogwog wrote:
| Is it time for FFmpeg to relicense as AGPL? That'd be fun to
| witness.
| PeaceTed wrote:
| 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 wrote:
| 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.
| Ferret7446 wrote:
| It'll just get forked (see terraform)
| jeroenhd wrote:
| 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.
| shevy-java wrote:
| I think this would be hard. It also makes not a whole lot of
| sense IMO.
|
| People need to think about what licence they want to use for a
| project.
| bhouston wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| aweiher wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| you could not imagine and just read sources like
| https://en.wikipedia.org/wiki/Project_Zero
| khuey wrote:
| 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 wrote:
| 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.
| NegativeK wrote:
| PR.
|
| And pushing forward the idea that "responsible disclosure"
| doesn't mean the software creator can just sit on a bug for as
| long as they want and act superior and indignant when the
| researcher gives up and publishes anyway because the creator is
| dragging their ass.
| HackerThemAll wrote:
| 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/
| shevy-java wrote:
| 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 wrote:
| 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.
| iscoelho wrote:
| 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 wrote:
| 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.
| vsgherzi wrote:
| 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 wrote:
| >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.
| themafia wrote:
| > 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 wrote:
| > That does not impact their business or their operations in
| any way whatsoever.
|
| I don't know what tools and backends they use exactly, but
| working purely by statistics, I'm sure _some_ place in Google
| 's massive cloud compute empire is relying on ffmpeg to
| process data from the internet.
| themafia wrote:
| And they're processing old LucasArts codec videos with it?
| Which is the specific bug report in question.
| shevy-java wrote:
| > ffmpeg owes me nothing. I haven't paid them a dime.
|
| That is true. At the same time Google also does not owe the
| ffmpeg devs anything either. It applies both ways. The whole
| "pay us or we won't fix this" makes no sense.
| themafia wrote:
| > Google also does not owe the ffmpeg devs anything either.
|
| Then they can stop reporting bugs with their assinine one
| size fits all "policy." It's unwelcome and unnecessary.
|
| > It applies both ways.
|
| The difference is I do not presume things upon the ffmpeg
| developers. I just use their software.
|
| > The whole "pay us or we won't fix this" makes no sense.
|
| Pay us or stop reporting obscure bugs in unused codecs
| found using "AI" scanning, or at least, if you do, then
| change your disclosure policy for those "bugs." That's the
| actual argument and is far more reasonable.
| rat9988 wrote:
| I for one welcome it. I want to know if there are some
| vulnerabilities in the software I use.
| ChrisMarshallNY wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| gowld wrote:
| If no one uses the stream type, then not fixing the bug won't
| hurt.
|
| The people who do use the stream type are at risk, and have
| been at risk all along. They need to stop using the stream
| type, or get the bug fixed, or triage the but as not
| exploitable.
| Seattle3503 wrote:
| > "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 wrote:
| I doubt there's an endgame in mind. It's probably small teams
| trying to optimize their quarterly KPIs
| strictnein wrote:
| > 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 wrote:
| Google is evil.
| skybrian wrote:
| 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
| FridgeSeal wrote:
| 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_ wrote:
| Try xcancel instead:
| https://xcancel.com/argvee/status/1986194852669964528
| izacus wrote:
| Google is one of the largest contributors to OSS in the
| world, so they're already throwing literal millions at OSS?
| strictnein wrote:
| Nice to see coming from Google. Some other current and form
| Google employees were unfortunately not as professional in
| their interactions on Twitter in regards to this issue.
| shevy-java wrote:
| 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 wrote:
| The Tragedy of the Bazaar.
| deepriverfish wrote:
| why don't they just ignore Goole and work at their own pace?
| lamontcg wrote:
| 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.
| mclanett wrote:
| What happens if ffmpeg ignores (after triage) the minor CVEs?
| gowld wrote:
| Life goes on.
| firefax wrote:
| 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.
| vzaliva wrote:
| Is it me or the linked article seems to be heavily co-authored by
| AI. The cadence is very monotonic and dull.
| erikerikson wrote:
| 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 wrote:
| 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 wrote:
| 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?
___________________________________________________________________
(page generated 2025-11-11 23:01 UTC)