Say what you like about the random word sequence generation machine, but it does actually seem to be usefully good at generating sequences of random words that correspond to problems in your software.
The purpose of this is to address a practice common in certain open source ideologies of banning all AI contributions - including vulnerability reports. Basically they are choosing to ignore security vulnerabilities because they had to read too much slop last year.
You can do this by vibe coding extensions, and it appears many people are doing this. Ironically this probably makes GNOME the easiest DE to customize at this point.
KDE cannot be modified by extensions in the same way GNOME can. This is a fact. The problem is the extension needed to be written. They are trivial to vibe now. You can make them do whatever you want.
Yes, you can do some light scripting or create your own plugins for specific apps (krunner). This is not near what you get with gnome extensions, which allow you to essentially execute arbitrary code in the shell’s main process.
The shell got a lot of hate for being written in gjs, but you won’t get that kind of functionality from a shell written in a compiled language.
Not really. That would require re-compiling, ensuring binary compatibility with the rest of the system, etc. GNOME extensions are just scripts injected into the main process.
I feel like you are being intentionally dense. Show me some examples of customized KDE builds, at the source level. You don’t even have to look to find 100s probably 1000s of gnome extensions. They are not the same.
It's the opposite, I'm at the level of your aspiratons for vibe coding while you're ignoring the basics.
First, you should subtract from those "100s probably 1000s" what's possible via the identical KDE mechanism that you were aware of in the other comment ("some light scripting or create your own plugins").
Then once you get to a less-obviously-wrong number you should think about the all the vibe coding that resulted in nothing useful, also a very common pastime nowadays, and not count those towards achieving the goal of "easiest DE to customize"
Think think about whether there might be other factors besides "ease" that could lead to the difference. Like, maybe the base KDE is already more customizable, so you wouldn't need to vibe code any custom builds to achieve the same.
They should be using an automated AI agent to validate vulnerability reports. Have it pull up the code base, confirm the bug exists, try to reproduce, then update the ticket. You might even run another AI agent pass to clean up the text before humans look at it. AI writing quality improves a lot with multiple passes.
"Vibe reviewing" is an underrated way of dealing with vibe coded PRs. There's going to be a lot of low-quality noise that's probably better to just close without a human looking at it, but it would be unfortunate to ignore the stuff that might be worthwhile because of that.
I’d posit that well over half of tokens spent should go not just to write new code/software alone, but in review, testing, as well as tooling. Every bit of code an agent writes should at the very least have an adversarial review loop.
my rebuttal to his point is that AI generated code does not essentially have to be low quality. And it very well mean higher quality code if supervised properly
> GNOME is primarily written using unsafe programming languages where simple mistakes in our code lead to devastating consequences for our users, and we make these mistakes all the time. No matter how much we try, GNOME developers will fail write secure code when using unsafe languages like C, C++, or Vala: it’s just too hard for even experienced developers to do properly.
Once I saw that I knew that this article was a ridiculous stack of bullshit.
Gnome might have some bugs and shortcomings but now millions desktops are using Gnome based window manager for decade and the world didn't collapse yet.
And let's not forget the ridiculous assumption that you can't handle a software quality without using AI...
This remind me of OpenBSD's code. Not saying there isn't any bugs there, but the risk is mitigated by writing simple and clean code. They do not rush to add the latest ideas and wishes to the codebase.
What was good enough in the past may not be good enough now. In the past these overflow defects were as hard for attackers to find as they were for developers, because they had the same tools available.
Now we have LLMs, and they can apparently find all sorts of problems that, for whatever reason, weren’t being found with manual review, static analysis and fuzzing. We have to assume that hackers will use the technology to find vulnerabilities. If maintainers don’t do the same, then they are ceding an advantage and leaving their users unnecessarily exposed.
I don’t know that I completely agree with the above. (For example, I don’t know how scrupulous GNOME has been in the past about non-AI tools for automated defect discovery, or how well they compare to AI.) But it at least feels like a much more charitable interpretation of the article’s main thrust.
It remains viable as long as frontier models remain subsidized, too. How long will it take before these providers have to raise the prices to such a degree that such attacks would be reduced to only the most determined, financially capable attackers?
And even then there is the risk that the frontier model providers collapse. There’s no indication yet that these companies are going to become profitable. And open source models simply piggy back on frontier ones and are generally not powerful enough for this level of adversarial attacks as far as I know.
And finally are LLMs the only method to hardening software? There is still a lot left on the table that could still allow a project to resist attacks from a frontier model.
Sure, humans are bad at catching this stuff. But in order to drive an LLM you have to be able to catch this stuff. Otherwise your only option is to trust the model and give up.
To the point about LLMs being the only method to harden software - that's why I'm not sure I'm convinced by the argument. The article says the bulk of the defects were integer overflow bugs. This is out of my league a bit, but that feels like the kind of thing that should be detectable with static analysis, possibly both less expensively and more reliably than with LLMs.
Perhaps using static analysis generates false positives in cases where the code can't be proven safe? But when I was working on a project where we used Sonarqube, we ended up deciding as a team that we'd prefer changing the code to eliminate false positives over "wontfix"ing them, and I was happy with that decision. It led to more regular coding practices that ultimately made the codebase easier to read and understand. For largely the same reasons as Dijkstra was getting at in "Go To Statement Considered Harmful."
I think your expectations may be a little out of date. Existing models, including open weight models you can run yourself, are already quite incredible at finding defects. Even if the technology never gets better (it will) we are already at the point were LLM-wielding attackers have a dramatic advantage over non-LLM-wielding defenders.
There is no excuse for not having an LLM look for flaws in your codebase. Your attackers are using them already.
44 comments
[ 0.21 ms ] story [ 11.5 ms ] threadReally? While other projects rewrite things in memory-safe ways, GNOME's response is to ask a chatbox if there are any memory vulnerabilities?
It's not even false, you do know that KDE exists
I was pretty sure that was false. I did a quick check and found
https://develop.kde.org/docs/plasma/scripting/
https://develop.kde.org/docs/plasma/kwin/
https://develop.kde.org/docs/plasma/krunner/
The shell got a lot of hate for being written in gjs, but you won’t get that kind of functionality from a shell written in a compiled language.
First, you should subtract from those "100s probably 1000s" what's possible via the identical KDE mechanism that you were aware of in the other comment ("some light scripting or create your own plugins").
Then once you get to a less-obviously-wrong number you should think about the all the vibe coding that resulted in nothing useful, also a very common pastime nowadays, and not count those towards achieving the goal of "easiest DE to customize"
Think think about whether there might be other factors besides "ease" that could lead to the difference. Like, maybe the base KDE is already more customizable, so you wouldn't need to vibe code any custom builds to achieve the same.
Basically, just take to heart your own
> They are not the same
...only dig just a bit deeper
But let that not waste the opportunity to promote AI.
Once I saw that I knew that this article was a ridiculous stack of bullshit. Gnome might have some bugs and shortcomings but now millions desktops are using Gnome based window manager for decade and the world didn't collapse yet.
And let's not forget the ridiculous assumption that you can't handle a software quality without using AI...
What was good enough in the past may not be good enough now. In the past these overflow defects were as hard for attackers to find as they were for developers, because they had the same tools available.
Now we have LLMs, and they can apparently find all sorts of problems that, for whatever reason, weren’t being found with manual review, static analysis and fuzzing. We have to assume that hackers will use the technology to find vulnerabilities. If maintainers don’t do the same, then they are ceding an advantage and leaving their users unnecessarily exposed.
I don’t know that I completely agree with the above. (For example, I don’t know how scrupulous GNOME has been in the past about non-AI tools for automated defect discovery, or how well they compare to AI.) But it at least feels like a much more charitable interpretation of the article’s main thrust.
And even then there is the risk that the frontier model providers collapse. There’s no indication yet that these companies are going to become profitable. And open source models simply piggy back on frontier ones and are generally not powerful enough for this level of adversarial attacks as far as I know.
And finally are LLMs the only method to hardening software? There is still a lot left on the table that could still allow a project to resist attacks from a frontier model.
Sure, humans are bad at catching this stuff. But in order to drive an LLM you have to be able to catch this stuff. Otherwise your only option is to trust the model and give up.
For example: https://link.springer.com/article/10.1186/s42400-020-00058-2
Perhaps using static analysis generates false positives in cases where the code can't be proven safe? But when I was working on a project where we used Sonarqube, we ended up deciding as a team that we'd prefer changing the code to eliminate false positives over "wontfix"ing them, and I was happy with that decision. It led to more regular coding practices that ultimately made the codebase easier to read and understand. For largely the same reasons as Dijkstra was getting at in "Go To Statement Considered Harmful."
There is no excuse for not having an LLM look for flaws in your codebase. Your attackers are using them already.