[bawolff]

I think that is a little entitled. They should be happy google isn't just straight up emailing full-disclisure.

The person who makes the software has the duty to fix the security issues in their own code, nobody else, no matter how big they are.

[waste_monk]

>I think that is a little entitled. They should be happy google isn't just straight up emailing full-disclisure.

Google has literally billions of dollars in profits (in part because they use FFmpeg in a bunch of commercial products like Youtube and Chrome), and one of the largest software workforces in the world, including expertise on secure software and vulnerability remediation.

If anyone can afford to contribute back a fix instead of just raising a report, and has the ethical responsibility to do so, it's Google.

[godelski]

  > because they use FFmpeg in a bunch of commercial products like Youtube and Chrome

Not to mention they just have a vested interest in getting the problem solved. Even if we don't talk about money.

I'm not sure why this is an unpopular idea, but contribute back to your upstream dependencies. If they're a dependency, they're part of *your code*.

[bawolff]

> Not to mention they just have a vested interest in getting the problem solved. Even if we don't talk about money.

Correct me if im wrong, but based on the report this looks like something that would affect regular users of ffmpeg but not google's use.

[godelski]

FWIW I tried replicating it and didn't get the same result. I end up with a failed conversion, exit code 69[0]. Same thing when I run with my installed version of ffmpeg.

But I think Google would still be concerned. Even if they're running ffmpeg in a sandbox you can escape sandboxes. The sandbox is a security layer, not what makes the thing safe. You should be using it as a layer of defense for unknown vulns, and try to resolve vulns. I mean Google is much more likely to have an attacker trying to chain a vuln with a sandbox escape than the average user.

Btw:

  ffmpeg -codecs | cat | grep SANM 2&>/dev/null
  ffmpeg version n8.0 Copyright (c) 2000-2025 the FFmpeg developers
  ... ffmpeg flags ...
  D.V.L. sanm                 LucasArts SANM/SMUSH video

So my version does have that codec, as others are reporting.

[0] Will expire soon https://0x0.st/KL6K.log

[DISCLOSURE]: I AM NOT A SECURITY PROFESSIONAL. If I am wrong please correct me

[jsnell]

You're running version 8.0. That's the version where this was fixed.

[bawolff]

Security vulnerability finding is a contribution. On the open market the type of service google is providing here would cost hundreds of thousands of dollars if not millions.

[leoedin]

> The person who makes the software has the duty to fix the security issues in their own code, nobody else, no matter how big they are.

That’s just clearly untrue for freely available software. So every person that ever published a hobby project on GitHub has a duty to fix security issues in it?

The organisation who ships software to paying customer may have a duty to fix security issues. If they didn’t, it could be seen as negligent, violate regulations or the contract they have with their customers. But there’s no contract with the free software developers. No duty of care from them to end users. Absolutely no duty.

[x0x0]

Be careful, the Europeans tried (had the python foundation not pushed back hard, would have) and still would love to require anyone who's ever built a piece of software to perform maintenance for them on demand.

[bawolff]

> That’s just clearly untrue for freely available software. So every person that ever published a hobby project on GitHub has a duty to fix security issues in it?

Yes, i think there is a moral duty if you are presenting the software for the general public to use. Or if you dont to at least make it clear how you handle stuff so that users can make their own decisions.

> But there’s no contract with the free software developers. No duty of care from them to end users. Absolutely no duty.

In your view would it be acceptable to backdoor open source software to sell user's data to the highest bidder? That's obviously not what happened here, but seems like the obvious conclusion of your argument.

[63stack]

Software licenses already make the conditions íj which they are offered to you very clear.

It is up to you, the end user of the software to evaluate whether those terms, risks, and options are good enough for you. If not, don't use it. You have it completely backwards, and frankly, sound quite entitled.

[bawolff]

Morality and legality are not the same thing.

Although perhaps my previous comment went a little too far. I think its fine to not fix issues as long as you publish them so that users can make an informed decision. Where i think it would be morally wrong is if a project pretends it fixes security issues but doesn't or if it tries to cover them up - insisting external reporters dont talk about them while also having no intention of fixing them.

Basically i think open source projects (like everyone) have a moral duty to be honest and not try and decieve people, regardless of what the license says.

[63stack]

You make it sound like this is a common problem in open source projects, like they are trying to cover up existing issues, or claiming they are fixing security issues when they are actually ignoring. Do you think this is the case? Can you name a few projects where you noticed this?

[hitekker]

Nah, it's entitlement to expect maintainers to overwork and fix every single "security" issue thrown their way. ffmpeg has just a few resources and Google has way, way more. The maintainers are not your servants nor are they Google's servants.

[godelski]

Doesn't Chrome use libavcodec?

I'm somewhat with you but we're also talking about a $3.4T company that's depending on an OSS project with what... under a $1m budget? It seems they're pretty resource constrained.

I'm pretty sure Google makes more through Chrome's usage of libav than ffmpeg's entire budget. So yeah, I think Google should put effort back in and I think it's in their best interest.

Trillion dollar companies standing on top of open source projects and giving little to nothing back is not okay. It's also just stupid since they're eating their own foundations

[thatguysaguy]

It's a volunteer run project... Saying that they have a duty to do anything other than what they want is quite strange.

[eipi10_hn]

