Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

371–380 of 913 posts

Re: FFmpeg to Google: Fund us or stop sending bugs

#371

Earlier quoted context omitted.

> 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 are…

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 Go…

But if no bug report is filed, then only google gets the ability to "be responsible for their own security", everyone else either has to independently discover and then patch the bug themselves, or wait until upstream discovers the bug.

In no reasonable reading of the situation can I see how anything Google has done here has made things worse:

1) Before hand, the bug existed, but was either known by no one, or known only by people exploiting it. The maintainers weren't actively looking at or for this particular bug and so it may have continue to go undiscovered for another 20 years.

2) Then Google was the only one that knew about it (modulo exploiters) and were the only people that could take any steps to protect themselves. The maintainers still don't know so everyone else would remain unprotected until they discover it independently.

3) Now everyone knows about the issue, and are now informed to take whatever actions they deem appropriate to protect themselves. The maintainers know and can choose (or not) to patch the issue, remove the codec or any number of other steps including deciding it's too low priority in their list of todos and advising concerned people to disable/compile it out if they are worried.

#3 is objectively the better situation for everyone except people who would exploit the issue. Would it be even better if Google made a patch and submitted that too? Sure it would. But that doesn't make what they have done worthless or harmful. And more than that, there's nothing that says they can't or won't do that. Submitting a bug report and submitting a fix don't need to happen at the same time.

It's hard enough convincing corporations to spend any resources at all on contributing to upstream. Dragging them through the mud for not submitting patches in addition to any bug reports they file is in my estimation less likely to get you more patches, and more likely to just get you less resources spent on looking for bugs in the first place.

Re: FFmpeg to Google: Fund us or stop sending bugs

#372
post #323

Earlier quoted context omitted.

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 comp…

As yet, Valve is the only company I know of doing this, and it's paying off in dividends both for Linux and for Valve. In just 5ish years of Valve investing people and money into Linux- specifically mesa and WINE, Linux has gone from a product that is kind of shaky with Windows, to "I can throw a windows program or game at it and it usually works". Imagine how further the OSS ecosystem would be if Open Source hadn't…

> Valve is the only company I know of [upstreaming fixes for open source software]

Sorry, that's ridiculous. Basically every major free software dependency of every major platform or application is maintained by people on the payroll of one or another tech giant (edit: or an entity like LF or Linaro funded by the giants, or in a smaller handful of cases a foundation like the FSF with reasonably deep industry funding). Some are better than others, sure. Most should probably be doing more. FFMpeg in particular is a project that hasn't had a lot of love from platform vendors (most of whom really don't care about software codecs or legacy formats anymore), and that's surely a sore point.

But to pretend that SteamOS is the only project working with upstreams is just laughable.

Re: FFmpeg to Google: Fund us or stop sending bugs

#373
post #324

Earlier quoted context omitted.

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.

> They could, but there is really no requirement on them to do so. I see this sort of sentiment daily. The sentiment that only what is strictly legal or required is what matters. Sometimes, you know, you have to recognise that there are social norms and being a good person matters and has intrinsic value. A society only governed by what the written law of the land explicitly states is a dystopia worse than hell.

What's "strictly legal or required" of Google here is absolutely nothing. They didn't have to do any auditing or bug hunting. They certainly didn't have to validate or create a proper bug report, and there's no requirement whatsoever that they tell anyone about it at all. They could have found the bug, found it was being actively exploited, made their own internal patch and sat quietly by while other people remained vulnerable. All of that is well within what is "strictly legal or required".

Google did more than what is "strictly legal or required", and what they did was submit a good and valid bug report. But for some reason we're mad because they didn't do even more. Why? The world is objectively a better place for having this bug report, at least now people know there's something to address.

Re: FFmpeg to Google: Fund us or stop sending bugs

#374
post #63

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.

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.

What in GPL3 or MIT mandates that Google fix this bug and submit a PR or simply sends a bug report and walks away? I don't see how this applies at all.

Re: FFmpeg to Google: Fund us or stop sending bugs

#375
post #299

Earlier quoted context omitted.

[flagged]

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 wor…

I don't think ffmpeg is terribly affected by whether a codec is patent-encumbered or not

Re: FFmpeg to Google: Fund us or stop sending bugs

#376

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 liste…

How could ffmpeg maintainers kill three major AWS product lines with an email?

Open up an Amazon media app and navigate around enough, and you'll encounter a page with all their "Third Party Software Licenses."

For instance, here's one for the Amazon Music apps, which includes an FFMpeg license: https://www.amazon.com/gp/help/customer/display.html?nodeId=...

Re: FFmpeg to Google: Fund us or stop sending bugs

#377
post #57

Earlier quoted context omitted.

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...

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.

I'm just imagining them having 4 or 5 250K a year security workers pumping out endless bug reports for one guy in Norway who works on ffmpeg at night and weekends for free because he loves open source and demanding him meet their program deadlines lol

Re: FFmpeg to Google: Fund us or stop sending bugs

#378

Earlier quoted context omitted.

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 comp…

I've literally had my employer's attorneys tell me I can't upstream patches because it would put my employer's name on the project, and they don't want the liability. No, it didn't help giving them copies of licenses that have the usual liability clauses. It seems a lot of corporate lawyers fundamentally misunderstand open source.

Corporate counsel will usually say no to anything unusual because there's no personal upside for them to say yes. If you escalate over their heads with a clear business case then you can often get a senior executive to overrule the attorneys and maybe even change the company policy going forward. But this is a huge amount of extra unpaid work, and potentially politically risky if you don't have a sold management chain.

Re: FFmpeg to Google: Fund us or stop sending bugs

#379
post #63

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.

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 Nee…

FFMPEG, at no cost to Google, provided a core piece of their infrastructure for multiple multi-billion dollar product lines.

Re: FFmpeg to Google: Fund us or stop sending bugs

#380

Earlier quoted context omitted.

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 comp…

I've literally had my employer's attorneys tell me I can't upstream patches because it would put my employer's name on the project, and they don't want the liability. No, it didn't help giving them copies of licenses that have the usual liability clauses. It seems a lot of corporate lawyers fundamentally misunderstand open source.

Sounds like your employers attorneys need to be brought to heel by management. Like most things, this is a problem of management not understanding that details matter.
Post reply on HN