They could, but there is really no requirement on them to do so. The security flaw was discovered by Google, but it was not created by them.
Equally there is no requirement on ffmpeg to fix these CVEs nor any other.
And, of course, there is no requirement on end-users to run software from projects which do not consider untrusted-input-validation bugs to be high priority.
> They could, but there is really no requirement on them to do so.
I see this sort of sentiment daily. The sentiment that only what is strictly legal or required is what matters.
Sometimes, you know, you have to recognise that there are social norms and being a good person matters and has intrinsic value. A society only governed by what the written law of the land explicitly states is a dystopia worse than hell.
What's "strictly legal or required" of Google here is absolutely nothing. They didn't have to do any auditing or bug hunting. They certainly didn't have to validate or create a proper bug report, and there's no requirement whatsoever that they tell anyone about it at all. They could have found the bug, found it was being actively exploited, made their own internal patch and sat quietly by while other people remained vulnerable. All of that is well within what is "strictly legal or required".
Google did more than what is "strictly legal or required", and what they did was submit a good and valid bug report. But for some reason we're mad because they didn't do even more. Why? The world is objectively a better place for having this bug report, at least now people know there's something to address.
Google did more than what is "strictly legal or required", and what they did was submit a good and valid bug report. But for some reason we're mad because they didn't do even more. Why?
"I noticed your window was broken, so I took the liberty of helping you, working for free, by posting a sign that says UNLOCKED WINDOW HERE with exact details on how it was broken. I did lots of gratis work for you which you do not need to do yourself now. The world is safer now. Why are you not grateful?"
I mean if we’re going to do sloppy analogies, a bug report for open source software as widely used as ffmpeg is more like “I noticed the trees in the back corner of your free apple orchard are producing apples with trace amounts of heavy metals. I did some literal digging and sent some soil off to the labs and it looks like your back corner field may be contaminated. Here’s a heads up about that, and also just FYI in 90 days, if you haven’t been able to get your soil remediated, I’m going to put up a sign so that people can know to avoid those apples and not get poisoned by your free orchard while it’s getting fixed.”
Yes, this is a good illustration why The Copenhagen Interpretation of Ethics makes sense when Ffmpeg is allowed to criticise the manner of actions of Google.
I think it’s a good example of why it makes no sense. People are saying they would rather a world where people unknowingly get heavy metal poisoning from apples at the free orchard rather than a world where people are informed that some of the apples in one part of the orchard may have heavy metals in it because the person letting people know about it didn’t also remediate the soil, even though they don’t own the orchard.
That is plainly ridiculous. An orchard without heavy metals is obviously an ideal world in this case, but a world where people are at least informed of the places where the heavy metals are is orders of magnitude better than one where they’re unknowing getting heavy metal poisoning.
You're correct, but it's the social norms -- or at least, the norms as I perceive them -- that I am talking about here.
If you find yourself with potentially serious security bugs in your repo, then the social norm should be for you to take ownership of that because, well, it's your repo.
The socially unacceptable activity here should be treating security issues as an irritation, or a problem outside your control. If you're a maintainer, and you find yourself overwhelmed by genuine CVE reports, then it might be worth reflecting on the root cause of that. What ffmpeg did here was to shoot the messenger, which is non-normative.
It seems to me that they are not treating the security issue as an irritation, but instead the manner at which it was presented to them that is the problem.
> And, of course, there is no requirement on end-users to run software from projects which do not consider untrusted-input-validation bugs to be high priority.
What's this even saying?
Then they're free to fork it and never use the upstream again.
Equally there is no requirement on ffmpeg to fix these CVEs nor any other.
And, of course, there is no requirement on end-users to run software from projects which do not consider untrusted-input-validation bugs to be high priority.