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

801–810 of 913 posts

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

#801

Post by Sohcahtoa82 »

strictnein wrote: post #226
esrauch wrote: post #139

Earlier quoted context omitted.

One problem here is that CVE scoring is basically entirely bugged, something scored 8.7 could be an RCE exploit or a "may be able to waste CPU" issue. That's the difference between "it may or may not be that there's someone who cares" versus "no one should be running this software anywhere in the general vicinity of untrusted inputs".

> One problem here is that CVE scoring is basically entirely bugged, something scored 8.7 could be an RCE exploit or a "may be able to waste CPU" issue. +100000 My favorite 8.x or higher CVEs are the ones where you would have to take untrusted user input, bypass all the standard ways to ingest and handle that type of data, and pass it into some internal function of a library. And then the end result is that a regex c…

If you think that's bad, you should look at Linux kernel CVEs. They're basically gone rogue when it comes to CVEs. Every minor bug gets flagged as a CVE, regardless of impact. Often, exploitation requires root access. If you have root, you've already won and can do whatever the hell you want. No need to exploit a bug to cause problems.

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

#802

Post by tombert »

izacus wrote: post #626
tombert wrote: post #474

Earlier quoted context omitted.

I've grown a bit disillusioned with contributing to Github. I've said this on here before, but a few months ago I wrote a simple patch for LMAX Disruptor, which was merged in. I like Disruptor, it's a very neat library, and at first I thought it was super cool to have my code merged. But after a few minutes, I started thinking: I just donated my time to help a for-profit company make more money. LMAX isn't a charity,…

Now count how many libraries you use in your day to day paid work that are opensource and you didn't have to pay anything for them. If you want to think selfishly about how awful it is to contribute to that body of work, maybe also purge them all from your codebase and contact companies that sell them?

Maybe those people shouldn’t be doing free labor to give me free libraries either.

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

#803

Post by f33d5173 »

ndriscoll wrote: post #778
f33d5173 wrote: post #523

Earlier quoted context omitted.

This has nothing to do with payment. Not deliberately infecting your users with vulnerabilities is simply the right thing to do. Giving something away for free doesn't absolve you of certain basic ethical responsibilities.

They're not deliberately infecting users with anything. There effectively saying "here's example code showing how to deal with these video formats. NOTE THAT THESE ARE EXAMPLES THAT I WROTE FOR FUN. THEY ARE NOT MEANT FOR SERIOUS USE AND MAY NOT HANDLE ALL CORNER CASES SAFELY. THIS SHOULD BE OBVIOUS SINCE WE HAVE NO COMMERCIAL RELATIONSHIP AND YOU'RE DOWNLOADING RANDOM CODE FROM SOMEONE YOU DON'T KNOW ON THE INTERNET…

The idea that things can be right and wrong seems to be lost on you.

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

#804

Post by OkayPhysicist »

skhameneh wrote: post #264
phkahler wrote: post #54

From TFA this was telling: Thus, as Mark Atwood, an open source policy expert, pointed out on Twitter, he had to keep telling Amazon to not do things that would mess up FFmpeg because, he had to keep explaining to his bosses that “They are not a vendor, there is no NDA, we have no leverage, your VP has refused to help fund them, and they could kill three major product lines tomorrow with an email. So, stop, and liste…

I've been a proponent of upstreaming fixes for open source software. Why? - It makes continued downstream consumption easier, you don't have to rely on fragile secret patches. - It gives back to projects that helped you to begin with, it's a simple form of paying it forward. - It all around seems like the "ethical" and "correct" thing to do. Unfortunately, in my experience, there's often a lot of barriers within comp…

This is why all open source software should be copyleft. No discussion to be had: either you upstream changes, or that open source developer's going to get funded via the courts.

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

#805

Post by flymasterv »

izacus wrote: post #585
Root_Denied wrote: post #558

Earlier quoted context omitted.

I'd say as a counterpoint that just because someone works at, say, Meta or Oracle, and also contributes to OSS projects, that doesn't equate to the company they work at funding upstream projects (at least not by itself). I don't even have to link the xkcd comic because everyone already knows which one goes here.

People don't use their company email addresses for private work.

At GOOG you’re required to, by policy.

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

#806

Post by kastagg »

tpmoney wrote: post #463
lenerdenator wrote: post #273

Earlier quoted context omitted.

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

The text and context of the complaint can be used to steelman it, adopting the principle of charity.

