After apt install krusader, I ran suggested apt install okteta. As part of its dependency tree, I saw many opaque dependency names, including libkf5newstuffcore5 which sounded vibe coded could be more meaningfully named.
It’s a six year old KDE project that provides download capabilities.
I’ll pass on the hex editor that downloads things, but I’ll suggest that “downloader” is better than “newstuff”. How do users and developers feel about this set of name changes?
That wouldn’t really be less confusing, though; the store-like functionality that KNewStuff provides is certainly not what i would think of when hreading KDownloader. It’s also an implementation detail; The user does not need to know or care what the library providing this functionality is called.
The existing package names are one of only two unpolished things I’ve found since I began using KDE6 in January. They sound like they’re from a project that’s accidentally releasing its developer branches.
libkf5newstuffcore5 sounds benign (i assumed “the latest kf5 features”) libkf5downloader makes it clear that it’s an attack surface.
I am not willing to introduce a new attack surface to my file manager by letting its plugin download things. I had 32 total dependencies to audit for okteta and I didn’t start with this one. With a name saying explaining what it does, I could have stopped as soon as I scanned the dependency list, and saved a bunch of time.
is not installed on my system, but most of the *newstuff* comes as part of the default install.
so it’s not really introducing a new attack surface because it’s kind of already backed in… what distro are you using that it not part of the initial install?
i’m still not seeing the issue here or why this proposed change is needed.
my feedback, is that it doesn’t need to be changed.
So the QT6 version was preinstalled with debian 13, and the okteta package was asking for the QT5 version.
It’s literally telling the user it’s got unvetted executable code. Exactly why I wanted to avoid it. I may have expected too much from KDE’s security posture
Depends on the usage, i.e. what type of asset is being supported by the respective application.
I think global themes are partially support running shell script to adjust settings and copy files.
Could probably be reimplemented with some contained scripting API in a future version that can drop compatibility.
For Okteta it seems to be used to download files containing definitions of binary structures.
No worries, all of this requires the user to explicitly trigger the download/installation.
And it only adds support for community provided assets/extensions on top of what comes from either KDE or the distributor.
what it is telling you is that you are venturing into 3rd party code and to use at your own risk… just like all the add-ons you need to add to gnome or cinnamon in order to get them any where close to what plasma offers out of the box.
having the code on your system to ACCESS this 3rd party content is no more of a security risk than you make it… if you don’t want the risk than close that window and keep the default themes that come with plasma when you installed it (breeze works just fine) .
You’re looking at a developer-facing library; it’s not uncommon for these to have weird names. For example, a Rust integration tool for CMake is named corrosion, which isn’t about tarnishing metal. poke-elf has nothing to do with fantasy literature. And what on earth is golang-github-hydrogen18-stalecucumber-dev? dummydroid? dustmite? ontospy? curseofwar? hearse?
Debian’s repos are full of funky-named packages; I wouldn’t recommend reading too much into them. These aren’t really meant to be user-facing — at least not user-facing for the kind of user who reads a lot into package names!
