Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

571–580 of 913 posts

Re: FFmpeg to Google: Fund us or stop sending bugs

#571

From TFA this was telling: Thus, as Mark Atwood, an open source policy expert, pointed out on Twitter, he had to keep telling Amazon to not do things that would mess up FFmpeg because, he had to keep explaining to his bosses that “They are not a vendor, there is no NDA, we have no leverage, your VP has refused to help fund them, and they could kill three major product lines tomorrow with an email. So, stop, and liste…

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…

interesting, checking the git history of FFmpeg, google has approximately 643 contributions

    git clone https://git.ffmpeg.org/ffmpeg.git
    cd ffmpeg
    git log --pretty=format:"%ae" | grep -E "chromium\\.org|google\\.com" | wc -l
prints 643

Re: FFmpeg to Google: Fund us or stop sending bugs

#572
post #323

Earlier 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…

They totally broke CSGO Legacy's code to push its sequel CS2 and won't accept fixes for it because it's 'not being supported'.

To be clear, both of those are closed source, proprietary games owned by Valve. It makes sense for them to want to consolidate their player base in one game.

Re: FFmpeg to Google: Fund us or stop sending bugs

#573
So what if ffmpeg has open CVEs? What is Google going to do? Swap it? Leave them open, let Google ship products with CVE'd dependencies, and then they'll be forced to act.

Why would Google act if they got smart guys working for them for free? Stop fixing Google-reported bugs.

Re: FFmpeg to Google: Fund us or stop sending bugs

#574

Earlier quoted context omitted.

> When you publicize a vulnerability you know someone doesn't have the capacity to fix according to the requested timeline, you are simultaneously increasing the visibility of the vulnerability and name-calling the maintainers. So how long should all bug reporters wait before filing public bugs against open source projects? What about closed source projects? Anyone who works in software knows to ship software is to a…

It's funny you come up with that suggestion when I clearly offer a different solution: "make your internal teams do the right thing by both reporting, but also helping fix the issue with hands-on work". It's a call not to stop reporting, but to equally invest in fixing these.

Hands on work like filing a detailed bug report with suspected line numbers, reproduction code and likely causes? Look, I get it. It would be nice if Google had filed a patch with the bug. But also not every bug report is going to get a patch with it, nor should that be the sort of expectation we have. It's hard enough getting corporations to contribute time and resources to open source projects as it is, to set an expectation that the only acceptable corporate contribution to open source is full patches for any bug reports is just going to make it that much harder to get anything out of them.

In the end, Google does submit patches and code to ffmpeg, they also buy consulting from the ffmpeg maintainers. And here they did some security testing and filed a detailed and useful bug report. But because they didn't file a patch with the bug report, we're dragging them through the mud. And for what? When another corporation looks at what Google does do, and what the response this bug report has gotten them, which do you think is the most likely lesson learned?

1) "We should invest equally in reporting and patching bugs in our open source dependencies"

2) "We should shut the hell up and shouldn't tell anyone else about bugs and vulnerabilities we discover, because even if you regularly contribute patches and money to the project, that won't be good enough. Our name and reputation will get dragged for having the audacity to file a detailed bug report without also filing a patch."

Re: FFmpeg to Google: Fund us or stop sending bugs

#575
post #341

I’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…

That quote felt pretty disingenuous. OK, so the proof of concept was found in some minor asset of an old video game. But is it an exploitable vulnerability? If so, you will quickly find it on modern-day scummy advertising networks. Will it still be "medium severity"? Not clear either way to me, from the quote.

Re: FFmpeg to Google: Fund us or stop sending bugs

#576
post #323

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…

Valve is so successful because it is a private company, and the CEO is the CTO and he is essentially the corporate equivalent of a religious monk. How else can you get 20+ years to slowly build a software business?

As a side note YC and tech startups themselves have become reality TV. Your goal should be Valve! You should be Gabe Newell! You don’t need to be famous! Just build something valuable and be patient

Re: FFmpeg to Google: Fund us or stop sending bugs

#577
post #192

Earlier quoted context omitted.

Watch places like Amazon and Google suddenly stop updating and trying to find alternatives. Like how Apple stopped using up to date the GNU tools in 2008 because of GPL3. That moved showed me then that Apple did not want you to use your computer as your computer.

Well, to continue that timeline. "Big Tech" freezes their version to the last gpl'ed version, and each commences their own (non-trivial effort) to make their own version (assuming the last gpl'ed version was not feature-complete for all their future uses). And of course, they won't share with each other. So another driver would be fear of a slight competitive disadvantage vs other-big-tech-monstrosity having a better…

Imagine Google paying only 100k to ffmpeg though. That's like a single 3-month top-SWE pay at Google.

Re: FFmpeg to Google: Fund us or stop sending bugs

#578

Earlier quoted context omitted.

But how are those companies supposed to know they need to do anything unless someone finds and publicly reports the issue in the first place? Surely we're not advocating for a world where every vendor downstream of the ffmpeg project independently discovers and patches security vulnerabilities without ever reporting the issues upstream right?

If they both funded vulnerability scanning and vulnerability fixing (if they don't want to do it in-house, they can sponsor the upstream team), which is to me the obvious "how", I am not sure why you believe there is only one way to do it. It's about accountability! Who really gets to do it once those who ship it to customers care, is on them to figure out (though note that maintainers will have some burden to review…

They regularly submit code and they buy consulting from the ffmpeg maintainers according to the maintainer's own website. It seems to me like they're already funding fixes in ffmpeg, and really everyone is just mad that this particular issue didn't come with a fix. Which is honestly not a great look for convincing corporations to invest resources into contributing to upstream. If regular patches and buying dev time from the maintainers isn't enough to avoid getting grief for "not contributing" then why bother spending that time and money in the first place?

Re: FFmpeg to Google: Fund us or stop sending bugs

#580

Earlier quoted context omitted.

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…

Best response would be to drop this codec entirely, or have it off by default. At least distros should do that.

The actual best response would be to run any "unsupported" codecs in a WASM sandbox. That way you are not throwing away work, Google can stop running fuzzers against random formats from 1995, and you can legitimately say that the worst that can happen with these formats is a process crash. Everybody wins.
Post reply on HN