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

701–710 of 913 posts

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

#701

Post by WesolyKubeczek »

josephg wrote: post #648
WesolyKubeczek wrote: post #624

Earlier quoted context omitted.

Not any patch. Sometimes there are patches that are not explicitly fixing defects, but for example they surface a boolean setting that some upstream library started to expose. That setting is exactly like a dozen other settings already there. It's made using the same coding style and has all requisite things other settings have. Will you be still making a fuss over it?

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, and polarization, I just as increasingly want to have no part in them most of the time.

I think many projects would be better for having a lane for drive-by contributors who could work on fixing bugs that prevent their day-to-day from working without expectations of becoming full-time engaged. The project could set an expectation that "we will rewrite your patch as we see fit so we could integrate and maintain it, if we need/want to". I wouldn't care as long as the problem is taken care of in some way.

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

#702

Post by etiennebausson »

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

xz was a fundamentally different problem, it was code that had been maliciously introduced to a widespread library and the corrupted version was in the process of being deployed to multiple distributions. The clock was very much ticking.

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

#703

Post by WesolyKubeczek »

josephg wrote: post #648
WesolyKubeczek wrote: post #624

Earlier quoted context omitted.

Not any patch. Sometimes there are patches that are not explicitly fixing defects, but for example they surface a boolean setting that some upstream library started to expose. That setting is exactly like a dozen other settings already there. It's made using the same coding style and has all requisite things other settings have. Will you be still making a fuss over it?

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…

> 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 also care about some other use case you have for my work?

Then say you don't expect contributions at all. That's a fair game, I'm ok with it. I will then exercise my rights granted by your license in another way (forking and making my own fix most likely). My gripe is with projects that write prominently "PRs welcome", and then make enough red tape to signal that nah, not really.

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

#705

Post by bawolff »

rsanek wrote: post #138
eddd-ddde wrote: post #127

Earlier quoted context omitted.

So your claim is that buggy software is better than documented buggy software?

I think so, yes. Certainly it's more effort to both find and exploit a bug than to simply exploit an existing one someone else found for you.

> I think so, yes. Certainly it's more effort to both find and exploit a bug than to simply exploit an existing one someone else found for you.

That just means the script kiddies will have more trouble, while more scary actors like foreign intellegence agencies will have free reign.

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

#706

Post by codeptualize »

I think the glaring issue underlying this is that the big companies are not investing enough in the tools they rely on.

I agree with some of the arguments that patching up vulnerabilities is important, but it's crazy to put that expectation on unpaid volunteers when you flood them with CVE's some completely irrelevant.

Also the solution is fairly simple: Either, you submit a PR instead of an issue. Or, you send a generous donation with the issue to reward and motivate the people who do the work.

The amount of revenue they generate using these packages will easily offset the cost of funding the projects, so I really think it's a fair expectation for companies to contribute either by delivering work or funds.

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

#708

Post by kllrnohj »

Orygin wrote: post #679
surajrmal wrote: post #654

Earlier quoted context omitted.

The timeline is industry standard at this point. The point is make sure folks take security more seriously. If you start deviating from the script, others will expect the same exceptions and it would lose that ability. Sometimes it's good to let something fail loudly to show this is a problem. If ffmpeg doesn't have enough maintainers, then they should fail and let downstream customers know so they have more pressure…

Is it industry standard to run automatic AI tools and spam the upstream with bug reports? To then expect the bugs to be fixed within a 90 days is a bit much. It's not some lone report of an important bug, it's AI spam that put forth security issues at a speed greater than they have resources to fix it.

"AI tools" and "spam" are knee jerk reactions, not an accurate picture of the bug filed: https://issuetracker.google.com/issues/440183164?utm_source=...

whether or not AI found it, clearly a human refined it and produced a very high quality bug report. There's no AI slop here. No spam.

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

#709

Post by kragen »

chii wrote: post #538
ekidd wrote: post #500

Earlier quoted context omitted.

> they shouldn't be its maintainers. I mean, yes, the ffmpeg maintainers are very likely to decide this on their own, abandoning the project entirely. This is already happening for quite a few core open source projects that are used by multiple billion-dollar companies and deployed to billions of users. A lot of the projects probably should be retired and rewritten in safer system languages. But rewriting all of the…

> abandoning the project entirely that is a good outcome, because then the people dependent on such a project would find it plausible to pay a new set of maintainers.

We'll see. Video codec experts won't materialize out of thin air just because there's money.

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

#710

Post by seb1204 »

Yokolos wrote: post #229
woodruffw wrote: post #10

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…

I see you didn't read the article. The problem isn't Google reporting vulnerabilities. It's Google using AI to find obscure bugs that affect 2 people on the planet, then making a CVE out of it, without putting any effort into fixing it themselves or funding the project. What are the ffmpeg maintainers supposed to do about this? It's a complete waste of everybody's time. > The latest episode was sparked after a Google…

Mark it low, and estimate by when it can be fixed (3, 4 months from now). Advise google of it. Google does not need to disclose this bug that fast. If I do something one the side or as hobby and big corp comes by to tell me to hurry up I feel inclined to say no thanks.
Post reply on HN