Duh no, wtf. No one has the duty to fix the security issue unless they are paid for the open source codes they give. They don't threaten you to use their codes either.

If you want the security issue to be fixed, make a PR or offer the price you are willing to pay for them to fix.

[bawolff]

By the same token nobody has the duty to responsibly disclose security bugs. The entire premise of responsible disclosure is that security researchers give time for upstream projects to fix security issues by privately reporting the issues, in exchange the maintainers graciously accept the reports. Its a deal that benefits maintainers much more than it benefits researchers. If ffmpeg doesn't want that deal, then google should go the full disclosure route.

> If you want the security issue to be fixed,

There is no indication that google actually cared much whether the issue got fixed or not. It seems like the course of events is that they noticed something looked wrong with the code so they filed a bug. That's it.

> willing to pay for them to fix.

Should ffmpeg pay for security researchers time to find these issues? The market price for that is much much much higher than the price to fix bugs.

If you were to pay someone to do vulnerability testing in ffmpeg with sufficient skill to find this issue, it would probably cost you in the hundreds of thousands of dollars at least.

[eipi10_hn]

Yes, that's right. Nobody has the duty to disclosure the security bugs. It's the security researchers' principles, and if they want to follow that, they can follow that.

But don't take it further that the maintainers have the duty to fix the issues. They choose that career, don't make it sound like ffmpeg is forcing them to disclosure. Maintainers don't "deal" with any security researchers about those, and don't put the confidence that it "benefits maintainers" than "benefit researchers", unless the maintainers declare that themselves. In this case there's no patch, no fix, no PR either, just issue-submission. "You have more benefits" are the claims of the researchers who think that their issue-submission contributions top everything else.

Finding and disclosing the security are issue-submission contributions, and that's it. Don't make it as a gift or something. ffmpeg doesn't have the need to find these issues, and they don't pay for it for it either. And vice versa, they have no duties to fix the issues. They don't force the security researchers to find and disclose things. If security researchers want to do it themselves, they can do whatever they want, but stop at forcing duties to the maintainers. The only thing I don't agree with ffmpeg is bringing those issues social while they can just ignore them, that's it.

[bawolff]

I mean, i agree, ffmpeg are under no obligation to do anything. (In the heat of the moment i think my previous comment went too far, i would phrase it more, as if you want to be a "quality" software project then you have to respond to real security bugs promptly).

My biggest gripe though is that ffmpeg does seem to value these sorts of reports highly. If i'm reading the timestamps right, they fixed this report within 1 day: https://github.com/FFmpeg/FFmpeg/commit/c41a70b6bb79707e1e3a...

How often do you get your bug reports fixed that fast? When i file bugs in open source projects it usually takes at least weeks if im lucky to get a response. People almost never respond within 1 day. I think that demonstrates how valuable ffmpeg views these reports.

If the report was a garbage report (like e.g. the ones the curl maintainer complains about) i'd have more sympathy, but clearly ffmpeg views this issue submission as valuable. The whole thing makes me think of choosing-beggars. They want the google report but also are trying to use social pressure to make google contribute even more.

If they didn't want google's reports that's one thing - just reject them, but both wanting them while also demanding more is scummy in my opinion. Either accept or reject them.

[eipi10_hn]

Nope. Don't mistake a quick fix as they are "valuable" to the maintainers. They said clearly that it's a hobby project and at the most it just simply means that some volunteers were interested and wanted to fix it, or the fix is not complex, and I would just stop at that. The "valuable" is, again, an outsider view that is forced to the maintainers. Same as "They want google report" thing. Just because they fix some issues reported from someones doesn't mean that they view all of those reports being "valuable".

At most, I would just see that they are annoyed by the issue procedures (without PRs) of the "researchers" and they complaint on the social. I don't agree with their complaints because the "researchers" did nothing wrong either. And that's it, I would stop at that. Putting the whole "duty", "valuable reports" and "demand more" on them is just as bs as their complaints.

[bawolff]

> volunteers were interested and wanted to fix

If that's not the definition of valuable then what is?

As you said, its a volunteer project. What other metric of value is there other than a volunteer being interested?

[polski-g]

No person, ever, has a duty to fix security issues in free software with a no-warranty license. If you want your security fixes, pay for them.

[toofy]

i’m sorry, but when it comes to open source software if you want something on your timeline, you do it. the code is there. it’s _open_.

if “a duty” exists at all in this situation, it’s on the 4th wealthiest company in the world who is using that free software to serve its customers and raking in billions of dollars. (i want to be clear tho, that company does contribute a lot to the open source community. a whole lot. i’m just saying, if someone is hunting for a “duty” to fling around re: an open source project)

i was once naively saying some undeserved similar nonsense to a well known open source dev regarding some software package they were working on years ago, and he responded absolutely appropriately, [paraphrasing] “go ahead, you should absolutely do it, see if it’s better. none of us here are stopping you. we genuinely hope it is, truly. let us know. until then we’re working on other stuff.”

he was absolutely correct and i should have known better. not snotty at all, just, “you should totally do it!” that’s the appropriate answer every single time someone behaves as if your open source project owes them something. even more so when it’s the 4th richest company in the world.

so if you feel “a duty” exists somewhere to change something with ffmpeg, do it yourself. literally no one is stopping you. it’s _open source_.