From that perspective, the most likely problem is not that bugs are being reported, nor even that patches are not being included with bug reports. The problem is that a shift from human-initiated bug reports to large-scale LLM generation of bug reports by large corporate entities generates a lot more work and changes the value proposition of bug reports for maintainers.

Even if you use LLMs to generate bug reports, you should have a human vet and repro them as real and significant and ensure they are written up for humans accurately and concisely, including all information that would be pertinent to a human. A human can make fairly educated decisions on how to combine and prioritize bug reports, including some degree of triage based on the overall volume of submissions relative to their value. A human can be "trained" to conform to whatever the internal policies or requirements are for reports.

Go ahead and pay someone to do it. If you don't want to pay, then why are you dumping that work on others?

Even after this, managing the new backlog entries and indeed dealing with a significantly larger archive of old bug reports going forward is a significant drag on human labor - bug reports themselves entail labor. Again, the old value proposition was that this was outweighed by the value of the highest-value human-made reports and intangibles of human involvement.

Bug reports are, either implicitly or explicitly, requests to do work. Patches may be part of a solution, but are not necessary. A large corporate entity which is operationally dependent on an open source project and uses automation to file unusually large volumes of bug reports is not filing them to be ignored. It isn't unreasonable to ask them to pay for that work which they are, one way or another, asking to have done.

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

#807

Post by xxs »

cogman10 wrote: post #64
omnicognate wrote: post #47

Earlier quoted context omitted.

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.

hmm, didn't realize chrome was using ffmpeg in the background. That definitely makes it more dangerous than I supposed. Looks like firefox does the same.

Pretty much anything that has any video uses the library (incl. youtube)

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

#808

Post by amarant »

Astronaut3315 wrote: post #322
skhameneh wrote: post #264

Earlier quoted context omitted.

I've been a proponent of upstreaming fixes for open source software. Why? - It makes continued downstream consumption easier, you don't have to rely on fragile secret patches. - It gives back to projects that helped you to begin with, it's a simple form of paying it forward. - It all around seems like the "ethical" and "correct" thing to do. Unfortunately, in my experience, there's often a lot of barriers within comp…

I upstreamed a 1-line fix, plus tests, at my previous company. I had to go through a multi-month process of red tape and legal reviews to make it happen. That was a discouraging experience to say the least.

My team lead once approved me upstreaming some changes to a open source project, so long as I did it using my private account.

Basically I got to do the work on company time&dime, but I couldn't give my employer credit, due to this kind of legal red tape.

I liked that teamlead

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

#809

Post by soerxpso »

nemothekid wrote: post #149
vadansky wrote: post #35

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.

> 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? Yes? It's in the license > NO WARRANTY > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANT…

That license also doesn't give the ffmpeg devs the right to dictate which bugs you're allowed to find, disclose privately, or disclose publicly. The software is provided as-is, without warranty, and I can do what I want with it, including reporting bugs. The ffmpeg devs can simply not read the bug reports, if they hate bug reports so much.

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

#810

Post by kastagg »

esrauch wrote: post #147
blibble wrote: post #5

Earlier quoted context omitted.

Google internally maintaining a fork that attempts to track upstream has a ongoing cost that increases over time vs. spamming OSS maintainers with slop reports costs Google nothing

Is there really slop here though? It sounds like the specific case identified was a real use after free in an obscure file format but which is enabled by default. If it was slop they could complain that it was wasting their time on false or unimportant reports, instead they seem to be complaining that the program reported a legitimate security issue?

If a maintainer complains about slop bug reports, instead of assuming the worst of the maintainer, it'll often be more productive to put yourself in their shoes and consider the context. An individual case may simply be the nth case in a larger picture (say, the straw that broke the camel's back). Whenever this nth case is observed, if you only consider that single case, a response also informed by detailed personal consideration of the preceding (n-1) cases may appear grossly and irrationally disproportionate, especially when the observer isn't personally that involved.

For a human, generating bug reports requires a little labor with a human in the loop, which imposes a natural rate limit on how many reports are submitted, which also imposes a natural triaging of whether it's personally worth it to report the bug. It could be worth it if you're prosocially interested in the project or if your operations depend on it enough that you are willing to pay a little to help it along.

For a large company which is using LLMs to automatically generate bug reports, the cost is much lower (indeed it may be longer-term profitable from a standpoint like marketing, finding product niches, refining models, etc.) This can be asymmetric with the maintainer's perspective, where the quality and volume of reports matter in affecting maintainer throughput and quality of life.

Post reply on HN