←back to thread

1125 points CrankyBear | 4 comments | | HN request time: 0s | source
Show context
pjmlp ◴[] No.45891849[source]
Fully on FFmpeg team side, many companies approach to FOSS is only doing so when it sounds good on their marketing karma, leech otherwise.

Most of them would just pirate in the old days, and most FOSS licences give them clear conscience to behave as always.

replies(2): >>45892276 #>>45892516 #
iscoelho ◴[] No.45892516[source]
Google is, at no cost to FFMPEG:

1) dedicating compute resources to continuously fuzzing the entire project

2) dedicating engineering resources to validating the results and creating accurate and well-informed bug reports (in this case, a seriously underestimated security issue)

3) additionally for codecs that Google likely does not even internally use or compile, purely for the greater good of FFMPEG's user base

Needless to say, while I agree Google has a penny to spare to fund FFMPEG, and should (although they already contribute), I do not agree with funding this maintainer.

replies(3): >>45892589 #>>45892848 #>>45895277 #
pjmlp ◴[] No.45892589[source]
Then they can surely also provide a pull request for said CVE.
replies(2): >>45892622 #>>45893197 #
SR2Z ◴[] No.45892622[source]
Where do you draw the line? Do you want Google to just not inspect any projects that it can't fully commit to maintaining?

Providing a real CVE is a contribution, not a burden. The ffmpeg folks can ignore it, since by all indications it's pretty minor.

replies(4): >>45892822 #>>45892859 #>>45893344 #>>45893509 #
ahepp ◴[] No.45893344{3}[source]
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.

Maybe part of the solution is creating a separate low priority queue for bug reports from groups that could fix it but chose not to.

replies(4): >>45893580 #>>45893694 #>>45895896 #>>45895942 #
f33d5173 ◴[] No.45893694{4}[source]
If you are deliberately shipping insecure software, you should stop doing that. In ffmpeg's case, that means either patching the bug, or disabling the codec. They refused to do the latter because they were proud of being able to support an obscure codec. That puts the onus on them to fix the bug in it.
replies(3): >>45894826 #>>45894948 #>>45895125 #
ahepp ◴[] No.45894948[source]
I can tell you with 100% certainty that there are undiscovered vulnerabilities in the Linux kernel right now. Does that mean they should stop shipping?

I do think that contributing fuzzing and quality bug reports can be beneficial to a project, but it's just human nature that when someone says "you go ahead and do the work, I'll stand here and criticize", people get angry.

Rather than going off and digging up ten time bombs which all start counting down together, how about digging up one and defusing it? Or even just contributing a bit of funding towards the team of people working for free to defuse them?

If Google really wants to improve the software quality of the open source ecosystem, the best thing they could do is solve the funding problem. Not a lot of people set out to intentionally write insecure code. The only case that immediately comes to mind is the xz backdoor attempt, which again had a root cause of too few maintainers. I think figuring out a way to get constructive resources to these projects would be a much more impressive way to contribute.

This is a company that takes a lot of pride in being the absolute best of the best. Maybe what they're doing can be justified in some way, but I see why maintainers are feeling bullied. Is Google really being excellent here?

replies(2): >>45895907 #>>45896727 #
saagarjha ◴[] No.45895907[source]
You will note the Linux kernel is not crying on Twitter when Google submits bugs to them. They did long ago, then realized that the bugs that Google reported often showed up exploited in the wild when they didn’t fix them, and mostly decided that the continuous fuzzing was actually a good thing. This is despite not all the bugs being fixed on time (there are always new OSSFuzz bugs in the queue for fixing).
replies(1): >>45897335 #
1. pjmlp ◴[] No.45897335[source]
The Linux kernel instead decided to become a CVE authority, so that they have control over what is officially reported as a CVE.
replies(1): >>45897886 #
2. fulafel ◴[] No.45897886[source]
There are other CVE numbering authorities you can report a vulnerability to and apply for a CVE, or appeal, but this does possibly have a chilling effect if the vendor's CNA refuses valid vulns. (Like with MS in https://news.ycombinator.com/item?id=44957454 )

There's an appeals process: https://www.cve.org/Resources/General/Policies/CVE-Record-Di...

And of course CVE is not the only numbering system, there's OSV DB, GHSA, notcve.org etc.

replies(1): >>45900158 #
3. jorams ◴[] No.45900158[source]
> this does possibly have a chilling effect if the vendor's CNA refuses valid vulns

The Linux kernel went in the opposite direction: Every bugfix that looks like it could be relevant to security gets a CVE[1]. The number of CVEs has increased significantly since it became a CNA.

[1]: https://lwn.net/Articles/978711/

replies(1): >>45900496 #
4. fulafel ◴[] No.45900496{3}[source]
Thanks. They seem to be pretty proactive indeed if you look at the feed: https://lore.kernel.org/linux-cve-announce/