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

681–690 of 913 posts

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

#681

Post by cornonthecobra »

grumbelbart2 wrote: post #555
mmooss wrote: post #550

Earlier quoted context omitted.

Why would they invest resources - scarce, expensive time of attorneys - in researching and solving this problem? The attorneys' job is to help the company profit, to maximize ROI for legal work. Where is the ROI here? And remember, just positive ROI is unacceptable; they want maximum ROI per hour worked. When the CEO asks them how this project maximized ROI, what do they say? I believe in FOSS and can make an argumen…

If you fixed something in an open source library you use, and you don't push that upstream, you are bound to re-apply that patch with every library update you do. And today's compliance rules require you to essentially keep all libraries up to date all the time, or your CVE scanners will light up. So fixing this upstream in the original project has a measurable impact on your "time spent on compliance and updates KPI…

This touches on what I ended up telling them: maintaining a local patchset is expensive and fragile. Running customized versions of things is a self-inflicted compliance problem.

I still had to upstream anonymously, though.

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

#682

Post by Orygin »

walletdrainer wrote: post #625
samus wrote: post #598

Earlier quoted context omitted.

Why should Google not be expected to also contribute fixes to a core dependency of their browser, or to help funding the developers? Just publishing bug reports by themselves does not make open source projects secure!

Google does do that. This bit of ffmpeg is not a Chrome dependency, and likely isn’t used in internal Google tools either. > Just publishing bug reports by themselves does not make open source projects secure! It does, especially when you first privately report them to the maintainers and give them a plenty of time to fix the bug.

It doesn't if you report lots of "security" issues (like this 25 years old bug) and give too little time to fix them.

Nobody is against Google reporting bugs, but they use automatic AI to spam them and then expect a prompt fix. If you can't expect the maintainers to fix the bug before disclosure, then it is a balancing act: Is the bug serious enough that users must be warned and avoid using the software? Will disclosing the bug now allow attackers to exploit it because no fix has been made?

In this case, this bug (imo) is not serious enough to warrant a short disclosure time, especially if you consider *other* security notices that may have a bigger impact. The chances of an attacker finding this on their own and exploiting it are low, but now everybody is aware and you have to rush to update.

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

#683

Post by rs186 »

joshkel wrote: post #148
skrebbel wrote: post #73

Earlier quoted context omitted.

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

In a follow-up tweet, Mark Atwood eloborates: "Amazon was very carefully complying with the licenses on FFmpeg. One of my jobs there was to make sure the company was doing so. Continuing to make sure the company was was often the reason I was having a meeting like that inside the company." I interpret this as meaning there was an implied "if you screw this up" at the end of "they could kill three major product lines…

Still doesn't make any sense.

The company that I work at makes sure anything that uses third-party library, whether in internal tools/shipped product/hosted product, goes through legal review. And you'd better comply with whatever the legal team asks you to do. Unless you and everyone around you are as dumb as a potato, you are not going to do things that blatantly violates licenses, like shipping a binary with modified but undisclosed GPL source code. And you can be sure that (1) it's hard to use anything GPL or LGPL in the first place (2) even if you are allowed to, someone will tell you to be extra careful and exactly do what you are told to (or not to)

And as long as Amazon is complying with ffmpeg's LGPL license, ffmpeg can't just stop licensing existing code via an email. Of course, unless there is some secret deal, but again, in that case, someone in the giant corporation will make sure you follow what's in the contract.

Basically, at company at Amazon where there are functional legal teams, the chance of someone "screwing up" is very small.

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

#684

Post by jitbit »

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…

True - if we're talking about actual security bugs, not the "CVE slop"

P.S. I'm an open source maintainer myself, and I used to think, "oh, OSS developers should just stop whining and fix stuff." Fast forward a few years, and now I'm buried under false-positive "reports" and overwhelmed by non-coding work (deleting issue spam, triage, etc.)

P.P.S. What's worse, when your library is a security component the pressure’s even higher - one misplaced loc could break thousands of apps (we literally have a million downloads at nuget [1] )

[1]: https://www.nuget.org/packages/AspNetSaml

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

#685

Post by rs186 »

deaddodo wrote: post #329
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.

And then the argument for refusing to just pay ffmpeg developers gets even more flimsy. The entire point here is to pay for the fixes/features you keep demanding, else the project is just going to do as it desires and ignore you. More and more OSS projects are getting to this point as large enterprises (especially in the SaaS/PaaS spheres) continue to take advantage of those projects and treat them like unpaid worker…

Heard of OpenSearch?

There are many reasons, often good ones, not to pay money for an open source project but instead fund your own projects, from a company's perspective.

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

#686

Post by rs186 »

zrm wrote: post #168
arrowleaf wrote: post #120

Earlier quoted context omitted.

If they can fund a fork, they can continue business as usual until the need arises

A fork is more expensive to maintain than funding/contributing to the original project. You have to duplicate all future work yourselves, third party code starts expecting their version instead of your version, etc.

Nobody said the fork cannot diverge from the original project.

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

#687

Post by Orygin »

ikiris wrote: post #516
woodruffw wrote: post #365

Earlier quoted context omitted.

I think it’s exceedingly reasonable for a maintainer to dispute the severity of a vulnerability, and to ultimately decide the severity.

Maintainers rarely understand or agree with the severity of a bug until an exploit beats them over the head publicly in a way they are unable to sweep under the rug.

On the other hand, reporters giving a CVE a 10 for a bug in an obscure configuration option that is disabled by default in most deployments is bit over the top. I've seen security issues being reported as world ending, being there for years, without anyone being able to make an exploit PoC.

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

#689

Post by Orygin »

woodruffw wrote: post #530
WhyNotHugo wrote: post #495

Earlier quoted context omitted.

The issue at hand is that Google has a policy of making the security issue public regardless of whether a fix has been produced. Typically disclosures happen after a fix exists.

This isn’t true at all in my experience: disclosures happen on a timeline (60 to 90 days is common), with extensions provided as a courtesy based on remediation complexity and other case-by-case considerations. I’ve been party to plenty of advisories that went public without a fix because the upstream wasn’t interested in providing one.

For OSS projects or commercial ones? I feel it's not the same when one has trillion in market cap and the other has a few unpaid maintainers.

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

#690

Post by Cthulhu_ »

cornonthecobra wrote: post #361
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…

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.

It goes even further sometimes, I've seen someone in the Go community slack announce they are going to dial back their activity because of Very Serious Clauses in their Apple contract.

That seems to imply that Apple employees are prohibited from being good internet citizens and e.g. helping people out with any kind of software issue. This presumably includes contributing to open source, although I'm sure they can get approval for that. But the fact they have to get approval for it is already a chilling effect.

Post reply on HN