Earlier quoted context omitted.
I've been a proponent of upstreaming fixes for open source software. Why? - It makes continued downstream consumption easier, you don't have to rely on fragile secret patches. - It gives back to projects that helped you to begin with, it's a simple form of paying it forward. - It all around seems like the "ethical" and "correct" thing to do. Unfortunately, in my experience, there's often a lot of barriers within comp…
As yet, Valve is the only company I know of doing this, and it's paying off in dividends both for Linux and for Valve. In just 5ish years of Valve investing people and money into Linux- specifically mesa and WINE, Linux has gone from a product that is kind of shaky with Windows, to "I can throw a windows program or game at it and it usually works". Imagine how further the OSS ecosystem would be if Open Source hadn't…
FFmpeg to Google: Fund us or stop sending bugs
401–410 of 913 posts
Re: FFmpeg to Google: Fund us or stop sending bugs
#402Earlier quoted context omitted.
In a follow-up tweet, Mark Atwood eloborates: "Amazon was very carefully complying with the licenses on FFmpeg. One of my jobs there was to make sure the company was doing so. Continuing to make sure the company was was often the reason I was having a meeting like that inside the company." I interpret this as meaning there was an implied "if you screw this up" at the end of "they could kill three major product lines…
Are you interpreting that as "if we violate the license, they can revoke our right to use the software" ?? And they use it in 3 products so that would be really bad. That would make sense to have a compliance person.
Re: FFmpeg to Google: Fund us or stop sending bugs
#403Earlier quoted context omitted.
It's a codec that is enabled by default at least on major Linux distributions, and that will be processed by ffmpeg without any extra flags. Anyone playing an untrusted video file without explictly overriding the codec autodetection is vulnerable. The format being obscure and having no real usage doesn't help when it's the attackers creating the files. The obscure formats are exposing just as much attack surface as t…
There are dozens if not hundreds of issues just like this one in ffmpeg, except for codecs that are infinitely more common. Google has been running all sorts of fuzzers against ffmpeg for over a decade at this point and it just never ends. It's a 20 year old C project maintained by poorly funded volunteers that mostly gives every media file ever the be-liberal-in-what-you-accept treatment, because people complain if…
This is software that is directly or indirectly run by millions of people on untrusted media files without sandboxing. It's not even that they don't care about security, it's that they're unaware that they should care. It should go without saying that they don't deserve to be hacked just because of that. Big companies doing tons of engineering work to add defense in depth for use cases on their own infrastructure (via sandboxing or disabling obsolete codecs) doesn't help those users. Finding and fixing the vulnerabilities does.
Re: FFmpeg to Google: Fund us or stop sending bugs
#404Earlier quoted context omitted.
It's a codec that is enabled by default at least on major Linux distributions, and that will be processed by ffmpeg without any extra flags. Anyone playing an untrusted video file without explictly overriding the codec autodetection is vulnerable. The format being obscure and having no real usage doesn't help when it's the attackers creating the files. The obscure formats are exposing just as much attack surface as t…
Sure, it's a valid bug report. But I don't understand why there has been so much drama over this when all the ffmpeg folks have to do is say "sorry, this isn't a priority for us so we'll get to it as soon as we can" and put the issue in the backlog as a low priority. If Google wants the issue fixed faster, they can submit a fix. If they don't care enough to do that, they can wait. No big deal either way. Instead, ffm…
But no. Intentionally or not, there was a whole drama created around it [1], with folks being criticized [2] for saying exactly what you said above, because their past (!) employers.
Instead of using the situation to highlight the need for more corporate funding for opensource projects in general, it became a public s**storm, with developers questioning their future contributions to projects. Shameful.
Re: FFmpeg to Google: Fund us or stop sending bugs
#405Earlier quoted context omitted.
The linked report seems to me to be the furthest thing from "slop". It is an S-tier bug report that includes a complete narrative, crash artifacts, and detailed repro instructions. I can't believe anyone is complaining about what is tied for the best bug report I have ever seen. https://issuetracker.google.com/issues/440183164?pli=1
It's a good quality bug report. But it's also a bug report about the decoder for "SANM ANIM v0" - a format so obscure almost all the search results are the bug report itself. Possibly a format exclusive to mid-1990s LucasArts games [1] Pretty crazy that ffmpeg supports the codec in the first place, IMHO. I can understand volunteers not wanting to sink time into maintaining a codec to play a video format that hasn't b…
Re: FFmpeg to Google: Fund us or stop sending bugs
#406Earlier quoted context omitted.
I've been a proponent of upstreaming fixes for open source software. Why? - It makes continued downstream consumption easier, you don't have to rely on fragile secret patches. - It gives back to projects that helped you to begin with, it's a simple form of paying it forward. - It all around seems like the "ethical" and "correct" thing to do. Unfortunately, in my experience, there's often a lot of barriers within comp…
I upstreamed a 1-line fix, plus tests, at my previous company. I had to go through a multi-month process of red tape and legal reviews to make it happen. That was a discouraging experience to say the least.
Re: FFmpeg to Google: Fund us or stop sending bugs
#407Earlier quoted context omitted.
Google is a multi-billion dollar company, which is paying people to find these bugs in the first place. That's a pretty core difference.
Great, so Google is actively spending money on making open source projects better and more secure. And for some reason everyone is now mad at them for it because they didn't also spend additional money making patches themselves. We can absolutely wish and ask that they spend some money and resources on making those patches, but this whole thing feels like the message most corporations are going to take is "don't do a…
I saw another poster say something about "buggy software". All software is buggy.
Re: FFmpeg to Google: Fund us or stop sending bugs
#408Earlier quoted context omitted.
As yet, Valve is the only company I know of doing this, and it's paying off in dividends both for Linux and for Valve. In just 5ish years of Valve investing people and money into Linux- specifically mesa and WINE, Linux has gone from a product that is kind of shaky with Windows, to "I can throw a windows program or game at it and it usually works". Imagine how further the OSS ecosystem would be if Open Source hadn't…
> Valve is the only company I know of [upstreaming fixes for open source software] Sorry, that's ridiculous. Basically every major free software dependency of every major platform or application is maintained by people on the payroll of one or another tech giant (edit: or an entity like LF or Linaro funded by the giants, or in a smaller handful of cases a foundation like the FSF with reasonably deep industry funding)…
Valve does seem somewhat rare position of making a proper Linux distro work well with games. Google’s Chromebooks don’t contribute to the linux ecosystem in the same holistic fashion it seems.
Re: FFmpeg to Google: Fund us or stop sending bugs
#409I’m an open source maintainer, so I empathize with the sentiment that large companies appear to produce labor for unpaid maintainers by disclosing security issues. But appearance is operative: a security issue is something that I (as the maintainer) would need to fix regardless of who reports it, or would otherwise need to accept the reputational hit that comes with not triaging security reports. That’s sometimes per…
From TFA: > The latest episode was sparked after a Google AI agent found an especially obscure bug in FFmpeg. How obscure? This “medium impact issue in ffmpeg,” which the FFmpeg developers did patch, is “an issue with decoding LucasArts Smush codec, specifically the first 10-20 frames of Rebel Assault 2, a game from 1995.” This doesn't feel like a medium-severity bug, and I think "Perhaps reconsider the severity" is…
Re: FFmpeg to Google: Fund us or stop sending bugs
#410Earlier quoted context omitted.
But if it's a real, serious issue without an easy resolution, who is the burden on? It's not that the maintainers wouldn't fix bugs if they easily could. FFmpeg is provided "as is"[0], so everyone should be responsible for their side of things. It's not like the maintainers dumped their software on every computer and forced people to use it. Google should be responsible for their own security. I'm not adamant that Go…
But if no bug report is filed, then only google gets the ability to "be responsible for their own security", everyone else either has to independently discover and then patch the bug themselves, or wait until upstream discovers the bug. In no reasonable reading of the situation can I see how anything Google has done here has made things worse: 1) Before hand, the bug existed, but was either known by no one, or known…