When you already work 40+ hours a week and big companies suddenly start an AI snowblower that shoots a dozen extra hours of work every week at you without doing anything to balance that (like, for instance, also opening PRs with patches that fix the bugs), the relationship starts feeling like being an unpaid employee of their project.

What's the point of just showering these things with bug reports when the same tool (or a similar one) can also apparently fix the problem too?

The problem with security reports in general is security people are rampant self-promoters. (Linus once called them something worse.)

Imagine you're a humble volunteer OSS developer. If a security researcher finds a bug in your code they're going to make up a cute name for it, start a website with a logo, Google is going to give them a million dollar bounty, they're going to go to Defcon and get a prize and I assume go to some kind of secret security people orgy where everyone is dressed like they're in The Matrix.

Nobody is going to do any of this for you when you fix it.

Except that the only people publicizing this bug were the people running the ffmpeg Twitter account. Without them it would have been one of thousands of vulnerabilities reported with no fanfare, no logos, and no conference talks.

Doesn't really fit with your narrative of security researchers as shameless glory hounds, does it?

How do they know that next week it's not going to be one of those 10 page Project Zero blog posts? (Which like all Google engineer blog posts, usually end up mostly being about how smart the person who wrote the blog post is.)

Note FFmpeg and cURL have already had maintainers quit from burnout from too much attention from security researchers.

If Google wanted nothing more than to simply make blog posts, why wouldn't they just only report the big bugs that they can make blog posts out of (and avoid having to spend any resources on finding the rest) ?

I don't know if you'd be satisfied with that, but certainly this would allow them to easily make the blog posts you seem to be complaining about, all while making the load on maintainers rather minimal, at least insofar as blog posts appear to be quite infrequent compared to the total amount of vulnerabilities they report - around 20 vulnerability reports per year certainly seems like a manageable load for the entire FOSS community to bear, especially given almost none of these 20 yearly vulnerability reports would go to ffmpeg (if not literally none, given the Project Zero blog has 0 search results for "ffmpeg" or "libav"), and a significant portion of their blog posts aren't even about FOSS at all but instead about proprietary software like the operating systems Microsoft and Apple make.

I do think such a thing would be bad for everyone, though (including the ffmpeg developers themselves, to be honest) - Project Zero is good for everyone's security, in my opinion, and even if all FOSS developers were to universally decide to reject all Project Zero reports that don't come with a patch, and Google decided to still not make such patches, people being able to know that these vulnerabilities exist is still a good thing nonetheless - certainly much better than more vulnerabilities being left in for malicious actors to discover and use in zero-day attacks.

CVEs aren't caused by bugs?

They are not published in project bug trackers and are managed completely differently so no, personally, I don't view CVE as bug reports. Also, please, don't distrort what I say and omit part of my comment, thank you.

Some of them are not even bugs in the traditional sense of the world but expected behaviours which can lead to unsecure side effects.

It seems like you might misunderstand what CVEs are? They're just identifiers.

This was a bug, which caused an exploitable security vulnerability. The bug was reported to ffmpeg, over their preferred method for being notified about vulnerabilities in the software they maintain. Once ffmpeg fixed the bug, a CVE number was issued for the purpose of tracking (e.g. which versions are vulnerable, which were never vulnerable, which have a fix).

Having a CVE identifier is important because we can't just talk about "the ffmpeg vulnerability" when there have been a dozen this year, each with different attack surfaces. But it really is just an arbitrary number, while the bug is the actual problem.

I'm not misunderstanding anything. CVE involves a third party and it's not just a number. It's a number and an evaluation of severity.

Things which are usually managed inside a project now have a visibility outside of it. You might justify it as you want like the need to have an identifier. It doesn't fundamentally change how that impacts the dynamic.

Also, the discussion is not about a specific bug. It's a general discussion regarding how Google handles disclosure in the general case.

You could argue that, but I think that a bug is the software failing to do what it was specified, or what it promised to do. If security wasn't promised, it's not a bug.

Which is exactly the case here. This CVE is for a hobby codec written to support digital preservation of a some obscure video files from the 90’s that are used nowhere else. No security was promised.

Not always, there have been a plenty of CVEs issued for completely absurd reasons.

> The lowered lead times are because devs have an entitled additude that others fix their code when they discover bugs in it.

That’s how open source works.

It is super strange to say that who devoted their time and effort and then gives away their work for free is somehow entitled.

If this keeps up, there won't be anyone willing to maintain the software due to burn out.

In today's situation, free software is keeping many companies honest. Losing that kind of leverage would be a loss to the society overall.

And the public disclosure is going to hurt the users which could include defense, banks and other critical institutions.

Do you have evidence of ai slop, or are you just spreading fud? The linked bug was acknowledged as real.

That is completely irrelevant, the gross part is that (if true) they are demanding them to be fixed in a given time. Sounds like the epitome of entitlement to me, to say the least.

No one is demanding anything, the report itself is a 90 day grace period before being publicly published. If the issues are slop then what exactly is your complaint?

google literally tells them it's an ai generated report

That is not the definition of slop.

if it's unwanted then it is

and the ffmpeg maintainers say it's not wanted

so it's slop

It’s a reproducible use-after-free in a codec that ships by default with most desktop and server distributions. It can be leveraged in an exploit chain to compromise a system.

I'm not a Google fan, but if the maintainers are unable to understand that, I welcome a fork.