Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

Post reply on HN
Print view View original

751–760 of 913 posts

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

#751

Post by bayindirh »

red-iron-pine wrote: post #740
fao_ wrote: 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…

WINE was a thing for years and generally worked okay for a lot of things. I was playing Fallout 3 on WINE well before Valve got involved with minimal tweaks or DIY effort. Proton with Steam works flawlessly for most things including AAA games like RDR2 and it's great, but don't forget that WINE was out there making it work for a while

> WINE was a thing for years and generally worked okay for a lot of things.

Yes, but Valve's involvement handled "the last 10% takes the 90% of the time" part of WINE, and that's a great impact, IMHO.

Trivia: I remember WINE guys laughing at WMF cursor exploit, then finding the exploit works on WINE too and fix it in panic, and then bragging bug-for-bug compatibility with Windows. It was hilarious.

Also, WINE allowed Linux systems to be carrier for Windows USB flash drive virii without being affected by them for many years.

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

#752

Post by kierank »

surajrmal wrote: post #750
kierank wrote: post #660

Earlier quoted context omitted.

FFmpeg is developed almost entirely by volunteers. We have no "customers".

There are people who use and depend on ffmpeg. Maintainers seem to go out of their way to solve issues these folks face. If you don't care, then ignore the bug reports and force them to solve their own problems by contributing.

Then you and your security friends will create lots of FUD about FFmpeg being "insecure" with lots of red and the word "critical" everywhere.

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

#753

Post by tpmoney »

necovek wrote: post #713
tpmoney wrote: post #574

Earlier quoted context omitted.

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

And if they choose 2), would they stop to consider what happens if everybody does that? What's their fallback plan once maintainers dump the project? All I am saying is that you should be as mindful to open source maintainers as you are to the people at companies.

> would they stop to consider what happens if everybody does that?

It’s almost almost like bitching about the “free labor” open source projects are getting from their users, especially when that labor is of good quality and comes from a user that is actively contributing both code and money to the project is a losing strategy for open source fans and maintainers.

> All I am saying is that you should be as mindful to open source maintainers as you are to the people at companies.

And all I’m saying is there is nothing that’s “un-mindful” about reporting real bugs to an open source project, whether that report is public or not. And especially when that report is well crafted and actionable. If this report were for something that wasn’t a bug, is this report was a low quality “foo is broke, plz to fix” report with no actionable information, or if the report actually came with demands for responses and commitment timelines, then it would be a different matter. But ffmpeg runs a public bug tracker. To say then that making public bug reports is somehow disrespectful of the maintainers is ridiculous.

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

#754

Post by cestith »

jsnell wrote: post #286
cestith wrote: post #236

Earlier quoted context omitted.

Yes, security is by definition adversarial. Thanks for the most basic lesson. How are you getting ffmpeg to process a stream or file type different from the one you’re expecting? Most use cases of ffmpeg are against known input and known output types. If you’re just stuffing user-supplied files through your tools, then yes you have a different threat model.

> How are you getting ffmpeg to process a stream or file type different from the one you’re expecting? ... That is how ffmpeg works? With default settings it auto-detects the input codec from the bitstream, and the output codec from the extension. You have to go out of your way to force the input codec and disable the auto-detection, and I don't think most software using ffmpeg as a backend would force the user to ma…

In the industry I think folks generally know what they’re feeding into it and what they’re wanting out of it. When there’s a handoff between companies the stream encoding, bitrate, and resolution are generally part of the project spec. Within a company, your teams should know what they’re feeding into a tool and it’s probably not some obscure LucasArts game codec.

If it’s a potential problem for home users, yeah, that’s an issue but it’s not every use of the tool.

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

#755

Post by cestith »

esrauch wrote: post #321
cestith wrote: post #165

Earlier quoted context omitted.

The difference is that Google does use it, though. They use it heavily. All of us in the video industry do - Google, Amazon, Disney, Sony, Viacom, or whoever. Companies you may have never heard of build it into their solutions that are used by big networks and other streaming services, too.

Right, Google absolutely should fund ffmpeg. But opening security issues here is not related to that in any way. It's an obscure file format Google definitely doesn't use, the security issue is irrelevant to Google's usages of it. The critique would make sense if Google was asking for ffmpeg to implement something that Google wanted, instead of sending a patch. But they don't actually care about this one, they aren't…

Opening a security issue is not the problem. A public disclosure so soon when there are so many machine-assisted reports for such obscure issues is the problem.

If Google wants to force a faster turnaround on the fixes, they can send the reports with patches or they can pay for prioritization.

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

#756

Post by maybewhenthesun »

WesolyKubeczek wrote: post #701
josephg wrote: post #648

Earlier quoted context omitted.

Maybe, it depends! Maybe the developer intends to some day change the internal implementation, such that that particular boolean flag wouldn't make sense any more. Or they're considering taking out the option entirely, and thus simplifying the codebase by making it so it only works one way. Maybe the developer just doesn't care about your use case. If I have a project that works fine for what I do with it, why should…

