←back to thread

1125 points CrankyBear | 2 comments | | HN request time: 0.418s | source
Show context
HackerThemAll ◴[] No.45892250[source]
FFmpeg should stop fixing security bugs reported by Google, MS, Amazon, Meta etc. and instead wait for security patches from them. If FFmpeg maintainers will leave it exposed, those companies will rush to fixing it, because they'd be screwed otherwise. Every single one of them is dependent on FFmpeg exactly as shown in https://xkcd.com/2347/
replies(1): >>45892753 #
shevy-java ◴[] No.45892753[source]
I understand the problem of corporations leeching off of the community here.

I still fail to see why "ffmpeg is not allowed to fix bugs reported by corporations" is a good strategy. To me this sounds not logical.

replies(1): >>45893404 #
lenerdenator ◴[] No.45893404[source]
Because they are making more money in profit than some mid-sized American cities' economies do in a year while contributing nothing back. If they don't want massive security vulnerabilities in their services using FFmpeg, maybe they need to pony up about .1 seconds' worth of their quarterly earnings to the project either in cash or in manpower.

It's not FFmpeg's problem if someone uses a vulnerability to pwn YouTube, it's Google's problem.

Also, in the article, they mention that Google's using AI to look for bugs and report them, and one of them that it found was a problem in the code that handles the rendering of a few frames of a game from 1995. That sort of slop isn't helping anyone. It's throwing the signal-to-noise ratio of the bug filings way the hell off.

replies(1): >>45895980 #
tpmoney ◴[] No.45895980[source]
If they contribute nothing back, what are all the `google.com` email addresses in the git history doing? If they contribute nothing back, why are they listed as a customer of `fflabs.eu` which is apparently a private consulting company for ffmpeg run by some of the ffmpeg lead maintainers?

What do we think the lesson corporations are going to take from this is?

1) "You should file patches with your bug reports"

2) "Even when you submit patches and you hire the developers of OSS projects as consultants, you will still get dragged through the mud if you don't contribute a patch with every bug report you make, so you might as well not contribute anything back at all"

replies(1): >>45902491 #
1. kastagg ◴[] No.45902491[source]
The text and context of the complaint can be used to steelman it, adopting the principle of charity.

From that perspective, the most likely problem is not that bugs are being reported, nor even that patches are not being included with bug reports. The problem is that a shift from human-initiated bug reports to large-scale LLM generation of bug reports by large corporate entities generates a lot more work and changes the value proposition of bug reports for maintainers.

Even if you use LLMs to generate bug reports, you should have a human vet and repro them as real and significant and ensure they are written up for humans accurately and concisely, including all information that would be pertinent to a human. A human can make fairly educated decisions on how to combine and prioritize bug reports, including some degree of triage based on the overall volume of submissions relative to their value. A human can be "trained" to conform to whatever the internal policies or requirements are for reports.

Go ahead and pay someone to do it. If you don't want to pay, then why are you dumping that work on others?

Even after this, managing the new backlog entries and indeed dealing with a significantly larger archive of old bug reports going forward is a significant drag on human labor - bug reports themselves entail labor. Again, the old value proposition was that this was outweighed by the value of the highest-value human-made reports and intangibles of human involvement.

Bug reports are, either implicitly or explicitly, requests to do work. Patches may be part of a solution, but are not necessary. A large corporate entity which is operationally dependent on an open source project and uses automation to file unusually large volumes of bug reports is not filing them to be ignored. It isn't unreasonable to ask them to pay for that work which they are, one way or another, asking to have done.

replies(1): >>45907861 #
2. tpmoney ◴[] No.45907861[source]
> Even if you use LLMs to generate bug reports, you should have a human vet and repro them as real and significant and ensure they are written up for humans accurately and concisely, including all information that would be pertinent to a human.

Look at the report that's the center of this controversy. It's detailed, has a clear explanation of the issue at hand, has references and links to the relevant code locations where the submitter believes the issue is and has a minimal reproduction of the issue to both validate the issue and the fix. We can assume the issue is indeed valid and significant as ffmpeg patched it before the 90 day disclosure window. There is certainly nothing about it that screams low effort machine generated report without human review, and at least one commenter in this discussion claims to have inside knowledge that all these reports are written by verified and written by humans before submission to the projects.

I won't pretend that it's a perfect bug report, but I will say if every bug report I got for the rest of my career was of this caliber, I'd be a quite happy with that.

> It isn't unreasonable to ask them to pay for that work which they are, one way or another, asking to have done.

Google quite literally hires some of the ffmpeg maintainers as consultants as attested to by those same maintainer's own website (fflabs.eu). They are very plainly putting cold hard cash directly into the funds of the maintainers for the express purpose of them maintaining and developing ffmpeg. And that's on top of the code their own employees submit with some regularity. As near as I can tell, Google does everything people complaining about this are saying they don't do, and it's still not enough. One has to wonder then what would be enough?