I’ve had this reply from @cscs floating around in my mind for a while now, is it at all possible for anybody here to explain to me what exactly that’s supposed to mean; I get that packagekit is weird at times but what do you guys think about pretty much every distro using it?
With the disclaimer that I’ve never used packagekit, it is my understanding that it isn’t necessarily a bad or insecure thing in and of itself, but rather that Arch’s implementation of it is set up insecurely, and given that Manjaro takes over most of its packages from Arch without modification, this thus means that it would be equally insecure when used in Manjaro.
3 Likes
Warning: PackageKit opens up system permissions by default, and is otherwise not recommended for general usage. See FS#50459 and FS#57943.
4 Likes
I’ve read it and it seems like it’s just more of a burden for normal Arch then a security vulnerability, that still makes it so Manjaro probably shouldn’t bother with it as it may indirectly mess with something… I’ll not mark solved yet for any possible additional contribution.
That you can install software without a password is considered a security concern.
(regular user can make system package changes without a password challenge so long as they are in the wheel group)
Similarly no output means no warnings, no pacnew prompts, and probably means pacman hooks wont fire.
This can be filed as a security concern as well, though not technically a vulnerability itself.
Whether you place a premium on this kind of a security may be opinionated, but the technical aspects are still fundamentally flawed on an ALPM system.
5 Likes
KDE Plasma has its own graphical software manager called Discover which can be used on Fedora, Ubuntu… to install, remove and upgrade the whole system with its apps. It uses packagekit as an abstraction layer to interact with different package managers like apt, dnf, yum, pacman… It’s also used by GNOME software on different distributions.
The real problem is coming from Arch devs who refuse to fix packagekit backend for their system. They really hate the idea of giving users any way to manage update/install/remove their systems using graphical interfaces, while it’s used for years by other distributions.
I know that.
The problem is that packagekit is buggy in general, and unsecure by nature.
This has nothing to do with arch or pacman.
packagekit allows package addition and removal without any security prompt.
Furthermore it hides/disables/disregards what is considered crucial output from pacman. These being important warnings, pacnews, etc - such that changes that must be made prior to a reboot could be missed, for example.
These are all already outlined in various bug reports and the like.
If you want to use packagekit … I guess you can … but it is not good advice, and it should not be present by default on new installations.
1 Like
The age of waiting on screen to press yes and no then merge conflicting packages and files is gone and become not tolerated at all. The nature of current businesses cannot allow paid employees to waste times managing their systems instead of working.
Most distributions used by companies schedule upgrades at night or weekend, and the whole operation is done automatically.
OK … so …
Your argument is … skipping everything else … and going straight for
“in corporate environments automated untended updates are desirable”
??
That neither addresses the fundamental issues here, nor is it directly related to the issue at hand … in what world is packagekit the only way to achieve what you describe? And at what point were we talking about manjaro-rolling-ISOs being catered specifically for such deployments? …
I really dont understand your point.
1 Like
My point is that packagekit is not the issue but Arch.
Then you are mistaken.
(And how is that point furthered by your ‘in corporate…’? It isnt. Make it make sense please.)
1 Like
What I wanted to bring to table is that Manjaro is doomed by following the Arch’s way, it cannot be deployed by any company as daily driver due to its unsafe upgrades’ nature. Unlike Ubuntu or Fedora where most upgrades conflicts are automatically solved.
Steam Deck solved the issue by relying on immutable releases which are now also tested by Manjaro. So maybe it’s the correct way to break that chaotic dependency.
I think you are still mistaken.
“Automatic upgrades” “resolved automatically” is the antithesis of safe upgrades.
The entire premise of pacman for example is to not clobber your configs with new upstream defaults - they are presented but not forced - and this is the ONLY way you are going to get 100% safe upgrades.
If you dont like that I have no idea why you ever considered an Arch-based linux for your own use.
And, again, I must stress - this has absolutely nothing to do with the dumpster fire that is packagekit.
If you really want untended upgrades you can do that. And it certainly does not require some GUI abstraction layer breaking privileges in order to do it.
3 Likes