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

31–40 of 913 posts

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

#31

Post by ikiris »

StopDisinfo910 wrote: post #14
ganelonhb wrote: post #6

Not too fond of maintainers getting too uppity about this stuff. I get that it can be frustrating to receive bug report after bug report from people who are unwilling or unable to contribute to the code base, or at the very least to donate to the team. But the way I see it, a bug report is a bug report, no matter how small or big the bug or the team, it should be addressed. I don’t know, I’m not exactly a pillar of t…

It’s not bug reports. It’s CVE. There is a convergence of very annoying trends happening: more and more are garbage found and written using AI and with an impact which is questionable at best, the way CVE are published and classified is idiotic and platform founding vulnerability research like Google are more and more hostile to projects leaving very little time to actually work on fixes before publishing. This is le…

The lowered lead times are because devs have an entitled additude that others fix their code when they discover bugs in it.

The 90 day period is the grace period for the dev, not a demand. If they don't want to fix it then it goes public.

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

#32

Post by kwanbix »

prewett wrote: post #15

"They could shut down three product lines with an email" If you (Amazon, in this case) can put it that way, it seems like throwing them 10 or 20 thousand a year would simply be a good insurance policy! Any benefits you might get in goodwill and influence are a bonus.

How do you think Jeff got a 500 million dollars yacht? Not by writing checks.

But on a more serious note, it is crazy that between Google and Amazon they can not fund them with 50k each per year, so that they can pay people to work on this.

Specially Google, with Youtube, they can very easily pay them more. 100k~200k easily.

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

#33

Post by ivell »

benced wrote: post #17

This is dumb. Obscurity doesn’t create security. It’s unfortunate if ffmpeg doesn’t have the money to fix reported bugs but that doesn’t mean they should be ignorant of them. I don’t see any entitlement out of Google either - I expected this article would have a GH issue thread with a whiny YouTube engineer yelling at maintainers.

Agreed that obscurity is not security. However we don't want to make it easy for hackers to get a catalog of vulnerabilities to pick and choose from. I think the issue is public disclosure of vulnerabilities after a deadline. The hobbyists can't just keep up.

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

#34

Post by foolswisdom »

danlitt wrote: post #27
Msurrow wrote: post #13

Earlier quoted context omitted.

In addition to your point, it seems obvious that disclosure policy for FOSS should be “when patch available” and not static X days. The security issue should certainly be disclosed - when its responsible to do so. Now, if Google or whoever really feels like fixing fast is so important, then they could very well contribute by submitting a patch along with their issue report. Then everybody wins.

> it seems obvious that disclosure policy for FOSS should be “when patch available” and not static X days This is very far from obvious. If google doesn't feel like prioritising a critical issue, it remains irresponsible not to warn other users of the same library.

Part of the problem is that many of the issues are not really critical, no?

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

#35

Post by vadansky »

Msurrow wrote: post #24
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…

My takeaway from the article was not that the report was a problem, but a change in approach from Google that they’d disclose publicly after X days, regardless of if the project had a chance to fix it. To me its okay to “demand” from a for profit company (eg google) to fix an issue fast. Because they have ressources. But to “demand” that an oss project fix something with a certain (possibly tight) timeframe.. well I’…

On the other hand as an ffmpeg user do you care? Are you okay not being told a tool you're using has a vulnerability in it because the devs don't have time to fix it? I mean someone could already be using the vulnerability regardless of what Google does.

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

#38

Post by BoredPositron »

chemotaxis wrote: post #7

I am fairly confident that this article is largely AI-generated. More generally, the whole site appears to be heavy on AI slop, e.g.: https://thenewstack.io/how-ai-is-pushing-kubernetes-storage-... And maybe it's fine to have AI-generated articles that summarize Twitter threads for HN, but this is not a good summarization of the discussion that unfolded in the wake of this complaint. For one, it doesn't mention a rep…

Like the bug report in question... poetic.

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

#40

Post by dboon »

ranger_danger wrote: post #3

Wouldn't they just fork it, fix their own bugs and stop contributing at all?

Forking puts you in another hell as Google. Now you have to pay someone to maintain your fork! Maybe for a project that’s well and fully complete that’s OK. But something like FFmpeg is gonna get updated all the time, as the specs for video codecs are tweaked or released.

Their choice becomes to: - maintain a complex fork, constantly integrating from upstream. - Or pin to some old version and maybe go through a Herculean effort to rebase when something they truly must have merges upstream. - Or genuinely fork it and employ an expert in this highly specific domain to write what will often end up being parallel features and security patches to mainline FFmpeg.

Or, of course, pay someone in doing OSS to fix it in mainline. Which is the beauty of open source; that’s genuinely the least painful option, and also happens to be the one that benefits the community the most.

Post reply on HN