Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

41–50 of 913 posts

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

#41

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…

if you've ever read about codependency, "need" is a relative term.

codependency is when someone accepts too much responsibility, in particular responsibility for someone else or other things out of their control.

the answer is to have a "healthy neutrality".

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

#42
post #24

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

That is standard practice. It is considered irresponsible to not publicly disclose any vulnerability.

The X days is a concession to the developers that the public disclosure will be delayed to give them an opportunity to address the issue.

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

#43
post #24

Earlier quoted context omitted.

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.

They could be, and the chances of that increase immensely once Google publishes it.

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

#44
post #24

Earlier quoted context omitted.

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.

Sure but how.

Let's say that FFMPEG has a 10 CVE where a very easy stream can cause it to RCE. So what?

We are talking about software commonly for end users deployed to encode their own media. Something that rarely comes in untrusted forms. For an exploit to happen, you need to have a situation where an attacker gets out a exploited media file which people commonly transcode via FFMPEG. Not an easy task.

This sure does matter to the likes of google assuming they are using ffmpeg for their backend processing. It doesn't matter at all for just about anyone else.

You might as well tell me that `tar` has a CVE. That's great, but I don't generally go around tarring or untarring files I don't trust.

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

#47

Earlier quoted context omitted.

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.

Sure but how. Let's say that FFMPEG has a 10 CVE where a very easy stream can cause it to RCE. So what? We are talking about software commonly for end users deployed to encode their own media. Something that rarely comes in untrusted forms. For an exploit to happen, you need to have a situation where an attacker gets out a exploited media file which people commonly transcode via FFMPEG. Not an easy task. This sure do…

AIUI, (lib)ffmpeg is used by practically everything that does anything with video, including such definitely-security-sensitive things as Chrome, which people use to play untrusted content all the time.

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

#49
post #32
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.

Double funny considering new-grads who may polish up some UI features or rewrite components for the 10th time will get paid 200-400K TC at these same companies. Evidently these companies value something other than straight labor.

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

#50
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.

The first thing you can do is actually read the article. The question is not about the security reports but Google's policy on disclosing the vulnerability after x days. It works for crazy lazy corps. But not for OSS projects.
Post reply on HN