Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

461–470 of 913 posts

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

#461
post #372

Earlier quoted context omitted.

> Valve is the only company I know of [upstreaming fixes for open source software] Sorry, that's ridiculous. Basically every major free software dependency of every major platform or application is maintained by people on the payroll of one or another tech giant (edit: or an entity like LF or Linaro funded by the giants, or in a smaller handful of cases a foundation like the FSF with reasonably deep industry funding)…

From my time working at a Fortune 100 company, if I ever mentioned pushing even small patches to libraries we effing used , I'd just be met "try to focus on your tickets". Their OSS library and policies were also super byzantine, seemingly needing review of everything you'd release, but the few times I tried to do it the official way, I just never heard anything back from the black-hole mailing list you were supposed…

Those aren’t tech giants. They're just shit companies. I agree they greatly outnumber Big Tech, in employees if not talent.

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

#462
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…

The reason for this policy is that if you don’t keep a deadline upstream can just sit on the report forever while bad actors can find and exploit the vulnerabilities, which harms downstream users because they are left entirely unaware that the vulnerability even exists. The idea behind public disclosure is that downstream is now made aware of the bug and can take appropriate action on their side (for example, by avoiding the software, sponsoring a fix, etc.)

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

#463

Earlier quoted context omitted.

I understand the problem of corporations leeching off of the community here. I still fail to see why "ffmpeg is not allowed to fix bugs reported by corporations" is a good strategy. To me this sounds not logical.

Because they are making more money in profit than some mid-sized American cities' economies do in a year while contributing nothing back. If they don't want massive security vulnerabilities in their services using FFmpeg, maybe they need to pony up about .1 seconds' worth of their quarterly earnings to the project either in cash or in manpower. It's not FFmpeg's problem if someone uses a vulnerability to pwn YouTube,…

If they contribute nothing back, what are all the `google.com` email addresses in the git history doing? If they contribute nothing back, why are they listed as a customer of `fflabs.eu` which is apparently a private consulting company for ffmpeg run by some of the ffmpeg lead maintainers?

What do we think the lesson corporations are going to take from this is?

1) "You should file patches with your bug reports"

2) "Even when you submit patches and you hire the developers of OSS projects as consultants, you will still get dragged through the mud if you don't contribute a patch with every bug report you make, so you might as well not contribute anything back at all"

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

#464

Earlier quoted context omitted.

FFMPEG is upset because Google made the exploit public. They preferred that it remained a zero-day until they decided it was a priority. I don't understand how anyone believes that behavior is acceptable.

There's no exploit on the bug report at least, unless you consider the crash reproducer one.

UAF bugs lead to RCE exploit chains.

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

#465

Earlier quoted context omitted.

If google bears no role in fixing the issues it finds and nobody else is being paid to do it either, it functionally is just providing free security vulnerability research for malicious actors because almost nobody can take over or switch off of ffmpeg.

I guess the question that a person at Google who discovers a bug they don’t personally have time to fix is, should they report the bug at all? They don’t necessarily know if someone else will be able to pick it up. So the current “always report” rule makes sense since you don’t have to figure out if someone can fix it. The same question applies if they have time to fix it in six months, since that presumably still gi…

It doesn't matter how obscure it is if it's a vulnerability that's enabled in default builds.

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

#466

Earlier quoted context omitted.

It's a good quality bug report. But it's also a bug report about the decoder for "SANM ANIM v0" - a format so obscure almost all the search results are the bug report itself. Possibly a format exclusive to mid-1990s LucasArts games [1] Pretty crazy that ffmpeg supports the codec in the first place, IMHO. I can understand volunteers not wanting to sink time into maintaining a codec to play a video format that hasn't b…

Yeah but as you can see from the bug report ffmpeg automatically triggers the codec based on file magic, so it is possible that if you run some kind of network service or anything that handles hostile data an attacker could trigger the bug.

It feels like maybe people do not realize that Google is not the only company that can run fuzzers against ffmpeg? Attackers are also highly incentivized to do so and they will not do you the courtesy of filing bug reports.

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

#467
post #444

Earlier quoted context omitted.

Publishing bugs that the project has so that they can be fixed is actively making the project more secure. How is someone going to do anything about it if Google didn’t do the research?

Did you see how the FFMPEG project patched a bug for a 1995 console? That's not a good use for the limited amount of volunteers on the project. It actively makes it less secure by taking away from more pertinent bugs.

Then they should mark it as low priority and put it in their backlog. I trust that the maintainers are good judges of what deserves their time.

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

#469
post #339

Earlier quoted context omitted.

No, publishing the vulnerability is the right thing to do for a secure world because anyone can find this stuff including nation states that weaponize it. This is a public service. Giving the dev a 90 day pre warn is a courtesy. Expecting a reporter to fix your security vulnerabilities for you is entitlement. If your reputation is harmed by your vulnerable software, then fix the bugs. They didn’t create the hazzard t…

This is all true(maybe not the extortion being worse hard to say), but it doesnt change the fact that publishing the CVE is a demand to fix it.

No, it is a notice to others that your software as-is is insecure in some way. The pre notice is again a courtesy if you want to fix it.

What you do with the notice as a dev is up to you, but responsible ones would fix it without throwing a tantrum.

Devs need to stop thinking of themselves as the main character and things get a lot more reasonable.

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

#470
post #407

Earlier quoted context omitted.

Great, so Google is actively spending money on making open source projects better and more secure. And for some reason everyone is now mad at them for it because they didn't also spend additional money making patches themselves. We can absolutely wish and ask that they spend some money and resources on making those patches, but this whole thing feels like the message most corporations are going to take is "don't do a…

They're actively making open source projects less secure by publishing bugs that the projects don't have the volunteers to fix I saw another poster say something about "buggy software". All software is buggy.

The bug exists whether or not google publishes a public bug report. They are no more making the project less secure than if some retro-game enthusiast had found the same bug and made a blog post about it.
Post reply on HN