3 ms·

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 contributi

by SR2Z 1y ago

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.

strictnein 1y ago
Personally, I want the $3.5 Trillion company to do more. So the line should be somewhere else.
- SR2Z 1y ago
  So you don't have a line, you just want to move the goalposts and keep moving them?
  - iscoelho 1y ago
    It is my understanding that the commenters in FFMPEG's favor believe that Google is doing a disservice by finding these security vulnerabilities, as they require volunteer burden to patch, and that they should either: 1) allow the vulnerabilities to remain undiscovered & unpatched zero-days (stop submitting "slop" CVEs.) 2) supply the patches (which i'm sure the goalpost will move to the maintainers being upset that they have to merge them.) 3) fund the project (including the maintainers who clearly misunderstand the severity of the vulnerabilities and describe them as "slop") (no thank you.) This entire thread defies logic.
    - strictnein 11mo ago
      No one is saying #1. No one is arguing against #2. #3 is something all companies with significant reliance on OSS projects should help do. The only thing that defies logic is how poorly your strawman is constructed.
      - iscoelho 11mo ago
        It appears we are not reading the same thread.
  - ruined 1y ago
    location of goalposts scales with market cap
  - strictnein 11mo ago
    Yep, that's clearly what I was saying. I want to just keep moving the goalposts (which I didn't even know I had set or moved in the first place) again and again. Or I just want the $3.5 trillion company to also provide the patches to OSS libraries/programs/etc that their projects with hundreds of millions or billions in funding happen to find. Crazy, I know.
angiolillo 1y ago
> Providing a real CVE is a contribution, not a burden. Isn't a real CVE (like any bug report) both a contribution and a burden?
- SR2Z 1y ago
  Only if you subscribe to the "if we stop testing, the number of cases will drop!" philosophy.
- arcfour 1y ago
  It's not fair to classify it as a burden; it existed anyways, but now you have the work/issue identified.
ahepp 1y ago
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.
- saubeidl 1y ago
  To build on that - if it "doesn't scale" for one of the wealthiest companies in the world, it certainly doesn't scale for a volunteer project...
- f33d5173 1y ago
  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.
  - ndriscoll 1y ago
    The ffmpeg authors aren't "shipping" anything; they're giving away something they make as a hobby with an explicit disclaimer of any kind of fitness for purpose. If someone needs something else, they can pay an engineer to make it for them.
    - f33d5173 1y ago
      This has nothing to do with payment. Not deliberately infecting your users with vulnerabilities is simply the right thing to do. Giving something away for free doesn't absolve you of certain basic ethical responsibilities.
      - 1y ago
lenerdenator 1y ago
> Providing a real CVE is a contribution, not a burden. The ffmpeg folks can ignore it, since by all indications it's pretty minor. Re-read the article. There's CVEs and then there's CVEs. This is the former, and they're shoving tons of those down the throats of unpaid volunteers while contributing nothing back. What Google's effectively doing is like a food safety inspection company going to the local food bank to get the food that they operate their corporate cafeteria on just to save a buck, then calling the health department on a monthly basis to report any and all health violations they think they might have seen, while contributing nothing of help back to the food bank.
- SR2Z 1y ago
  I have read the article. The expectation for a tool like ffmpeg is that regardless of what kind of file you put into it, it safely handles it. This is an actual bug in submitted code. It doesn't matter that it's for some obscure codec, it's technically maintained by the ffmpeg project and is fair game for vulnerability reports. Given that Google is also a major contributor to open-source video, this is more like a food manufacturer making sure that grocery stores are following health code when they stock their food. Mind you, the grocery store has no obligation to listen to them in this metaphor and is free to just let the report/CVE sit for a while.
- iscoelho 1y ago
  I am unsure why this untruth is being continuously parroted. It is false. This is exploitable on a majority of systems as the codec is enabled by default. This is a CVE that is being severely underestimated.

by SR2Z 1y ago

strictnein 1y ago

Personally, I want the $3.5 Trillion company to do more. So the line should be somewhere else.

SR2Z 1y ago
So you don't have a line, you just want to move the goalposts and keep moving them?
- iscoelho 1y ago
  It is my understanding that the commenters in FFMPEG's favor believe that Google is doing a disservice by finding these security vulnerabilities, as they require volunteer burden to patch, and that they should either: 1) allow the vulnerabilities to remain undiscovered & unpatched zero-days (stop submitting "slop" CVEs.) 2) supply the patches (which i'm sure the goalpost will move to the maintainers being upset that they have to merge them.) 3) fund the project (including the maintainers who clearly misunderstand the severity of the vulnerabilities and describe them as "slop") (no thank you.) This entire thread defies logic.
  - strictnein 11mo ago
    No one is saying #1. No one is arguing against #2. #3 is something all companies with significant reliance on OSS projects should help do. The only thing that defies logic is how poorly your strawman is constructed.
    - iscoelho 11mo ago
      It appears we are not reading the same thread.
- ruined 1y ago
  location of goalposts scales with market cap
- strictnein 11mo ago
  Yep, that's clearly what I was saying. I want to just keep moving the goalposts (which I didn't even know I had set or moved in the first place) again and again. Or I just want the $3.5 trillion company to also provide the patches to OSS libraries/programs/etc that their projects with hundreds of millions or billions in funding happen to find. Crazy, I know.

angiolillo 1y ago

> Providing a real CVE is a contribution, not a burden. Isn't a real CVE (like any bug report) both a contribution and a burden?

SR2Z 1y ago
Only if you subscribe to the "if we stop testing, the number of cases will drop!" philosophy.
arcfour 1y ago
It's not fair to classify it as a burden; it existed anyways, but now you have the work/issue identified.

ahepp 1y ago

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.

saubeidl 1y ago
To build on that - if it "doesn't scale" for one of the wealthiest companies in the world, it certainly doesn't scale for a volunteer project...
f33d5173 1y ago
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.
- ndriscoll 1y ago
  The ffmpeg authors aren't "shipping" anything; they're giving away something they make as a hobby with an explicit disclaimer of any kind of fitness for purpose. If someone needs something else, they can pay an engineer to make it for them.
  - f33d5173 1y ago
    This has nothing to do with payment. Not deliberately infecting your users with vulnerabilities is simply the right thing to do. Giving something away for free doesn't absolve you of certain basic ethical responsibilities.
    - 1y ago

lenerdenator 1y ago

> Providing a real CVE is a contribution, not a burden. The ffmpeg folks can ignore it, since by all indications it's pretty minor. Re-read the article. There's CVEs and then there's CVEs. This is the former, and they're shoving tons of those down the throats of unpaid volunteers while contributing nothing back. What Google's effectively doing is like a food safety inspection company going to the local food bank to get the food that they operate their corporate cafeteria on just to save a buck, then calling the health department on a monthly basis to report any and all health violations they think they might have seen, while contributing nothing of help back to the food bank.

SR2Z 1y ago
I have read the article. The expectation for a tool like ffmpeg is that regardless of what kind of file you put into it, it safely handles it. This is an actual bug in submitted code. It doesn't matter that it's for some obscure codec, it's technically maintained by the ffmpeg project and is fair game for vulnerability reports. Given that Google is also a major contributor to open-source video, this is more like a food manufacturer making sure that grocery stores are following health code when they stock their food. Mind you, the grocery store has no obligation to listen to them in this metaphor and is free to just let the report/CVE sit for a while.
iscoelho 1y ago
I am unsure why this untruth is being continuously parroted. It is false. This is exploitable on a majority of systems as the codec is enabled by default. This is a CVE that is being severely underestimated.