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

861–870 of 913 posts

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

#861

Post by naasking »

tpmoney wrote: post #860
naasking wrote: post #757

Earlier quoted context omitted.

Responsible disclosure policies for contributor-driven projects can differ from commercial projects. Also, if Google has the funds to pay for bug finding, they also have the funds for bug fixing the community projects they depend on.

> Responsible disclosure policies for contributor-driven projects can differ from commercial projects. The can , but there's not an obvious reason why they should . If anything, public disclosure timelines for commercial closed source projects should be much much longer than for contributor-driven projects because once a bug is public ANYONE can fix it in the contributor-driven project, where as for a commercial proj…

> The can, but there's not an obvious reason why they should.

Of course there are obvious reasons: corporations have the resources and incentives to fix them promptly once threatened with disclosure. Corporations don't respond well otherwise. None of these apply to volunteer projects.

> They literally higher the ffmpeg maintainers via the maintainer's consulting business (fflabs.eu) and they routinely contribute code to the ffmpeg project.

Great, then they should loop in the people they're paying on any notification of a vulnerability.

Of course, if this has truly been the case then nobody would have heard of this debacle.

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

#862

Post by Wowfunhappy »

walletdrainer wrote: post #849
Wowfunhappy wrote: post #829

Earlier quoted context omitted.

Right, I just don’t see why they need to publish the actual exploit.

They have not, neither have they indicated that they’re planning to do so.

I thought that was how the 90 day disclosure timeline worked?

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

#863

Post by adastra22 »

GaryBluto wrote: post #589
Ferret7446 wrote: post #190

Earlier quoted context omitted.

So would you rather Google have a secure ffmpeg while us plebian individual users continue to have an insecure ffmpeg?

It's frustrating to me how many people are siding with FFmpeg here considering how unprofessional and generally asshole-ish they are being. I feel that this is mostly a kneejerk reaction to AI and Google in general, with people coming up with arguments to support their reaction after already forming an opinion.

Because we've worked as open-source maintainers and experienced the same frustrating asshole-ish behavior from companies before.

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

#864

Post by LexiMax »

spookie wrote: post #581
KingMob wrote: post #542

Earlier quoted context omitted.

I like FS, but it's always had kind of nebulous morality, though. It lumps in humans with companies, which cannot have morals, under the blanket term "users". This is the same tortured logic as Citizens United and Santa Clara Co vs Southern Pacific Railroad, but applied to FS freedoms instead of corporate personhood and the 1st Amendment. I like the FS' freedoms, but I favor economic justice more, and existing FS lic…

Agree in some ways. Still, discussing the nitty gritty is superfluous, the important underlying message you are making is more existential. Open source software is critical infrastructure at this point. Maintainers should be helped out, at least by their largest users. If free riding continues, and maintainers' burden becomes too large, supply chain attacks are bound to happen.

> Agree in some ways. Still, discussing the nitty gritty is superfluous, the important underlying message you are making is more existential.

It's an important conversation to have.

I remember a particular developer...I'll be honest, I remember his name, but I remember him being a pretty controversial figure here, so I'll pretend not to know them to avoid reflexive downvotes...but this developer made a particular argument that I always felt was compelling.

> If you do open source, you’re my hero and I support you. If you’re a corporation, let’s talk business.

The developer meant this in the context of preferring the GPL as a license, but the problem with the GPL is that it still treats all comers equally. It's very possible for a corporation to fork a GPL project and simply crush the original project by throwing warm bodies at their projects.

Such a project no longer represents the interests of the free software community as a whole, but its maintainers specifically. I also think that this can apply to projects that are alternatives to popular GPL projects, except for the license being permissive.

We need to revisit the four freedoms, because I no longer think they are fit for purpose.

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

#865

Post by esrauch »

cestith wrote: post #755
esrauch wrote: post #321

Earlier quoted context omitted.

Right, Google absolutely should fund ffmpeg. But opening security issues here is not related to that in any way. It's an obscure file format Google definitely doesn't use, the security issue is irrelevant to Google's usages of it. The critique would make sense if Google was asking for ffmpeg to implement something that Google wanted, instead of sending a patch. But they don't actually care about this one, they aren't…

Opening a security issue is not the problem. A public disclosure so soon when there are so many machine-assisted reports for such obscure issues is the problem. If Google wants to force a faster turnaround on the fixes, they can send the reports with patches or they can pay for prioritization.

Google does not "want this fixed", this isn't a bug report from a team using ffmpeg, it's a security analysis from a whitehat security project.

I think really if there's all these machine generated meaningless security reports, wasting time with that sounds like a very sensible complaint, but then they should point at that junk as the problem.

But for the specific CVE discussed it really looks to me like they are doing everything right: it's a real, default-configuration exploitable issue, they reported it and ffmpeg didn't fix or ask for any extension then it gets publicly disclosed after 90 days per a standard security disclosure policy.

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

#866

Post by joemi »

saagarjha wrote: post #436
joemi wrote: post #219

Earlier quoted context omitted.

