Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

501–510 of 913 posts

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

#501

Earlier quoted context omitted.

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

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/apirefe... CAUTION: big PD…

" ... and it can do insane stuff"

That's a pretty good indicator it's likely just ffmpeg in an AWS Hoodie/Trenchcoat.

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

#503

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…

Hmmmm. There's probably just one guy who wrote the ffmpeg code for that format. _Maybe_ one or two more who contributed fixes or enhancements?

The ffmpeg project need to get in touch and get then to assign copyright to the ffmpeg project, then delete that format/decoder from ffmpeg. Then go back to Google with an offer to licence then a commercial version of ffmpeg with the fixed SANM ANIM v0 decoder, for the low low price of only 0.0001% of YouTube's revenue every year. That'd likely make them the best funded open source project ever, if they pulled it off.

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

#504

Earlier quoted context omitted.

Sure, it's a valid bug report. But I don't understand why there has been so much drama over this when all the ffmpeg folks have to do is say "sorry, this isn't a priority for us so we'll get to it as soon as we can" and put the issue in the backlog as a low priority. If Google wants the issue fixed faster, they can submit a fix. If they don't care enough to do that, they can wait. No big deal either way. Instead, ffm…

FFMPEG is upset because Google made the exploit public. They preferred that it remained a zero-day until they decided it was a priority. I don't understand how anyone believes that behavior is acceptable.

That behaviour is indeed totally unacceptable. At your job. Where they're paying you, and especially if they're paying you at FAANG type pay scales.

If you're an unpaid volunteer? Yeah - nah. They can tell you "Sorry, I'm playing with my cat for the next 3 months, maybe I'll get to it after that?", or just "Fuck off, I don't care."

(I'm now playing out a revenge fantasy in my head where the ffmpeg team does nothing, and Facebook or Palantir or someone similar get _deeply_ hacked via the exploit Google published and theat starts the planets biggest ever pointless lawyers-chasing-the-deepest-pockets fight.)

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

#505
post #305

Earlier quoted context omitted.

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?

location of goalposts scales with market cap

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

#506

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…

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…

> 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’ve been at several companies where upstreaming was encouraged for everything. The fewer internal forks we could maintain, the better.

What surprised me was how many obstacles we’d run into in some of the upstream projects. The amount of time we lost to trying to appease a few maintainers who were never happy with code unless they wrote it themselves was mind boggling.

For some projects you can basically forget about upstreaming anything other than an obvious and urgent bug fix because the barriers can be so high.

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

#507

Earlier quoted context omitted.

Ffmpeg makes it trivial to enable and disable individual codecs at compile time. Perhaps it's the Linux distros that need to make a change here?

I get that the ffmpeg people have limited time and resources, I get that it would be nice if Google (or literally anyone else) patched this themselves and submitted that upstream. But "everyone else down stream of us should compile out our security hole" is a terrible way to go about things. If this is so obscure of a bug that there's no real risk, then there's no need for anyone to worry that the bug has been report…

> But "everyone else down stream of us should compile out our security hole" is a terrible way to go about things.

Is that somehow _less_ of a terrible way to think than "someone who's contributed their time as a volunteer to an open source software project that we have come to rely on, now has some sort of an obligation to drop everything and do more unpaid work for a trillion dollar company"?

> it really needs to be fixed in the up stream

Lots of people love using "Free Software" that they didn't have to write as essential parts of their business.

Way too many of them seem to blink right when they get to this bit of the licence they got it with:

SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

(That's directly from Section 15 "NO WARRANTY of https://code.ffmpeg.org/FFmpeg/FFmpeg/src/branch/release/4.0... )

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

#508

Earlier quoted context omitted.

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.

TFA is about Project Zero getting uppity about an unexploitable non-issue in ffmpeg.

Project Zero hasn't reported any vulnerabilities in any software I maintain. Lots of other security groups have, some well respected as well, but to my knowledge none of these "outside" reports were actual vulnerabilities when analyzed in context.

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

#509
post #289

Earlier quoted context omitted.

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

There are dozens if not hundreds of issues just like this one in ffmpeg, except for codecs that are infinitely more common. Google has been running all sorts of fuzzers against ffmpeg for over a decade at this point and it just never ends. It's a 20 year old C project maintained by poorly funded volunteers that mostly gives every media file ever the be-liberal-in-what-you-accept treatment, because people complain if…

> Google has been running all sorts of fuzzers against ffmpeg for over a decade at this point

Yeah. It's called YouTube... Why run fuzzers if you can get people to upload a few million random videos every day? ;-)

(I wonder if the BigSleep AI was trained on or prompted with YouTube error logs?)

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

#510
post #489

Earlier quoted context omitted.

AGPL is banned from many BigCorps IIRC.

Right, but how is that a benefit here? The bug report was a valid report, ffmpeg is objectively better for it having been filed. Google contributes to ffmpeg on a regular basis according to the git history. They also buy consulting services from the ffmpeg maintainers according to the maintainer's own website. If ffmpeg was banned from Google, all of that would probably stop. So not only would ffmpeg have multiple un…

Spite I guess.
Post reply on HN