←back to thread

1124 points CrankyBear | 1 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[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 #
fulafel ◴[] No.45895942[source]
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.

replies(1): >>45896845 #
degamad ◴[] No.45896845[source]
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.

replies(1): >>45899770 #
1. UncleMeat ◴[] No.45899770{3}[source]
The security and privacy org is much large than just GPZ, but the security and privacy org does not have a general remit to fix all vulns everywhere. GPZ is also not the only part of the org that finds bugs in open source software but is not generally obligated to fix them. Projects like ossfuzz are similar.

Google could staff a team that is responsible for remediating vulns in open source software that doesn't actually affect any of Google's products. Lord knows they've got enough money. I'd prefer it if they did that. But I don't really see the reasoning behind why they must do this or scrap all vuln research on open source software.