Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

621–630 of 913 posts

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

#622
post #551

Earlier quoted context omitted.

Generally yes. Or yes, you could just do it yourself in your free time.

Even at places that are permissive about hobby code, a company ought to want to put its name on open source contributions. These build awareness in the programming community of the company and can possibly serve as a channel for recruitment leads. But the (usually false) perception of legal risk and misguided ideas about what constitutes productivity usually sink any attempts.

It is amazing how companies want this "marketing" but don't want to put the actual effort to make it possible.

A tech company I worked at once had a "sponsorship fund" to "sponsor causes" that employees wanted, it was actually good money but a drop in the bucket for a company. A lot of employees voted for sponsoring Vue.js, which is what we used. Eventually, after months of silence, legal/finance decided it was too much work.

But hey it wasn't an exception. The local animal shelter was the second most voted and legal/finance also couldn't figure it out how to donate.

In the end the money went to nowhere.

The only "developer marketing" they were doing was sending me in my free time to do panels with other developers in local universities and conferences. Of course it was unpaid, but in return I used it to get another job.

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

#623
post #605

Earlier quoted context omitted.

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…

This was not a case of stumbling across a bug. This was dedicated security research taking days if not weeks of high paid employees to find. And after all that, they just drop an issue, instead of spending a little extra time on producing a patch.

It’s possible that this is a more efficient use of their time when it comes to open source security as a whole, most projects do not have a problem with reports like this.

If not pumping out patches allows them to get more security issues fixed, that’s fine!

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

#624

Earlier quoted context omitted.

> Unfortunately, in my experience, there's often a lot of barriers within companies to upstream. Reasons can be everything from compliance, processes, you name it... It's unfortunate. I’ve been at several companies where upstreaming was encouraged for everything. The fewer internal forks we could maintain, the better. What surprised me was how many obstacles we’d run into in some of the upstream projects. The amount…

While there's sometimes maintainer-prima-donna egos the contend with there's also this: Any patch sent in also needs to be maintained into the future, and most of the time it's the maintainers that need to do that, not the people contributing the patch. Therefore any feature-patches (as opposed to simple bugfixes) are quite often refused, even if they add useful functionality, because the maintainers conclude they wi…

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?

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

#625
post #598

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…

Why should Google not be expected to also contribute fixes to a core dependency of their browser, or to help funding the developers? Just publishing bug reports by themselves does not make open source projects secure!

Google does do that.

This bit of ffmpeg is not a Chrome dependency, and likely isn’t used in internal Google tools either.

> Just publishing bug reports by themselves does not make open source projects secure!

It does, especially when you first privately report them to the maintainers and give them a plenty of time to fix the bug.

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

#626

Never work for free. It's a complete market distortion and leads to bad actors taking advantage of you and your work.

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?

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

#628

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.

Then maybe the Google chrome devs should submit a PR to ffmpeg.

Chrome devs frequently do just that, Chrome just doesn’t enable this codec.

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

#629

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.

If you use a trillion dollar AI to probe open source code in ways that no hacker could, you're kind of unearthing the vulnerabilities yourself if you disclose them.

This particular bug would be easy to find without any fancy expensive tools.

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

#630
post #406

Earlier quoted context omitted.

In this scenario does your employer have strong controls around what whether you can write hobby code on your own time?

One of my past employers in the UK added to the policy all the software the employee writes during the employment (eg. during the weekend, on the personal hardware), is owned by the company. Several software engineers left, several didn't sign it. Yes, company was very toxic apart of that. Yeah, I should name and shame but I won't be doxxing myself.

Many years ago an employer tried to to that and everyone .. just refused to sign the new contracts. The whole thing sat in standoff limbo for months until the dotcom crash happened and the issue became moot when we were all made redundant.
Post reply on HN