Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

Post reply on HN
Print view View original

301–310 of 913 posts

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

#301

Post by inkysigma »

Yokolos wrote: post #229
woodruffw wrote: post #10

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

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…

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.

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

#302

Post by SR2Z »

lenerdenator wrote: post #281
SR2Z wrote: post #185

Earlier quoted context omitted.

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.

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

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.

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

#303

Post by SR2Z »

danaris wrote: post #246
SR2Z wrote: post #178

Earlier quoted context omitted.

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

Then they can damn well pay for fixing them too .

That's not a choice. You can decide if Google files bugs like this or not, you can't force them to fix them.

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

#304

Post by SR2Z »

angiolillo wrote: post #218
SR2Z wrote: post #185

Earlier quoted context omitted.

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.

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

Only if you subscribe to the "if we stop testing, the number of cases will drop!" philosophy.

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

#305

Post by SR2Z »

strictnein wrote: post #211
SR2Z wrote: post #185

Earlier quoted context omitted.

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.

Personally, I want the $3.5 Trillion company to do more. So the line should be somewhere else.

So you don't have a line, you just want to move the goalposts and keep moving them?

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

#306

Post by rat9988 »

themafia wrote: post #224
shevy-java wrote: post #200

Earlier quoted context omitted.

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

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

I for one welcome it. I want to know if there are some vulnerabilities in the software I use.

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

#307

Post by LexiMax »

edoceo wrote: post #182
cortesoft wrote: post #169

Earlier quoted context omitted.

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.

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.

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

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

#308

Post by toast0 »

BobaFloutist wrote: post #296
toast0 wrote: post #133

Earlier quoted context omitted.

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.

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

Sure, but running a fuzzer on ancient codecs isn't that special. I can't do it, but if I wanted to learn how, codecs would be a great place to start. (in fact, Google did some of their early fuzzing work in 2012-2014 on ffmpeg [1]) Media decoders have been the vector for how many zero interaction, high profile attacks lately? Media decoders were how many of the Macromedia Flash vulnerabilities? Codecs that haven't gotten any new media in decades but are enabled in default builds are a very good place to go looking for issues.

Google does have immense scale that makes some things easier. They can test and develop congestion control algorithms with world wide (ex-China) coverage. Only a handful of companies can do that; nation states probably can't. Google isn't all powerful either, they can't make Android updates really work even though it might be useful for them.

[1] https://security.googleblog.com/2014/01/ffmpeg-and-thousand-...

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

#309

Post by GabrielTFS »

Msurrow wrote: post #30
danlitt wrote: post #27

Earlier quoted context omitted.

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

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.

Full (immediate) disclosure, where no time is given to anyone to do anything before the vulnerability is publicly disclosed, was historically the default, yes. Coordinated vulnerability disclosure (or "responsible disclosure" as many call it) only exists because the security researchers that practice it believe it is a more effective way of minimizing how much the vulnerability might be exploited before it is fixed.

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

#310

Post by Brian_K_White »

rcxdude wrote: post #295
Brian_K_White wrote: post #250

Earlier quoted context omitted.

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

If I know it's a bug and I use ffmpeg, I can avoid it by disabling the affected codec. That's pretty valuable.

More fantasy. Presumes the bug only exists in some part of ffmpeg that can be disabled at all, and that you don't need, and that you are even in control over your use of ffmpeg in the first place.

Sure, in maybe 1 special lucky case you might be empowered. And in 99 other cases you are subject to a bug without being in the remotest control over it since it's buried away within something you use and don't even have the option not to use the surface service or app let alone control it's subcomponents.

Post reply on HN