The fact that details of the issue _will_ be disclosed publicly is an implicit threat. Sure it's not an explicit threat, but it's definitely an implicit threat. So the demand, too, is implicit: fix this before we disclose publicly, or else your vulnerability will be public knowledge.

You should not be threatened by the fact that your software has security holes in it being made public knowledge. If you are, then your goals are fundamentally misaligned with making secure software.

I don't think that you understand the point of the delayed public disclosure. If it wasn't a threat, then there'd be no need to delay -- it would be publicly disclosed immediately.

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

#867

Post by insane_dreamer »

Dylan16807 wrote: post #832
insane_dreamer wrote: post #821

> it is unreasonable for a trillion-dollar corporation like Google, which heavily relies on FFmpeg in its products, to shift the workload of fixing vulnerabilities to unpaid volunteers. They believe Google should either provide patches with vulnerability reports or directly support the project’s maintenance. This is so basic it shouldn't even have to be said.

The first part is technically true but doesn't apply to this situation. "Shift the workload"? This isn't google's bug, and google doesn't need it fixed. It was never their workload, and has not been shifted. The last part is just wrong. Google does directly support the project's maintenance.

It wasn't paying the people who it was expecting to fix the bug.

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

#868

Post by saagarjha »

ahepp wrote: post #784
saagarjha wrote: post #450

Earlier quoted context omitted.

Project Zero is an offensive security team. Its job is to find vulnerabilities.

In their own words: > Our mission is to make the discovery and exploitation of security vulnerabilities more difficult, and to significantly improve the safety and security of the Internet for everyone. > We perform vulnerability research on popular software like mobile operating systems, web browsers, and open source libraries. We use the results from this research to patch serious security vulnerabilities, to impro…

Correct.

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

#869

Post by dzhiurgis »

Orygin wrote: post #694
dzhiurgis wrote: post #666

Earlier quoted context omitted.

So does a Siemens transformer, but it's era defining. Why there's such a weird toxic empathy around ffmpeg?

Why do you shit on it? This software is literally holding the near entirety of video transcoding *worldwide* on its shoulders.

Good on them, can they and their groupies a bit more chill when facing valid criticism.

If this wasn't google but lone developer by now he'd be doxxed, fired and receiving death threats. It's not first time ffmpeg strikes like this.

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

#870

Post by tpmoney »

naasking wrote: post #861
tpmoney wrote: post #860

Earlier quoted context omitted.

> Responsible disclosure policies for contributor-driven projects can differ from commercial projects. The can , but there's not an obvious reason why they should . If anything, public disclosure timelines for commercial closed source projects should be much much longer than for contributor-driven projects because once a bug is public ANYONE can fix it in the contributor-driven project, where as for a commercial proj…

> The can, but there's not an obvious reason why they should. Of course there are obvious reasons: corporations have the resources and incentives to fix them promptly once threatened with disclosure. Corporations don't respond well otherwise. None of these apply to volunteer projects. > They literally higher the ffmpeg maintainers via the maintainer's consulting business (fflabs.eu) and they routinely contribute code…

> None of these apply to volunteer projects.

How so? Volunteer projects have maintainers assigned to the project writing code. The "resources" to fix a bug promptly are simply choosing to allocate your developer resources to fixing the bug. Of course, volunteers might not want to do that, but then again, a company might not want to allocate their developers to fixing a bug either. But in either case the solution is to prioritize spending developer hours on the bug instead of on some other aspect of your project. In fact, volunteer driven projects have one huge resource that corporations don't, a theoretically infinite supply of developers to work on the project. Anyone with an interest can pick up the task of fixing the bug. That's the promise of open source right? Many eyes making all bugs shallow.

As for incentives, apparently both corporations and volunteer projects are "incentivized" to preserve their reputation. If volunteer projects weren't, we wouldn't be having this insane discussion where some people are claiming filing a bug report is tantamount to blackmail.

The only difference between the volunteer project and the corporation is even the head of a volunteer project can't literally force someone to work on an issue under the threat of being fired. I guess technically they could threaten to expel them from the project and I'm sure some bigger projects could also deny funding from their donation pool to a developer that refuses to play ball, but obviously that's not quite the same as being fired from your day job.

> Great, then they should loop in the people they're paying on any notification of a vulnerability.

If only there was some generally agreed upon and standardized way of looping the right people in on notifications of a bug. Some sort of "bug report" that you could give a team. It could include things like what issue you think you've found, places in the code that you believe are the cause of the issue, possibly suggested remediations, maybe even a minimum test case so that you can easily reproduce and validate the bug. Even better if there were some sort email address[1] that you could send these sorts of reports to if you didn't necessarily want to make them public right away. Or maybe there could be a big public database you could submit the reports to where anyone could see things that need work and could pick up the work[2] even if the maintainers themselves didn't. That would be swell, I'm sure some smart person will figure out a system like that one day.

[1]: https://ffmpeg.org/security.html [2]: https://ffmpeg.org/bugreports.html

Post reply on HN