FFmpeg To Google: Fund Us or Stop Sending Bugs (thenewstack.io) 113
FFmpeg, the open source multimedia framework that powers video processing in Google Chrome, Firefox, YouTube and other major platforms, has called on Google to either fund the project or stop burdening its volunteer maintainers with security vulnerabilities found by the company's AI tools. The maintainers patched a bug that Google's AI agent discovered in code for decoding a 1995 video game but described the finding as "CVE slop."
The confrontation centered on a Google Project Zero policy announced in July that publicly discloses reported vulnerabilities within a week and starts a ninety-day countdown to full disclosure regardless of patch availability. FFmpeg, written primarily in assembly language, handles format conversion and streaming for VLC, Kodi and Plex but operates without adequate funding from the corporations that depend on it. Nick Wellnhofer resigned as maintainer of libxml2, a library used in all major web browsers, because of the unsustainable workload of addressing security reports without compensation and said he would stop maintaining the project in December.
The confrontation centered on a Google Project Zero policy announced in July that publicly discloses reported vulnerabilities within a week and starts a ninety-day countdown to full disclosure regardless of patch availability. FFmpeg, written primarily in assembly language, handles format conversion and streaming for VLC, Kodi and Plex but operates without adequate funding from the corporations that depend on it. Nick Wellnhofer resigned as maintainer of libxml2, a library used in all major web browsers, because of the unsustainable workload of addressing security reports without compensation and said he would stop maintaining the project in December.
Mail server tweak (Score:5, Insightful)
Modify your mail server to return all emails from google to sender with status=Undelivered. If they haven't delivered the message, their bots may spot it and not start the countdown.
Bonus:
Allow only those emails in that carry a bitcoin pre-payment or a gift card code.
Re: Mail server tweak (Score:4, Interesting)
Or they might decide the devs are unable to be contacted and the vulnerability should be immediately released.
Re: Mail server tweak (Score:4, Interesting)
Full disclosure would also press the companies most. It isn't average joe who will be attacked instantly. Attackers will try to exploit YouTube and other large sites.
Re: (Score:2)
Right, and just leave the vulnerabilities unpatched so that someone else with AI can start exploiting them.
A 1995 video game format may sound unimportant, but if you say run a website where users can upload video, which gets transcoded with ffmpeg...
Re:Mail server tweak (Score:4)
If Goog is using the code in Chrome, why can't the Chrome team fix the issues and submit the patches to the maintainer? Isn't that how open source is supposed to work anyway? I know... I am a summer child
Re: (Score:2)
That was my other thought, why don't they submit a patch fixing it? Or maybe they did and it just needed review.
90 days, huh? (Score:2, Interesting)
Google Project Zero policy announced in July that publicly discloses reported vulnerabilities within a week and starts a ninety-day countdown to full disclosure regardless of patch availability
What's tempting here is finding some 9.x-level vulnerability in some Google product, create a CVE, publish it and, in the same vein as Google, do full disclosure within 90 hours and see how Google likes them apples.
Re:90 days, huh? (Score:5, Interesting)
It used to be 30 days. Apple and Microsoft complained because it didn't give enough time to analyze the problem, fix it, test it, and then do a proper rollout to ensure there weren't unexpected side effects in 30 days.
I think what happened was a kernel flaw, meaning a fix could severely impact other subsystems in the OS and thus a fix would need to be carefully done and a properly staged rollout.
The problem isn't the AI tools - Project Zero has real researchers doing real analysis and making sure those AI issues are real. It's likely they're filing issues FFMPEG feels aren't really issues at all.
You might think a bug in a codec used in a 1996 console isn't relevant for security, but if someone can code up an exploit using it, it's suddenly a big deal. I don't have to play back 1996 console video game to hit the bug, I just need to trick someone into getting FFMPEG to see the file as that format and exploit the security hole. (Think sites like YouTube and such that ingest video, for example)
The problem is, there is no right solution. Is it a real security issue? I don't care if it's only for a platform that only only one game released and no one's ever going to practically use it. If it's a way to break into the software and escape my software stack, it's a security issue because all you need is to have someone pretend to be that file. If not, then let the issue be published - even if you don't want to fix it, people who use it might simply be able to disable ingesting that format at all and eliminate the security hole by not having the feature available.
Re: 90 days, huh? (Score:1)
Good luck getting FFmpeg running on a console from 1996!
Actually, at Demuxed 2025 recently, somebody did make a presentation detailing how they got a Sega Genesis (Megadrive) to stream and playback video. What an awesome hack!! Itâ(TM)s here: https://github.com/joeyparrish... [github.com]
Re: (Score:2)
Good luck getting FFmpeg running on a console from 1996!
This has nothing do with running ffmpeg on a console from 1996. wtf are you talking about
Re: (Score:2)
You have a 4 digit UID. How are you this dumb?
Re:90 days, huh? (Score:4, Interesting)
Someone else I saw talking about it did also mention that the codec the bug was in isn't even included by default, it needs to be enabled at compile-time to be available.
So it might not be enough to just code up an exploit, but you'd need the target to be running a version of FFMPEG with the vulnerable codec compiled in.
Re: (Score:3)
A lot of people get an ffmpeg binary from some repo, and they often compile those with all the optional extras.
Either way, it needed to be fixed.
Re: (Score:2)
Except that's the case for many bugs across many pieces of software. That doesn't make the bug less severe, it just makes the likelihood of being affected lower.
It's also one of the cases for depreciating and removing old code, precisely because someone somewhere will be running with it on by default. You say "included by default" and I ask "by whom"? I must have some 20 copies of the FFMPEG libs on my computer with all the different software packages that include them using compiler flags unknown to me and
Re: (Score:3)
If use of ffmpeg in YouTube is the reason for the CVE, did Google send a PR with fix, or just an issue ticket?
Google has resource, so acting as a consumer only might be the problem. If they're send fixes then ffmpeg doesn't have much complaint.
Re: (Score:2)
Think most would rather take the big payday for finding such than go the route you suggested.
Re:90 days, huh? (Score:5, Interesting)
Sounds like they're working on doing exactly that. Chrome, YouTube, Android, and a bunch of other Google stuff seems to use FFMPEG, not to mention any other open source projects they do this to. In 90 days Google might just be saying "hewooo Internet! Here's a vulnerability in most of our software that we didn't even try to fix!"
Fixing CVE Slop? (Score:4, Interesting)
Wait if it is CVE Slop why not just label WONTFIX and move on? Something doesn't add up here.
Re: Fixing CVE Slop? (Score:3)
I think the overall quantity of this sort of thing means you need to fix the issue to avoid further slop. Even if WONTFIX stops Google from re-reporting the bug (a big IF), it won't stop other entities from running the same sorts of checks.
It's an overwhelming rush of stupid niggling details that don't really matter but will ultimately create too much work if it's unaddressed. Like if you have a web app and everyone's complaining about the color scheme, you should fix the color scheme even if it doesn't mat
Re: Fixing CVE Slop? (Score:3)
Adding one more thing: bug reports should require an impact assessment. If the AI properly reports the bug will only impact people running on a video game console from 1995, the maintainers can properly prioritize it as a bug, but one no one should care about. Not WONTFIX exactly, but prioritized last among all issues in the project.
One things that's hurting us I think is this idea that a security problem overrides all other problems. So bad actors are essentially couching feature requests as security probl
Re: (Score:2)
> Adding one more thing: bug reports should require an impact assessment.
Does that also change the public reporting of the bugs? If they're going to publicly report the bug in 90 days, then you probably don't want to low-priority the fix for it - even if it's super-obscure and only affects 1% of possible users who've already done a whole load of very personally specific steps.
Once the public report is made, then the whole landscape of your project changes from "there are some new CVEs" to "it has known b
Re: (Score:2)
Re: Fixing CVE Slop? (Score:2)
*citation needed
How do you know this impacts other users? The ffmpeg software is for the command line. It is not used for opening attachments. For that, you would use a video player that relies on ffmpeg for decoding. Are there actual video players in the wild that would play such a video?
You haven't demonstrated an attack chain for your assumptions, so I'm gonna go with the professional assessment of the ffmpeg team when they say this is not a serious issue. If you have any evidence to the contrary, it wou
Re: Fixing CVE Slop? (Score:2)
It's being reported as a security issue in ffmpeg when it's really a feature request for providing up-to-date support on an essentially non-existent codec. The codec is being provided as a kindness, not as a core feature of the ffmpeg library.
My point is these classifications are difficult to make and the simple heuristic of prioritizing "security" over "features" is deficient.
Re: Fixing CVE Slop? (Score:2)
> Like if you have a web app and everyone's complaining about the color scheme, you should fix the color scheme
How many it is so you think it would take to complain to Slashdot to get a dark theme enabled?
Re: Fixing CVE Slop? (Score:2)
/. is essentially in maintenance mode. You'd likely be better off looking into user stylesheets and see if anyone's already created a theme. Given this audience, there's a good chance.
Re: (Score:1)
Wait if it is CVE Slop why not just label WONTFIX and move on? Something doesn't add up here.
With hundreds of bug reports every day automatically submitted by AI tools, the problem is they already do mark WONTFIX but "moving on" means reading the next submission and having to do the same.
Oh and just because there are hundreds per day, that doesn't mean a legit vulnerability or bug hasn't been found once or twice.
Is it really worth the risk to out-right block google bug reports and find out about the vulnerability once it is in the wild?
What "doesn't add up here" is having to repurpose developer tim
Re: (Score:3, Insightful)
Because someone still has to take time to read the slop. Over and over. That's the kind of thing that makes volunteers go volunteer somewhere else. And this shit is going to snowball; if Google keeps getting away with it so will other companies, then it will be students testing out their AI hacking skills. It’s better to send a public message to Google before the situation gets bad.
Re:Fixing CVE Slop? (Score:5, Funny)
Because someone still has to take time to read the slop. Over and over.
That work sounds like a great candidate to offload onto AI!
Re: (Score:2)
Again, whoever read this "slop" decided that there was sufficient reason to then proceed to fix the bug. Why call it "slop"? If you felt the need to fix something then by definition it provided you with valuable information.
I agree Google should invest more in open source and that AI tools are creating newer and higher workloads, but right now it doesn't look like the work is worthless - based on the actions of the very team complaining about it.
Re: (Score:1)
Re: (Score:2)
Very simple, although it is not a surprise YOU do, again, not get it: It requires most of the work, which is analysis, to find it is slop and slap that WONTFIX on it.
Re: (Score:2)
You of course are a fan of throwing good money after bad? If it was so crap then it wouldn't be a bug worth fixing. Yet it was fixed.
It's not a surprise I don't get the rubbish logic you apply. No one does.
Re: (Score:2)
You won't want to WONTFIX a security issue. But you also don't want to be spammed with issues affecting codecs that are just implemented because you can, not because they are needed.
Isn't this the idea? (Score:5, Insightful)
I'm really torn on this.
Free Software benefits from bug reports - eventually the software gets better. Big corporations don't compensate - which sucks, but is part of the deal when you decide you're writing Free Software. You're not writing to be compensated, you're writing to "scratch an itch".
Can't fix all bugs? Then... Don't. Eventually whoever has most to lose is bound to step up and help. At any rate nobody gets to tell you whether or how fast to fix a big or implement a feature, if you're not on their payroll... that's the flip side that works to the Free Software Dev's advantage.
Bothered by the premature disclosure? Why? A security issue still is a security issue; better to know about it than not, fpr everyone involved.
Re:Isn't this the idea? (Score:4, Insightful)
You're not writing to be compensated, you're writing to "scratch an itch".
True, but with many popular OSS projects, that "itch" becomes a permanent rash (constant demands for features/fixes, unpaid) that drive developers to burnout.
So then there's really only a few choices:
1. close the source, or also use a less permissive license that perhaps requires paid contract for commercial use etc.
2. large companies whose products depend on those projects help fund it, or,
3. dev burns out, leaving the project in limbo (or a bunch of proprietary forks) making it less popular/supported.
Re: Isn't this the idea? (Score:3, Insightful)
Why?
You don't need to treat someone else's itch/rash, just your own. Prioritize and fix bugs by your own criteria, in your own time. You're not "supporting" anyone's product, you're building your own.
Nobody has any kind of hold over you; they either use your product as it is, or they can build their own, it's that simple.
It only becomes complicated once you attach your own pride and self-worth to the existence of a "large user base".
Re: (Score:1)
But thats the entire point - at that point you arent scratching your own itch, you are voluntarily scratching someone elses.
If people stuck to scratching their own itches, we would either have fewer large projects or more involvement from users who are scratching their own itches.
But in the meantime, many OSS projects exist on the following flow:
1. Scratch your own itch, and make the solution public because it might help out others
2. Someone else finds your scratching to be valuable to them, so uses your so
Re: (Score:2)
I think they know exactly how it works. Not being a maintainer is the ultimate version of ignoring requests.
Re: You're obviously not a maintainer of a popular (Score:3)
Bingo.
I "maintain" a number of projects (I outright refuse to write any software that isn't free these days, and as a beamline scientist I write a lot of software, ao inevitable there's lots of F/OSS out there that I wrote).
But I maintain it for a small circle only - essentially my own team and colleagues. If you want requests honored, convince me that it's what I need, wait for me to be interested in your request, or step up.
Re: (Score:2)
As if you need any sort of evidence for something that is this low of a bar. All you need to do is click the fork button on github and you are instantly a maintainer of an OSS project.
Re: (Score:2)
Re: Isn't this the idea? (Score:5, Insightful)
A company like Google could even contribute quality fixes, but by humans. Asking volunteers to solve a problem that the multi-million dollar company is benefiting from is cheap and spiteful, especially if said company provides no value to the project.
Re: Isn't this the idea? (Score:4, Insightful)
Nobody's asking anybody anything. Submitting bug reports (if they're valid and good) isn't asking, it's helping: knowing if and where your software fails is bettet than not knowing, regardless of whether you decide to fix it or not.
Re: (Score:3)
Nobody's asking anybody anything. Submitting bug reports (if they're valid and good) isn't asking, it's helping: knowing if and where your software fails is bettet than not knowing, regardless of whether you decide to fix it or not.
Though if Google is setting "ninety-day countdown to full disclosure regardless", then they are essentially pressuring a group og volunteers to change focus and deal with that problem. That's the spiteful part. If Google cared about the open source it benefits from, they could set aside some devs or even provide some financial help to deal with this,
Re: Isn't this the idea? (Score:5, Insightful)
I think it's established that Google are being dicks, no question about it. But it's easy to pearl off that pressure: ignore it.
Most of "us" are using ffmpeg at home, to convert our home videos and pirates collection. Google OTOH uses it in a world-wide product. Disclosing security bugs before they have a chance to be fixed hurts them way more. Just give them the chance to realize this...
Re:Isn't this the idea? (Score:4, Insightful)
Google appears to have understaken the expense of spinning up an ocean-boiling slop machine to automagically generate plausible bug reports, and then casually fire off an email to the maintainers.
Note that Google has not undertaken the expense of assigning an engineer to also write a fix.
That they are not doing that is a conscious, management-approved choice.
...Y'know how Google relishes in closing bug reports with "WONTFIX - Working as designed?" I think FFmpeg should close slop reports from Google with, "WONTFIX - Unfunded."
Re: Isn't this the idea? (Score:2)
Noe that's something I could stand behind :-) "Your bug report is important to us and very appreciated, please hold. the line"... until some undetermined time in the future that someone either magically has time for it, or haooens to be bugged by the same... bug.
Would also be nice to give.Google their own submission address (bugs.google@ffmpeg.org or so), and tell them to use it for submissions or get blocked altogether - if the frequency with which they submit bugs is clogging everything else.
Re: Isn't this the idea? (Score:2)
Yeah, in this case the people running FFMPEG on a console from 1995 can address the security problem if they think it's needed.
Re: (Score:2)
The issue is with a vulnerability in how ffmpeg decodes a codec from the 90's.
A video file could be encoded today using that vulnerable codec in order to exploit the vulnerability in ffmpeg
Re: (Score:2)
So why wait at all just release the bugs you found. So if you find a vulnerability in Chrome don't even bother sending an email to Google. Eventually Google will find out and fix the bug. /s
Re: (Score:2)
Pwn2Own.
You stockpile a bunch of zero days for a hacking contest.
Let alone the baddies...
Re: Isn't this the idea? (Score:2)
I understand that "responsible disclosure" is a thing. I a perfect world, releasing the fix before disclosing the bugs prevents script kiddies from using the bug for evil purposes.
Also it's a pressure device when you do it to a commercial product - someone has a reputation to lose, so maybe they'll at least consider fixing.
But these considerations go out the window when you're being a dick about it and doing it to a non-funded volunteer. Ans conversely, the volunteer can go ahead and not give a flyng about
Re:Isn't this the idea? (Score:4)
Only the legitimate and quality ones.
The author of curl [github.com] has been receiving a variety of reports that were generated by AI, none of which are legitimate. The latest one seems to involve a function that doesn't exist within curl, meaning he spent time tracking down a bug that didn't exist.
As for the Free and/or Open Source Software paradigm - it requires both "many eyes" and "many hands". Being able to spot problems doesn't mean a thing if there's nobody able to fix these problems.
Re: Isn't this the idea? (Score:2)
IIRC the curl problem was different, bugs reported weren't any true bugs - just adly researched corner cases.
Is it established that this was thw case here, too? The way I understood the poat wasn't "stop because your bug reports are crappy", it was "stop because we don't have time to.fix them".
Yes, "many hands" would be nice, but it is what it is - you have as many helpers as.you have and none more. Google here being an unpaid "volunteer", too (notwithstanding them also being dicks), they can choose where
Re: (Score:3)
Only the legitimate and quality ones. The author of curl [github.com] has been receiving a variety of reports that were generated by AI, none of which are legitimate.
That's a strawman argument. We're not talking about Curl. Curl's dev's took a different approach to what was going on and specifically determined they aren't legitimate and took no action. On the other hand FFMPEG devs looked at it and ... fixed the bugs.
So by what metric do you determine that this isn't legitimate and quality? The FFMPEG devs seemingly deemed it worth their time to take action after analysing the case.
Re: (Score:3)
Eventually whoever has most to lose is bound to step up and help.
That, or your project gets sidelined. Which is where the danger lies.
I work for a big multinational software company that uses a lot of Open Source Software. We have a security office that audits all of our products several times a year. If any piece of our stack shows any open CVEs we have a fixed amount of time to fix the issue, with the amount of time varying from a few days (for CRITICAL severity issues) to roughly half a year for the lowest severity issues. A lack of a fix for a published CVE isn
Re: (Score:2, Insightful)
If ffmpeg allows known and published vulnerabilities to languish, the risk here is that organizations that use their code will simply stop using it and will look for other solutions.
Orgs basically have a choice:
1. Suck it up and deal with the whims of people you are not paying a penny to
2. Cough up some cash and contribute
3. Develop their own completely in house/pay for a 3rd party one
2 is almost always way cheaper than 3. Option 4 of "whine incessantly that people you aren't paying aren't working for you f
Re: (Score:2)
Look — I’m a developer. I get it. I’m personally all for having organizations do more to support the OSS they rely on. But the people in the C-suite are more worried about organizational reputation and losing money to lawsuits. If a piece of software they rely on has a known critical CVE that allows for remote code execution and someone breaks in and steals customer data — that software either needs to be fixed, or it needs to be scrapped. Those are the choices. Our customers i
Re: (Score:2)
If ffmpeg allows known and published vulnerabilities to languish, the risk here is that organizations that use their code will simply stop using it and will look for other solutions.
Oh noes! In order to avoid spending a little bit of money to help ffmpeg maintain a quality codebase, they'll instead spend a *lot* more money switching to something else... and still be faced with the same "maintenance isn't free" problem when they continue to freeload off of someone else's work.
(And that's putting aside the basic problem that there isn't really "something else" that itself isn't built on top off ffmpeg, which drives up the costs of switching even more. Of course, there may be commercial
Re: (Score:2)
Google, Microsoft, Apple, Facebook, Amazon, or another one of the big software development companies could easily fork ffmpeg itself, fix the open CVEs, provide their own (likely incompatible) features, and become the new standard - leaving the original developers out in the cold. Google did this with Blink (forked from WebKit, which itself was forked from KHTML). They took a fork of a KDE backed project, put it into what is now the #1 browser in the world, allowed Microsoft, Opera, and others to then use
Re: Isn't this the idea? (Score:2)
organizations that use their code will simply stop using it and will look for other solutions.
...which are somehow going to be cheaper / easier to.maintain because, why exactly?
Re: (Score:2)
The problem is to discover whether it is AI slop or a real issue, you have to do 90% of the work anyways. Google is essentially doing a DoS attack on FFmpeg by delivering unvetted and often low-quality reports. Yes, that means the Google people behind this are _really_ dumb.
Re: Isn't this the idea? (Score:2)
Re: (Score:2)
No, they are dumb. Because it is obvious that this approach cannot work.
Re: Isn't this the idea? (Score:2)
True enough and I agree. But again, is this the core of ffmpeg's complaint? That they receive AI slop from google?
I thought the critique was focused around the volume of bugs, bot the legitimacy.
Re: (Score:2)
I thought the critique was focused around the volume of bugs, bot the legitimacy.
Unless you think FFmpeg has tons of legitimate security problems, the volume implies the slop being in there.
Good for FFmpeg - Shame on Google, Apple, Amazon (Score:1)
Re: (Score:2)
Re: (Score:2)
Like all other enterprises, Google is happy to take from the commons, but will not contribute unless publicly called out on it. As is happening here.
Change your licensing model (Score:2)
You can offer a fix fee for smaller businesses and an individually negotiated annual licenses for majors like Google.
I’m in my second year of running like this, and the extra income has enabled me to invest a lot more time into the project, than I otherwis
Re: (Score:1)
Agreed. There's no reason to just give your work away to people who can't even be bothered to open source their changes. That's great that you're able to make an actual income stream out of that.
FYI, your "Homepage" link goes to a 404.
If it's a real bug ... (Score:2)
Re: (Score:2)
Short term, ffmpeg is receiving bug reports, but not patches to repair them or the funding so ffmpeg contributors must fix it on their own time and effort.
Medium term, these codecs see so little use that the attack surface is very small. If it didn't go against ffmpeg's standards, removing the codecs might be more viable. Maybe they could be put behind some kind of "are you sure?" warning with an explanation as to why, and note that uses of these codecs are rare and users should already know if they need th
The problem (Score:2)
So even if there is a real bug somewhere in this crap, I won't see it or probably won't recognize it even if I do read it. Even if I do realize that it might really be a bug, figuring out what is
Re: (Score:2)
Simple: If it is slop and irrelevant, it still takes almost as much time to work on as a bug with high relevance. Google is overloading the projects engineering capabilities.
Corporate policy (Score:2)
Google could create a new corporate policy to provide a minimum of $1M/year to any open source project it uses.
That would be real innovation.
The effect on Google's bottom line would be completely negligible, not even a rounding error on a rounding error.
If $1M is more than necessary, make it $100K, or whatever is appropriate, but substantial. Fund at least be definitely on every project it uses.
Invite its peers to do the same.
Re: (Score:2)
While acknowledging your noble intentions, no, it wouldn't be innovation. It would be cheaping out.
In the San Francisco bay area, $1.0E+06/year gets you maybe five skilled engineers. Set against the quantity of Open Source projects used by such organizations -- FFmpeg, GStreamer, OpenSSL, ssh, rsync, gcc, gdb, coreutils, nanopb, Samba, Lua, Python, Perl, Git, Vim
Re: (Score:2)
...This is my embarrassed face.
I had previously assumed you were speaking of allocating $1M across all projects used by Google. In fact, you were speaking of giving $1M to each such project.
One would wonder what sorts of strings would be attached to such largesse. Still, that would indeed be game-changing and amazing.
Re: (Score:2)
Yes, I was. Thanks for acknowledging your error.
You do raise an interesting point. Under my plan, the strings would be that you work on whatever was funded. A think a monthly report indicating what got done would be reasonable. That's about.
If you wanted to be more robust, maybe one string would be that a percentage of time would be spent on different project areas, such as bug fixes, new features, documentation or whatever. I can see that.
Other than that, not sure, I could see a temptation to want to dir
Re: (Score:2)
I picked a random number. Pick a different one that you like better.
If AI can find and report the bug... (Score:4, Insightful)
then surely AI can also include the fix...
Re: (Score:2)
Irony or exceptionally naive statement? Difficult to say...
Re: (Score:2)
Without compensation? (Score:1, Troll)
Why does he need compensation? People don't pay for music, or movies, or software, why should he be any different and get paid for the work he did?
As (Score:5, Informative)
Not even close. 90% C, 8% assembly, at least according to GitHub [github.com].
Fuck MongoDB (Score:5, Insightful)
Re: (Score:3)
The filter that was working no longer does
Re: (Score:2)
The name of that attribute has changed. If you update your filter to match (easy enough to find w/ uBO), the pop-up will go away.
I'm expecting a lot of cat-and-mouse on this site over the next few weeks / months.
Re: (Score:2)
In Firefox with uBlock extension right-click on the pop-up and select "Block Element" and then "Create".
Re: (Score:2)
Re: (Score:3)
I wonder if it's possible to write a uBO filter rule that replaces that ad with this video [youtu.be]?
Re: (Score:2)
I paid and still have a Disable Advertising button in Slashdot and this is YET ANOTHER time that that prior purchase is not being honoured.
Re: (Score:2)
I've been using this Chrome extension to remove annoying things like this from websites:
Click to Remove Element [google.com]
Security? Disable the codec at build time. (Score:1)
ffmpeg (Score:1)
Re: (Score:2)
All that would happen is that the companies would take the last version, continue using that in privately-patched versions that they never distribute (they don't need to, they only need to provide source if they're providing binaries and YouTube et al don't give you their binaries), and wait for someone else to start up a fork.
Additionally, they can't. If they change the licence, they can't build on what's already there as its GPL. It's literally in the design of the licence that they deliberately chose.
The problem is ultimately this: (Score:2)
It's pushing FOSS away from the people and in to the hands of a chosen few. While I admit security flaws are a problem; I think a pragmatic approach is still better than blind realism. It's like the flaw might be rated 9.9; but you need physical access to the motherboard and remove 3 chips to make it happen....that's not a realistic security threat to most people.
If this continues, who will want to contribute to anything? If I write a project only to have a company with billions of dollars start picking it
Maybe just convert all the code to Rust (Score:2)
People either can't - or don't - read (Score:3)
I'm going to break this down for everyone since there seems to be a distinct lack of comprehenhsion in the comments section.
1) This bug has nothing to do with playing videos on a console and it instead has to do with playing extracted video from a console, specifically - extracted video from Star Wars Rebel Assault 2 - a computer/Playstation (1) game from 1995/96.
2) There is a bit of custom code designed specifically around this little used codec to account for video artifacting in the first handful of frames. Let's call a spade a spade - it's a custom filter built right into the FFmpeg code.
3) It's a use-after-free (UAF) exploit - which can lead to remote code execution.
4) Triggering this bug doesn't require someone to actually trick the user into watching the videos from Rebel Assult 2 - merely embedding enough into your file that FFmpeg will execute that code path. I'm not versed enough to list out the different containers FFmpeg might be convinced to run this code against, but having watched it chew through mislabeled files before I assume it's more than one.
5) I don't disagree with the project maintainers that companies that have a stake in open-source software should contribute towards its maintenance.
6) I do disagree with them about this being "CVE slop". AI is an arms race. If Google is using AI to detect and contribute bugs, there's no reason to think that hacker groups aren't using the exact same tools searching for exploitable bugs and not reporting them. It's very much like mining bitcoin - someone is going to find that next address. Do you want the hat to be black or white?