6 ms·

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. Th

by f33d5173 11mo 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 11mo 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 11mo 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.
  - ndriscoll 11mo ago
    They're not deliberately infecting users with anything. There effectively saying "here's example code showing how to deal with these video formats. NOTE THAT THESE ARE EXAMPLES THAT I WROTE FOR FUN. THEY ARE NOT MEANT FOR SERIOUS USE AND MAY NOT HANDLE ALL CORNER CASES SAFELY. THIS SHOULD BE OBVIOUS SINCE WE HAVE NO COMMERCIAL RELATIONSHIP AND YOU'RE DOWNLOADING RANDOM CODE FROM SOMEONE YOU DON'T KNOW ON THE INTERNET". If someone goes on to use that code for serious purposes, that's on them. They were explicitly warned that this is not production commercial code. It's weekend hobby work. There's no ethical obligation to make your hobby code suitable for production use before you share it. People are allowed to write and share programs for fun. Deliberate malware would be something like an inbuilt trojan that exfiltrates data (e.g. many commercial applications). Completely different.
    - f33d5173 11mo ago
      The idea that things can be right and wrong seems to be lost on you.
    - Dylan16807 11mo ago
      They are not effectively saying that. The way they talk about the library everywhere else makes it clear that they do expect serious use. Disclaimers in the license don't override that, especially when 99% of software has a disclaimer like that. Those words are there for legal reasons only. If they wanted to market ffmpeg as a toy project only, not to be trusted, they could do that, but they are not doing that.
      - ndriscoll 11mo ago
        Except the very idea that they owe you anything is so absurd that even if they had a contract document stating that they'd do work for you, they still wouldn't have an obligation to do so because society has decided that contracts without some consideration from both sides are not valid. Similarly, even if something you buy comes with a piece of paper saying they don't owe you anything if it breaks, the law generally says that's not true. Because you paid for it. But they don't say they warrant their work. They have a notice reminding you that you are receiving something for free, and that thing comes with no support, and is not meant to be fit for any particular use you might be thinking of, and that if you want support/help fulfilling some purpose, you can pay someone (maybe even them if you'd like) for that service. Because the way the world works is that as a general principle, other people don't owe you something for nothing. This is not just some legal mumbo jumbo. This is how life works for everyone. It's clear that they're not being malicious (they're not distributing a virus or something), and that's the most you can expect from them. Computer security is always contextual, but as a general rule, if you're going to be accepting random input from unknown parties, you should have an expert that knows how to do that safely. And as mentioned elsewhere in these comments, such an expert would already be compiling out codecs they don't need and running the processing in a sandboxed environment to mitigate any issues. These days even software written in-house is run in sandboxed environments with minimal permissions when competent professionals are making things. That's just standard practice. So they should be proud that they support obscure codecs, and by default the onus is on no one to ensure it's free from bugs. If an engineer needs to make a processing pipeline, the onus is always on them to do that correctly. If they want to use a free, unsupported hobby tool as part of their serious engineering project, it's on them to know how to manage any risks involved with that decision. Making good decisions here is literally their job.
ahepp 11mo ago
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?
- saagarjha 11mo ago
  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).
  - pjmlp 11mo ago
    The Linux kernel instead decided to become a CVE authority, so that they have control over what is officially reported as a CVE.
    - fulafel 11mo ago
      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 https://news.ycombinator.com/item?id=44957454 ) There's an appeals process: https://www.cve.org/Resources/General/Policies/CVE-Record-Dispute-Policy.pdf 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.
javier2 11mo ago
Nah, ffmpeg volunteers dont owe you or Google anything. They are giving you free access to their open project.

ndriscoll 11mo 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 11mo 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.
- ndriscoll 11mo ago
  They're not deliberately infecting users with anything. There effectively saying "here's example code showing how to deal with these video formats. NOTE THAT THESE ARE EXAMPLES THAT I WROTE FOR FUN. THEY ARE NOT MEANT FOR SERIOUS USE AND MAY NOT HANDLE ALL CORNER CASES SAFELY. THIS SHOULD BE OBVIOUS SINCE WE HAVE NO COMMERCIAL RELATIONSHIP AND YOU'RE DOWNLOADING RANDOM CODE FROM SOMEONE YOU DON'T KNOW ON THE INTERNET". If someone goes on to use that code for serious purposes, that's on them. They were explicitly warned that this is not production commercial code. It's weekend hobby work. There's no ethical obligation to make your hobby code suitable for production use before you share it. People are allowed to write and share programs for fun. Deliberate malware would be something like an inbuilt trojan that exfiltrates data (e.g. many commercial applications). Completely different.
  - f33d5173 11mo ago
    The idea that things can be right and wrong seems to be lost on you.
  - Dylan16807 11mo ago
    They are not effectively saying that. The way they talk about the library everywhere else makes it clear that they do expect serious use. Disclaimers in the license don't override that, especially when 99% of software has a disclaimer like that. Those words are there for legal reasons only. If they wanted to market ffmpeg as a toy project only, not to be trusted, they could do that, but they are not doing that.
    - ndriscoll 11mo ago
      Except the very idea that they owe you anything is so absurd that even if they had a contract document stating that they'd do work for you, they still wouldn't have an obligation to do so because society has decided that contracts without some consideration from both sides are not valid. Similarly, even if something you buy comes with a piece of paper saying they don't owe you anything if it breaks, the law generally says that's not true. Because you paid for it. But they don't say they warrant their work. They have a notice reminding you that you are receiving something for free, and that thing comes with no support, and is not meant to be fit for any particular use you might be thinking of, and that if you want support/help fulfilling some purpose, you can pay someone (maybe even them if you'd like) for that service. Because the way the world works is that as a general principle, other people don't owe you something for nothing. This is not just some legal mumbo jumbo. This is how life works for everyone. It's clear that they're not being malicious (they're not distributing a virus or something), and that's the most you can expect from them. Computer security is always contextual, but as a general rule, if you're going to be accepting random input from unknown parties, you should have an expert that knows how to do that safely. And as mentioned elsewhere in these comments, such an expert would already be compiling out codecs they don't need and running the processing in a sandboxed environment to mitigate any issues. These days even software written in-house is run in sandboxed environments with minimal permissions when competent professionals are making things. That's just standard practice. So they should be proud that they support obscure codecs, and by default the onus is on no one to ensure it's free from bugs. If an engineer needs to make a processing pipeline, the onus is always on them to do that correctly. If they want to use a free, unsupported hobby tool as part of their serious engineering project, it's on them to know how to manage any risks involved with that decision. Making good decisions here is literally their job.

ahepp 11mo ago

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?

saagarjha 11mo ago
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).
- pjmlp 11mo ago
  The Linux kernel instead decided to become a CVE authority, so that they have control over what is officially reported as a CVE.
  - fulafel 11mo ago
    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 https://news.ycombinator.com/item?id=44957454 ) There's an appeals process: https://www.cve.org/Resources/General/Policies/CVE-Record-Dispute-Policy.pdf 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.

javier2 11mo ago

Nah, ffmpeg volunteers dont owe you or Google anything. They are giving you free access to their open project.