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

451–460 of 913 posts

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

#451

Post by rossjudson »

fao_ wrote: post #323
skhameneh wrote: post #264

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…

I'm glad you threw in "I know of", because that part is true.

Feel free to read lore.kernel.org, and sort out where the people contributing many patches actually work.

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

#452

Post by saagarjha »

ahepp wrote: post #354
f33d5173 wrote: post #291

Earlier quoted context omitted.

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.

I can tell you with 100% certainty that there are undiscovered vulnerabilities in the Linux kernel right now. Does that mean they should stop shipping? I do think that contributing fuzzing and quality bug reports can be beneficial to a project, but it's just human nature that when someone says "you go ahead and do the work, I'll stand here and criticize", people get angry. Rather than going off and digging up ten tim…

You will note the Linux kernel is not crying on Twitter when Google submits bugs to them. They did long ago, then realized that the bugs that Google reported often showed up exploited in the wild when they didn’t fix them, and mostly decided that the continuous fuzzing was actually a good thing. This is despite not all the bugs being fixed on time (there are always new OSSFuzz bugs in the queue for fixing).

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

#453

Post by pabs3 »

colonwqbang wrote: post #335
astrange wrote: post #311

Earlier quoted context omitted.

ffmpeg cannot relicense anything because it doesn't own anything. The contributors own the license to their code.

Relicensing isn't necessary. If you violate the GPL with respect to a work you automatically lose your license to that work. It's enough if one or two main contributors assert their copyrights. Their contributions are so tangled with everything else after years of development that it can't meaningfully be separated away.

In addition, there is the potential for software users to sue for GPL compliance. At least that is the theory behind the lawsuit against Vizio:

https://sfconservancy.org/copyleft-compliance/vizio.html

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

#454

Post by saagarjha »

adastra22 wrote: post #369
viraptor wrote: post #231

Earlier quoted context omitted.

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.

I have yet to see one on any project I’ve been attached to that was actually exploitable under real circumstances. But the CVE hunting teams treat them all as if they were.

You should honestly consider not responding if you are unaware of Project Zero.

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

#455

Post by tpmoney »

shevy-java wrote: post #195

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

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

Google has a pretty regular stream of commits in the ffmpeg git history, and is proudly declared to be a customer of `fflabs.eu`, which appears to be the ffmpeg lead maintainer's private consulting company. Two of the maintainers on ffmpeg's "hire a dev" page[1] are also listed as employees of fflabs[2]. Honestly, Google seems like they're being a model for how corporations can give back to OSS better and benefit from that, but instead everyone is up in arms because they don't give patches in all of their bug reports.

[1]: https://ffmpeg.org/consulting.html [2]: https://fflabs.eu/about/

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

#456

Post by fulafel »

ahepp wrote: post #266
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.

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…

It's neither. WP says:

> After finding a number of flaws in software used by many end-users while researching other problems, such as the critical "Heartbleed" vulnerability, Google decided to form a full-time team dedicated to finding such vulnerabilities, not only in Google software but any software used by its users.

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

#457

Post by saagarjha »

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.

Because it gives maintainers a chance to fix the issue, which they’ll do if they feel it is a priority. Google does not decide your priorities for you, they just give you an option to make their report a priority if you so choose.

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

#458

Post by taviso »

hitekker wrote: post #434
taviso wrote: post #432

Earlier quoted context omitted.

why would you post such a patently absurd accusation.

I saw that tweet and thought it looked crazy. To me, it sounds like a death threat. Especially given that it's posted on X.com, after a really heated argument, with no clarification afterwards. If you didn't actually post that tweet, that's great! I'm happy to be corrected

If you hear a rumor that sounds too crazy to be true on social media, maybe don't repeat it as fact. Imagine how you would feel reading something like that.

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

#459

Post by woodruffw »

tofuahdude wrote: post #379
iscoelho wrote: post #161

Earlier quoted context omitted.

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.

"At no cost to Google" seems difficult to substantiate, given that multiple sources indicate that Google is sponsoring FFmpeg both with engineering resources (for codec development) and cold hard cash (delivered to the FFmpeg core team via their consulting outfit[1]).

This is excellent, to be clear. But it's not compatible with the yarn currently being spun of a purely extractive relationship.

[1]: https://fflabs.eu

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

#460

Post by rossjudson »

michaelt wrote: post #282
jeffbee wrote: post #244

Earlier quoted context omitted.

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

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

I'm sure that a hacker wouldn't think of trying to use an obscure format...

https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...

Post reply on HN