In this scenario does your employer have strong controls around what whether you can write hobby code on your own time?
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.
The bug report in question is obviously written by a human: https://issuetracker.google.com/issues/440183164?pli=1 It's of excellent quality. They've made things about as easy for the FFmpeg devs as possible without actually fixing the bug, which might entail legal complications they want to avoid. AI was only used to find the bug.
"obviously". You have 0 evidence for your comment. Big sleep is credited as reporter.
In this scenario does your employer have strong controls around what whether you can write hobby code on your own time?
Generally yes. Or yes, you could just do it yourself in your free time.
This is what I've done in those rare cases I've had to fix a bug in a tool or a library I've used professionally. I've also made sure to do that using online identities with no connection to my employer so that any small positive publicity for the contribution lands on my own CV instead of the bureaucratic company getting the bragging rights.
I've literally had my employer's attorneys tell me I can't upstream patches because it would put my employer's name on the project, and they don't want the liability. No, it didn't help giving them copies of licenses that have the usual liability clauses. It seems a lot of corporate lawyers fundamentally misunderstand open source.
Why would they invest resources - scarce, expensive time of attorneys - in researching and solving this problem? The attorneys' job is to help the company profit, to maximize ROI for legal work. Where is the ROI here? And remember, just positive ROI is unacceptable; they want maximum ROI per hour worked. When the CEO asks them how this project maximized ROI, what do they say? I believe in FOSS and can make an argumen…
If you fixed something in an open source library you use, and you don't push that upstream, you are bound to re-apply that patch with every library update you do. And today's compliance rules require you to essentially keep all libraries up to date all the time, or your CVE scanners will light up. So fixing this upstream in the original project has a measurable impact on your "time spent on compliance and updates KPI".
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.
This is a fantastic argument for the universe where Google does not disclose vulnerability until the maintainers had had reasonable time to fix it. In this world the user is left vulnerable because attackers can use published vulnerabilities that the maintainers are to overwhelmed to fix
In this world and the alternate universe both, attackers can also use _un_published vulnerabilities because they have high incentive to do research. Keeping a bug secret does not prevent it from existing or from being exploited.
The user is vulnerable while the problem is unfixed. Google publishing a vulnerability doesn't change the existence of the vulnerability. If Google can find it, so can others. Making the vulnerability public makes it easy to find to exploit, but it also makes it easy to find to fix.
>If Google can find it, so can others. What a strange sentence. Google can do a lot of things that nobody can do. The list of things that only Google, a handful of nation states, and a handful of Google-peers can do is probably even longer.
Nation-states are a very relevant part of the threat model.
As yet, Valve is the only company I know of doing this, and it's paying off in dividends both for Linux and for Valve. In just 5ish years of Valve investing people and money into Linux- specifically mesa and WINE, Linux has gone from a product that is kind of shaky with Windows, to "I can throw a windows program or game at it and it usually works". Imagine how further the OSS ecosystem would be if Open Source hadn't…
I'm glad you threw in "I know of", because that part is true. Feel free to read lore.kernel.org, and sort out where the people contributing many patches actually work.
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.
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.
The entire conflict here is that norms about what's considered responsible were developed in a different context, where vulnerability reports were generated at a much lower rate and dedicated CVE-searching teams were much less common. FFmpeg says this was "AI generated bug reports on an obscure 1990s hobby codec"; if that's accurate (I have no reason to doubt it, just no time to go check), I tend to agree that it doe…
The codec is compiled in, enabled by default, and auto detected through file magic, so the fact that it is an obscure 1990s hobby codec does not in any way make the vulnerability less exploitable. At this point I think FFmpeg is being intentionally deceptive by constantly mentioning only the ancient obscure hobby status and not the fact that it’s on by default and autodetected. They have also rejected suggestions to turn obscure hobby codecs off by default, giving more priority to their goal of playing every media format ever than to security.