I don't know. The pattern I have seen is that if you want to contribute a fix into a project, you are expected to "engage with the community", wear their badge, invest into the whole thing. I don't want to be in your community, I want to fix a bug in a thing I'm using and go on with my life. Given the usual dynamics of online communities which are getting somehow increasingly more prone to dramas, toxicity, tribalism…

In my experience simple bugfixes are nearly always accepted without fuss (in active projects, that is. Some project in maintenance mode where the last commit was 3 months ago is a different story, because then probably just no-one can be arsed to look at the patch).

Some simple setting expose like you describe can sometimes go in without a fuss or it can stall, that depends on a lot of factors. Like the other reply states: it could go against future plans. Or it could be difficult for the maintainer to see the ramifications of a simple looking change. It sucks that it is that way (I have sent in a few patches for obscure CUPS bugs which have stayed in limbo, so I know the feeling ;-) ) but it is hardly surprising. From a project's point of view drive-by patches very often cost more than they add so to get something included you often need to do a very thorough writeup as for why something is a good idea.

> I just as increasingly want to have no part in them most of the time. If all people you meet are assholes.... ;-P Not to say you are an asshole, or at least not more than most people, but I have been in this situation myself more than once, and it really pays to stay (overly) polite and not let your annoyance about being brushed off slip through the mask. The text-only nature of these kind of communications are very sensitive to misinterpretations and annoyances.

It would be nice if all you'd need for a patch to be included somewhere was for it to be useful. But alas there's a certain amount of social engineering needed as well. And imho this has always been the case. If you feel it gets increasingly hostile that's probably your own developer burnout speaking (by do I know that one :-P )

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

#757

Post by naasking »

tpmoney wrote: post #618
etiennebausson wrote: post #610

Earlier quoted context omitted.

Publicly posting an exploitable bug IS asking for someone to drop everything and come fix the issue NOW.

So when someone finds a bug in software, in your mind the only acceptable options are: 1) Fix it yourself 2) Sit on it silently until the maintainers finally get some time to fix it That seems crazy to me. For one, not everyone who discovers a bug can fix it themselves. But also a patch doesn't fix it until it's merged. If filing a public bug report is expecting the maintainers to "drop everything and do free labor"…

Responsible disclosure policies for contributor-driven projects can differ from commercial projects. Also, if Google has the funds to pay for bug finding, they also have the funds for bug fixing the community projects they depend on.

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

#758

Post by fulafel »

jorams wrote: post #745
fulafel wrote: post #615

Earlier quoted context omitted.

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 ) There's an appeals process: https://www.cve.org/Resources/General/Policies/CVE-Record-Di... And of course CVE is not the only numbering system, there's OSV DB,…

> this does possibly have a chilling effect if the vendor's CNA refuses valid vulns The Linux kernel went in the opposite direction: Every bugfix that looks like it could be relevant to security gets a CVE[1]. The number of CVEs has increased significantly since it became a CNA. [1]: https://lwn.net/Articles/978711/

Thanks. They seem to be pretty proactive indeed if you look at the feed: https://lore.kernel.org/linux-cve-announce/

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

#759

Post by zamadatix »

Brian_K_White wrote: post #535
dotancohen wrote: post #338

Earlier quoted context omitted.

The bug in question revolves around support for codec that has never been in wide use, and was only in obscure use over 25 years ago.

There is no "the bug". The discussion is about what to do with the power of bug-finding tools.

"The bug" in question refers to the one found by the bug-finding tool the article claims triggered the latest episode of debate. Nobody is claiming it's the only bug, just that this triggering bug highlighted was a clear example of where there is actually such a clear cut line.

Google does contribute some patches for codecs they actually consume e.g. https://github.com/FFmpeg/FFmpeg/commit/b1febda061955c6f4bfb..., the bug in question was just an example of one the bug finding tool found that they didn't consume - which leads to this conversation.

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

#760

Post by PapstJL4U »

tpmoney wrote: post #417
theoldgreybeard wrote: post #72

The vulnerability in question is a Use After Free. Google used AI to find this bug, it would've taken them 3 seconds to fix it. Burning cash to generate spam bug reports to burden volunteer projects when you have the extra cash to burn to just fix the damn issue leaves a very sour taste in my mouth.

If it takes 3 seconds to fix it, then how is this some massive burden on the maintainers? The bug report pointed to the relevant lines, the maintainers are the most familiar with the code and it probably would have taken them 1.5 seconds to not only fix it, but validate the fix. It probably took more time to write up the complaint about the bugs than to implement the fix.

It takes more time to read and understand the bug report, than to fix it. Instead of using googles time, they used ffmpegs voluntary time.

If this happens another 1000 times (easily possible with AI) google just got free labour and free publicity for "discovering 1000 critical bugs (but not fixing them even so they were easy to do)"

Post reply on HN