Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

541–550 of 913 posts

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

#541
post #267

Earlier quoted context omitted.

When you publicize a vulnerability you know someone doesn't have the capacity to fix according to the requested timeline, you are simultaneously increasing the visibility of the vulnerability and name-calling the maintainers. All of this increases the pressure on the maintainers, and it's fair to call that a "demand" (quotes-included). Note that we are talking about humans who will only have their motivation dwindle:…

> When you publicize a vulnerability you know someone doesn't have the capacity to fix according to the requested timeline My understanding is that the bug in question was fixed about 100 times faster than Project Zero's standard disclosure timeline. I don't know what vulnerability report your scenario is referring to, but it certainly is not this one. > and name-calling the maintainers Except Google did not "name-ca…

"When you publicize... you are ... name-calling": you are taking partial quotes out of context, where I claimed that publicizing is effectively doing something else.

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

#542
post #182

Earlier quoted context omitted.

If they want that level of control, reimburse for all the prior development too. - ie: buy that business. As it stands, they're just abusing someone's gift. Like jerks.

I always like to point out that "Open Source" was a deliberate watering-down of the moralizing messaging of Free Software to try and sell businesses on the benefits of developing software in the open. > We realized it was time to dump the confrontational attitude that has been associated with "free software" in the past and sell the idea strictly on the same pragmatic, business-case grounds that motivated Netscape. h…

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 licenses don't support that well in the 21st c. This is why we get articles like this every month about deep-pocketed corporate free riders.

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

#543

Earlier quoted context omitted.

When you publicize a vulnerability you know someone doesn't have the capacity to fix according to the requested timeline, you are simultaneously increasing the visibility of the vulnerability and name-calling the maintainers. All of this increases the pressure on the maintainers, and it's fair to call that a "demand" (quotes-included). Note that we are talking about humans who will only have their motivation dwindle:…

> When you publicize a vulnerability you know someone doesn't have the capacity to fix according to the requested timeline, you are simultaneously increasing the visibility of the vulnerability and name-calling the maintainers. So how long should all bug reporters wait before filing public bugs against open source projects? What about closed source projects? Anyone who works in software knows to ship software is to a…

It's funny you come up with that suggestion when I clearly offer a different solution: "make your internal teams do the right thing by both reporting, but also helping fix the issue with hands-on work".

It's a call not to stop reporting, but to equally invest in fixing these.

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

#544

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.

But that's only relevant if AWS (in this example) violates the GPL license, and it doesn't really seem like they have?

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

#545
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…

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.

Can't you just give the information you are hinting at? Other people than OP read this. You basically tell me to go read thousands of messages on a mailing list just solve your rhetorical question. (answer: Intel, Redhat, Meta, Google, Suse, Arm and Oracle. There are much more efficient ways to find this.) Yes, they are the main kernel contributors and have been for many years. I'm still not sure I understand the comment.

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

#546

Earlier quoted context omitted.

As clearly stated, most users of ffmpeg are unaware of them using it. Even them knowing about a vulnerability in ffmpeg, they wouldn't know they are affected. Really, the burden is on those shipping products that depend on ffmpeg: they are the ones who have to fix the security issues for their customers. If Google is one of those companies, they should provide the fix in the given time.

But how are those companies supposed to know they need to do anything unless someone finds and publicly reports the issue in the first place? Surely we're not advocating for a world where every vendor downstream of the ffmpeg project independently discovers and patches security vulnerabilities without ever reporting the issues upstream right?

If they both funded vulnerability scanning and vulnerability fixing (if they don't want to do it in-house, they can sponsor the upstream team), which is to me the obvious "how", I am not sure why you believe there is only one way to do it.

It's about accountability! Who really gets to do it once those who ship it to customers care, is on them to figure out (though note that maintainers will have some burden to review, integrate and maintain the change anyway).

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

#547

Earlier quoted context omitted.

If google bears no role in fixing the issues it finds and nobody else is being paid to do it either, it functionally is just providing free security vulnerability research for malicious actors because almost nobody can take over or switch off of ffmpeg.

This is a weird argument. Basically condoning security through obscurity: If nobody reports the bug then we just pretend it doesn’t exist, right? There are many groups searching for security vulnerabilities in popular open source software who deliberately do not disclose them. They do this to save them for their own use or even to sell them to bad actors. It’s starting to feel silly to demonize Google for doing secur…

> It’s starting to feel silly to demonize Google for doing security research at this point.

Aren't most people here demonizing Google for dedicating the resources to find bugs, but not to fix them?

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

#548
post #266

Earlier quoted context omitted.

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.

It did that but it did not decide to form a team dedicated to fixing issues in software that it uses? That's the misallocation of funds that's at play here.

The ideal outcome is that Project Zero sends its discoveries off to a team who triage and develop patches for the significant vulnerabilities, and then the communication with the project is a much more helpful one.

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

#549

Earlier quoted context omitted.

But FFmpeg does not have the resources to fix these at the speed Google is finding them. It's just not possible. So Google is dedicating resources to finding these bugs and feeding them to bad actors. Bad actors who might, hypothetically have had the information before, but definitely do once Google publicizes them. You are talking about an ideal situation; we are talking about a real situation that is happening in t…

A solution definitely ought to be found. Google putting up a few millionths of a percent of their revenue or so towards fixing the bugs they find in ffmpeg would be the ideal solution here, certainly. Yet it seems unlikely to actually occur. I think the far more likely result of all the complaints is that Google simply completely disengages from ffmpeg and stops doing any security work on it. I think that would be qu…

I really don’t understand whole discourse us vs them? Why it is should be only Google fixing the bugs. Isn’t if volunteers not enough, so maybe more volunteers can step up and help FFMpeg. Via direct patches, or via directly lobbying companies to fund project.

In my opinion if the problem is money, and they cannot raise enough, then somebody should help them with that. Isn’t it?

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

#550

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.

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 argument that lots of people on HN will accept, but many outside this context will not understand it or care.

Post reply on HN