Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

841–850 of 913 posts

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

#841

Earlier quoted context omitted.

> If you used the scan to pdf functionality of a [Xerox] like this a decade ago, your PDF likely had a JBIG2 stream in it. That's not an obscure format, that's an old format. Meanwhile with ffmpeg we're talking about > decoding LucasArts Smush codec, specifically the first 10-20 frames of Rebel Assault 2, a game from 1995. That's both old and obscure . Your point is still taken, but just to clarify that these are dif…

The problem is that if you have a process using ffmpeg and an attacker feeds it a video with this codec, ffmpeg will proceed to auto-detect the codec, attempt to decrypt and then then break everything. If the format is old and obscure, and the implementation is broken, it shouldn't be on by default.

Sorry, I probably wasn't clear enough in my comment. I was trying to say that being old gives some legitimacy for existing. Just because it is old doesn't mean it isn't used. Though yes, this should be better determined to make sure it isn't breaking workflows you don't know about.

But old AND obscure, well it's nice that it is supported but enabled by default? Fully with you there.

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

#842

Earlier quoted context omitted.

Are you on the autistic spectrum and/or not a native speaker of English? If we are discussing if FFMPEG's stance is reasonable, then it follows we are discussing of Google's actions are unreasonable. Google is absolutely being unreasonable here -- they should instruct their engineers to submit a patch when submitting CVEs, and FFMPEG is perfectly valid to engage in a little activism to nudge them along.

> [...]then it follows we are discussing[...] It's all connected but... Here, I'll phrase it more simply: They didn't agree that google is being unreasonable. You are not interpreting them right. I don't care how confident you are that google is being unreasonable. The "your stance seems to be" statement in your previous comment is wrong.

Let's pull back up the core line here:

>it's not "unreasonable" to ask for patches along with bug fixes, but it is unreasonable to be mad if they don't

So the ask (make a patch for your CVEs) is reasonable. It follows that to fail to do so is unreasonable. Whether the poster agrees Google is unreasonable or not is up for debate, but if they choose to espouse that the request is reasonable and that Google is reasonable, they're putting forth an irrational belief not rooted in their own logic.

But hey, lots of folks on HN are biased towards Google for financial reasons, so I totally get it.

But either their stance is how I said, or if their stance differs they are a hypocrite, there really is no middle ground here.

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

#843

Earlier quoted context omitted.

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…

> the very idea that they owe you anything All I'm asking for right here is consistency about whether the library is mostly secure. The ethical requirement is to follow through on your claims and implications, while making claims and implications is completely optional. > 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 a…

The library probably is mostly secure, and it might even be the best library out there for what it does. That still leaves them with no ethical requirement at all.

People are allowed to make secure, robust software for fun. They can take pride in how good of a job they do at that. They can correctly point out that their software is the best. That still leaves them with no obligations at all for having shared their project for free.

If you are not an expert in hardening computers, don't run random untrusted inputs through it, or pay someone to deliver a turnkey hardened system to you. That someone might be Adobe selling their codecs/processing tools, or it might be an individual or a company like Redhat that just customizes ffmpeg for you. In any case, if you're not paying someone, you should be grateful for whatever goodwill you get, and if you don't like it, you can immediately get a full refund. You don't even have to ask.

The person doing serious things in a professional context is always the one with the obligation to do them correctly. When I was at IBM, we used exactly 1 external library (for very early processor initialization) and 1 firmware blob in the product I worked on, and they were paid deliverables from hardware vendors. We also paid for our compiler. Everything else (kernel, drivers, firmware, tools) was in-house. If companies want to use random free code they found on the Internet without any kind of contract in place, that's up to them.

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

#844

Earlier quoted context omitted.

It's frustrating to me how many people are siding with FFmpeg here considering how unprofessional and generally asshole-ish they are being. I feel that this is mostly a kneejerk reaction to AI and Google in general, with people coming up with arguments to support their reaction after already forming an opinion.

It's a volunteer project, they have no requirement to be 'professional'. That's basically the root of the whole issue. A hobby project is not a product, and its developers are not vendors. Free software is not a supply chain.

> A hobby project is not a product, and its developers are not vendors

But it's developers do offer paid consulting as ffmpeg maintainers, which Google does pay for.

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

#845
post #81

I don't understand the rational for announcing that a vulnerability in project X was discovered before the patch is released. I read the project zero blogspot announcement but it doesn't make much sense to me. Google claims this is help downsteam users but that feels like a largely non-issue to me. If you announce a vulnerability (unspecified) is found in a project before the patch is released doesn't that just incen…

"Don't announce an unpatched vulnerability ever" used to be the norm. It caused a massive problem: most companies and organizations would never patch security vulnerabilities, so vulnerabilities would last years or sometimes decades being actively exploited with nobody knowing about it.

Changing the norm to "We don't announce unpatched vulnerabilities but there is a deadline" was a massive improvement.

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

#846
I think the main issue is the 90 day disclosure. Maybe Google can allow the maintainers to extend that deadline for low / medium impact issues.

I see no reason to follow the 90 day timeline if the maintainer is working on it. Especially considering it is very possible for Google to overwhelm a project with thousands of vulnerability reports.

Otherwise, I don't think Google should issue a patch, just like in this case, only FFmpeg people know it is an obscure codec that nobody really uses, and maybe the reasonable approach would be to simply remove it. Google don't know that, unless they somehow take over the project.

And AFAIK Google is one of the biggest sponsor for SPI, which is the fiscal sponsor for ffmpeg. So not sure where the not paying thing came from.

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

#848

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…

If Google can pay someone to find bugs, they can pay someone to fix them.

Sounds like they'll just throw their employees to work on it rather than monetarily fund it, that way they can aura farm.

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

#849

Earlier quoted context omitted.

It’s OSS so somebody who cares will fix it, and if nobody cares then it doesn’t really matter. This also informs users that it’s not safe to use ffmpeg or software derived from it to open untrusted files, and perhaps most importantly releasing this tells the distro package maintainers to disable the particular codec when packaging.

Right, I just don’t see why they need to publish the actual exploit.

They have not, neither have they indicated that they’re planning to do so.

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

#850

Earlier quoted context omitted.

> [...]then it follows we are discussing[...] It's all connected but... Here, I'll phrase it more simply: They didn't agree that google is being unreasonable. You are not interpreting them right. I don't care how confident you are that google is being unreasonable. The "your stance seems to be" statement in your previous comment is wrong.

Let's pull back up the core line here: > it's not "unreasonable" to ask for patches along with bug fixes, but it is unreasonable to be mad if they don't So the ask (make a patch for your CVEs) is reasonable. It follows that to fail to do so is unreasonable. Whether the poster agrees Google is unreasonable or not is up for debate, but if they choose to espouse that the request is reasonable and that Google is reasonab…

> So the ask (make a patch for your CVEs) is reasonable. It follows that to fail to do so is unreasonable.

Ah, that's where the confusion happens. It's your stance that it follows, but tpmoney was directly disagreeing with that logic.

tpmoney's stance, and my stance, is that it's reasonable to ask and it's also reasonable to say no.

It's not irrational to say that you can reasonably decline a reasonable request. Jeez.

(Also even if it was irrational, that wouldn't make tpmoney a hypocrite. That claim is just weird.)

Post reply on HN