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

791–800 of 913 posts

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

#791

Post by Wowfunhappy »

walletdrainer wrote: post #620
bigiain wrote: post #504

Earlier quoted context omitted.

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

Or perhaps you’re a FAANG security researcher and your time will be better spent serving the OSS community as a whole by submitting as many useful bug reports as possible, instead of slightly fewer reports with patches included. In this particular case it’s hardly obvious which patch you should submit. You could fix this particular bug (and leave in place the horrible clunky codec that nobody ever uses) OR you could…

I don’t understand how it helps the community to publicly release instructions for attacking people, unless you’re trying to incentivize a company to fix their crap. In this case, there is no company to incentivize, so just report it privately.

You can say publicly that “there is an ABC class vulnerability in XYZ component” so that users are aware of the risk.

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

#792

Post by jlarocco »

skhameneh wrote: post #264
phkahler wrote: post #54

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 sympathize and understand those issues for small companies, but after a certain size those excuses stop being convincing.

Especially for a software company like Google who runs dozens of open source projects, employs an army of lawyers to monitor compliance, and surely has to deal with those issues on a daily basis anyway.

At some point there needs to be pushback. Companies get a huge amount of value from hobbiest open source projects, and eventually they need to start helping out or be told to go away.

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

#793

Post by astrange »

deaddodo wrote: post #518
astrange wrote: post #353

Earlier quoted context omitted.

Doubtful that's enough for a copyright grant. You'd need a signed CLA.

No one said make it proprietary; there are other OSS licenses that would make ffmpeg non-viable for commercial usage.

You need a copyright grant to change the license in any way.

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

#794

Post by chanux »

Cthulhu_ wrote: post #692
poulpy123 wrote: post #650

Earlier quoted context omitted.

Nothing says solid industry better than having 3 majors product lines from a trillion dollar company depending of unpaid volunteer labor.

I think if you look a bit deeper, all product lines from said trillion dollor company rely on open source to some degree. They should be spending hundreds of millions in sponsorship of OS projects. They should put the maintainers on their payroll. Not even reporting to a manager, just pay them a salary for their OS work.

I have a feeling that if they do this, the economy would be hurt (somehow).

None of us want the economy to be hurt, right?

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

#795

Post by CSSer »

theoldgreybeard wrote: post #733
vsgherzi wrote: post #427

Earlier quoted context omitted.

I disagree, as software engineers we owe it to the craft to create correct software especially when we intend to distribute. Anything less is poor taste. You bring up licensing. I’m not talking about legally I’m talking about a social contract.

The choice of license is also a a partial descriptor of the social contract. If I wanted to work on it for “customers” I would sell it. I don’t owe you anything otherwise. The social contract is “here is something I’ve worked on for free, and it is a gift. Take it or leave it.” You want me to work on something for it? FYPM

For GP's sake, even before you make it to FYPM levels of angry, you will be in over your head. It's too much work. I remember being very early in my career and feeling like GP does. This is very easily more than a full-time job. The demands people will make of you and the attitudes they will use to do it will make you crazy.

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

#796

Post by amelius »

Propelloni wrote: post #723
codeptualize wrote: post #706

I think the glaring issue underlying this is that the big companies are not investing enough in the tools they rely on. I agree with some of the arguments that patching up vulnerabilities is important, but it's crazy to put that expectation on unpaid volunteers when you flood them with CVE's some completely irrelevant. Also the solution is fairly simple: Either, you submit a PR instead of an issue. Or, you send a gen…

The solution is even simpler. The project puts the bug report in its triage backlog. It works through it in its own time, and decides on severity and priority. That's the time-honored method. The compounding factor here is the automated reporting and disclosure process of Google's Project Zero. GPZ automatically discloses bugs after 90 days. Even if Google does not expect bugs to be fixed within this period, the FFmp…

Is it legal to disclose security vulnerabilities within such a short period?

It certainly does not seem ethically correct.

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

#797

Post by lokar »

renhanxue wrote: post #389
jsnell wrote: 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…

Anyone running this code with untrusted input needs to sandbox it (which Google has been doing all along).

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

#798

Post by xxs »

wewtyflakes wrote: post #115
NewsaHackO wrote: post #101

Earlier quoted context omitted.

But if it gets relicensed, they would still be able to use the current version. Amazon definitely would be able to fund an independent fork.

Sounds like it would be a lot of churn for nothing; if they can fund a fork, then they could fund the original project, no?

They can't - it's LGPL 2.1. So the fork would be public essentially.

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

#799

Post by jrm4 »

red-iron-pine wrote: post #740
fao_ wrote: post #323

Earlier quoted context omitted.

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…

WINE was a thing for years and generally worked okay for a lot of things. I was playing Fallout 3 on WINE well before Valve got involved with minimal tweaks or DIY effort. Proton with Steam works flawlessly for most things including AAA games like RDR2 and it's great, but don't forget that WINE was out there making it work for a while

But this is a perfect example of one of those "90/10" esque ideas.

Even if Wine was 90% there technologically, the most important 90% is really that last 10.

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

#800

Post by walletdrainer »

Wowfunhappy wrote: post #791
walletdrainer wrote: post #620

Earlier quoted context omitted.

Or perhaps you’re a FAANG security researcher and your time will be better spent serving the OSS community as a whole by submitting as many useful bug reports as possible, instead of slightly fewer reports with patches included. In this particular case it’s hardly obvious which patch you should submit. You could fix this particular bug (and leave in place the horrible clunky codec that nobody ever uses) OR you could…

I don’t understand how it helps the community to publicly release instructions for attacking people, unless you’re trying to incentivize a company to fix their crap. In this case, there is no company to incentivize, so just report it privately. You can say publicly that “there is an ABC class vulnerability in XYZ component” so that users are aware of the risk.

It’s OSS so somebody who cares will fix it, and if nobody cares then it doesn’t really matter.

This also informs users that it’s not safe to use ffmpeg or software derived from it to open untrusted files, and perhaps most importantly releasing this tells the distro package maintainers to disable the particular codec when packaging.

Post reply on HN