depends on policykit-1-gnome, which is unmaintained #10172
Comments
|
@mtwebster @clefebvre why built-in polkit agent was removed? |
|
I suppose this must be a problem with xfce4-session too. My only thought on the topic is, it is depressing that gnome continually abandons reusable components in favor of reimplementing features in non-reusable ways inside of gnome-shell or other leaf applications. |
The xfce4-session in Debian doesn't have that dependency, so this could either be a bug in the Debian packaging (not having a dependency that it should) or in the Arch packaging (having a dependency that it doesn't need). I don't use XFCE, so I don't know who is correct here. (I don't use Cinnamon either, but it's reasonably obvious from the packaging and code that Cinnamon does rely on the polkit agent formerly used in GNOME.)
GNOME Shell and its equivalents like Cinnamon aren't really leaf applications - they're the desktop shell that presents UI for desktop-level and system-level things. |
I don't see how this technicality affects my statement. I added "or other leaf applications" after the fact as a token reference to packages found in a software "start menu" listing, which also display the same problems gnome-shell itself does. Maybe I should have said "packages" or "and generally with leaf applications" to make my point clearer. |
|
I'm not sure why the polkit agent was removed but I don't see any valid reason for it than "this existed so we didn't want to maintain it" When I find the commit I'll make a PR to revert it, and see if I need to backport anything from GNOME |
|
Actually, it isn't used at all. to the best of what I can see and my knowledge. I'm not 100% sure, and I've done a basic grep search but I'll have to run a few tests to see if it actually calls anything but I don't think it does. Nothing related to polkit, policykit, or polkitagent to the best of my knowledge isn't used at all. It's just an empty dependency and can also be removed from the meson.build file. |
|
Are we talking about polkit-gnome or the polkit-agent libraries? I'm pretty sure the current state of affairs is that cinnamon doesn't contain any polkit code, but has a package level dependency on an external program that provides the right dbus interface to pop up a dialog box whenever polkit requests occur. That's all this ticket is about, not any potential and completely unrelated pkg-config dependencies that are being searched for and linked into cinnamon despite beer being used (and not, in fact, being linked into cinnamon if you build with |
|
@ItzSwirlz pkexec command needs a polkit dialog. |
|
It's not just pkexec: any system service that wants to do privileged actions in a controlled way using polkit (for example udisks, NetworkManager, systemd, firewalld, gdebi, flatpak --system) is going to need some sort of polkit agent to do the prompting/UI, either built-in to the desktop shell (as seen in GNOME Shell, GNOME Flashback, Phosh) or as a separate executable that is launched during desktop startup (as seen in Debian packages lxpolkit, lxqt-policykit, policykit-1-gnome, ukui-polkit, mate-polkit, polkit-kde-agent-1). I think it certainly makes sense to include a polkit agent in "the Cinnamon desktop" (the overall system equivalent to the GNOME desktop), either built-in or as a dependency. Whether it's in cinnamon the program (the equivalent of gnome-shell) is a design question for its maintainers. If it's an external program, it will probably need to do careful things with X11 grabs to stop unrelated X11 apps from stealing focus and receiving your password, and it will probably be harder to present a UI where users can be confident that they're really interacting with "the desktop" and not some program that is imitating it. The library dependency on polkit-agent-1 in Cinnamon does seem to be unused, at the moment. If Cinnamon gets a built-in polkit agent like the one in GNOME Shell, then the library dependency on polkit-agent-1 will be used again, to help to implement that; or if it uses an external polkit agent like policykit-1-gnome, it's the external polkit agent that will depend on the polkit-agent-1 library. |
|
From a fast look seems better readd integrated polkit agent rebasing it on the gnome-shell code. |
|
On the Debian bug mail, mate-polkit was brought up. However, it may not be as stable. If mate-polkit is stable and healthy upstream, using it would be great FOSSwise, but still we are kind of slightly behind GNOME and are kind of our own GNOME shell, not a completely different fork and DE in our own non-JS word (like MATE) |
The C code you linked is not all of it: that's just infrastructure. If the intention is to have a polkit agent built into Cinnamon (similar to how GNOME does it), you'll also need to bring back the UI. It's |
|
Yeah, I listed that as part of the tasks. I also realized that the same commit got rid of something else at a similar time-the network agent. Noting this here in case a similar situation may arise Polkit js files gone here: 72b406c#diff-243027502bd084c987c5e544e6380d6e36c51517aea1b0747fe8a3444d8e75d7 |
seriously? We need a different agent in every single DE? Why? |
Because UI really. Since this won't include a fallback mode, @mtwebster suggested maintaining policykit-1-gnome but I think if he wants to do that, it's better to switch to mate-polkit. MATE is pretty popular and I'm sure the polkit will stay around for a while. |
|
Cinnamon and Xfce are not going to piggy back and use MATE components, there's no way you'll see inter-DE dependencies like this. If we need to maintain this it's either the original or as part of a cross DE projects such as Xapp. Regarding UI, we've no need to theme the dialogs in Cinnamon, that's the only thing the Cinnamon was bringing really and that's why it was removed. |
Actually, mate-polkit doesn't need a mate component/tool for a dependency. It needs just gtk according to the imports in the code. But okay.
I guess it is original then, unless the Xfce team is happy with an Xapp. |
|
Mate-polkit is even older the than polkit-gnome, fedora will continue to use polkit-gnome. @smcv Why do you think it's better to use the code from gnome-shell?, it looks just as unmaintained as polkit-gnome. https://github.com/GNOME/gnome-shell/commits/master/src/shell-polkit-authentication-agent.c |
|
Yeah, they are all not maintained as well. The only thing I see left to do then is just to be the maintainers/pickup for policykit-1-gnome. It's something all distros have maintained together. |
|
Clearly, the code from gnome-shell is better maintained because it is stored inside of a git repo that isn't marked as archived. /s Isn't that the traditional playbook of gnome-shell? Stop maintaining cleanly separated components in favor of something included directly into gnome-shell itself, which is also unmaintained but has better PR because shoving everything into one repo confers maintenance by association. |
mate-polkit is a MATE component.
The XAPP project is cross-DE by definition, it's its mission, it's dedicated to supporting multiple DEs. There's no reason for DEs to inter-depend on each other or to fork every little component out there into their own local version thanks to cross-DE projects like this one. GNOME is an exception to this because historically it developed everything before anyone else needed it.
This to me is crazy. Imagine adding cinnamon-polkit and xfce-polkit to the list, both doing the EXACT same as all the other ones. Unless we're looking for a specific look here (and even this could be done for each DE as part of a cross-DE effort) there's no need to duplicate this. You're talking about security and maintenance, are there any security issues with gnome-polkit? And if so, are they fixed in all these little forks? Personally I'd recommend to continue to depend on gnome-polkit until there's an actual real problem with it. The day it gets forked it needs to be cross-DE. |
Will let you know if Cinnamon and Xfce get in trouble in Debian like they did with cjs later (probably won't for a while but I'll keep an eye on it) Otherwise, yeah. A cross-DE is what we should probably use. Hopefully there can only be exceptions in terms of having their own polkits and instead for all, have one for Gtk branch DE's. |
It is nothing like the mozjs52/cjs issue, debian will be able to support pokit-gnome for many years. |
I am not currently aware of any security issues or other serious problems in PolicyKit-gnome: this isn't about whether serious problems are known now, but rather about what would happen if a serious problem is discovered in future. The thing I'm concerned about is that if someone discovers a serious problem next week or next month or next year, it will definitely not be fixed in PolicyKit-gnome (regardless of how serious it might be), because PolicyKit-gnome is archived and has no upstream maintainer. At that point, Cinnamon's only options would be to fork PolicyKit-gnome and fix the fork, or leave the problem unfixed in Cinnamon environments (or switch to some unrelated polkit agent, but long-term-stable distributions are unlikely to do that). The polkit-related C code in gnome-shell is just glue to connect polkit to the Shell UI (the JavaScript part) and I'm not surprised it doesn't (need to) change often. The JavaScript code in the UI gets more commits than the C code.
That's not really true. Maybe it hasn't needed changes for a long time, but if a serious bug is discovered in GNOME Shell's polkit agent, it's the GNOME Shell maintainers who have taken responsibility for fixing it. At the moment, there is nobody who has the equivalent responsibility for the polkit agent used in Cinnamon, and that makes distributors uneasy. One advantage of integrating the polkit agent into the "chrome" of the desktop compositor (as seen in GNOME Shell, and the equivalent hybrid JS/C agent that was removed from Cinnamon a while ago and reinstated in #10177) is that the compositor has total control over where focus and input go, so an integrated polkit agent is probably less likely to be affected by focus-stealing (your password going to an unrelated application that popped up a window at exactly the wrong time) or impersonation (an unrelated application making itself look exactly like the polkit agent so that you'll type your password into it); so if I was implementing a polkit agent myself, I'd probably be including it in the desktop shell too. However, I'm not a Cinnamon developer (or a Cinnamon user, or a UI designer) and my design decisions are not the same as yours. If Cinnamon developers are confident that they can avoid that sort of issue for a polkit agent that is implemented as a separate process (the same overall design as PolicyKit-gnome, mate-polkit, etc.) then that's your call. If Cinnamon developers have plans to move from X11 to Wayland in future, then that might have an effect on this design decision.
To a point yes, but this assumes that there is someone in Debian who wants to take responsibility for maintaining polkit-gnome for the benefit of Cinnamon and maybe XFCE. The maintainers of Cinnamon in Debian would be an obvious candidate to do that, but the main maintainer of Cinnamon in Debian is no longer using Cinnamon, so other people who find Cinnamon important to them need to pick up the responsibility for Cinnamon's Debian packaging and maintenance (preferably people who can "agree to differ" while cooperating with other GTK-based desktop environments on shared components, rather than complaining that the other desktop environment is not behaving the way they would prefer). A software ecosystem that relies on people continuing to be responsible for components that they no longer use and no longer want to use is not sustainable. I am not a Cinnamon user myself, but I opened this issue to try to help Cinnamon by alerting you to a potential future problem that you might not have previously been aware of. If this attempt to help is unwelcome, I can unsubscribe and go away, but I don't think it really benefits anyone for desktop environments to discourage other desktop environments' contributors from communicating. |
|
Thanks @smcv. I don't want to be the maintainer for policykit-1-gnome and I don't think anyone else wants to in any other distros. Eventually i will be the same goal as libdbus-glib-1-dev: get rid of it. I don't want to be hanging on to deprecated stuff, regardless of there are any security flaws in it or not. Clearly the best option to get the best for Cinnamon stability (as mentioned in the PR) and probably everything else is to fork and create a new cross-DE Xapp policy kit agent. And if we want to make progress before the policykit-1-gnome debian maintainers give up (which they already kind of have, last update was in 2018 and they are at Standards-Version 4.1.4, latest is 4.5.1), then I'd get going soon.. |
|
While this discussion is specific to polkit-gnome, it is definitely not the only component Cinnamon depends on which has no maintained upstream (caribou, libtimezonemap). It seems like this is worth a broader discussion on how to deal with these class of dependencies. i.e.
Warning - ramblings ahead as a Gentoo package maintainer - by all means ignore if it's ignorant and/or not constructive :) As an aside regarding re-using components from other DEs - when I was packaging libtimezonemap for Gentoo, I got the impression that it was a Unitiy component library, which would explain why it got abandoned around the same time Ubuntu dropped Unity. This is where I feel a bit fuzzy around what constitutes a DE specific component vs a generic lib/util that happens to have a DE specific name. When you look at it, polkit-gnome, caribou, gnome-screenshot, and gsettings-desktop-schemas are from GNOME. libtimezonemap was(?) from Unity. So the argument to not use anything that originates from a different DE doesn't hold a whole lot of water for me. IMHO a more important determination is regarding code quality, active development, and whether or not there are DE exclusive dependencies/behaviors we wouldn't want also pulled in. For example, mate-polkit depends on mate-common as a non-starter :/ I'm also not sure I'd advocate for something like "polkit-xapp" as a replacement. I feel like the polkit client is something that should be dead simple, and having them try to do more DE integrated things is what led to all of the fragmentation. It seems like we should take a leaf from polkit-qt and propose "polkit-gtk" as a dead simple pure (py?)GTK implementation that all GTK DEs would use. And, while I certainly wouldn't disagree that xapp is designed around being DE agnostic (though it does imply X?), from the standpoint of Gentoo, it is very much a Mint/Cinnamon specific paradigm. I think blueberry is the only non-Cinnamon package using it - and even then it's still from Mint. We've pretty much stuck with using the analogous GNOME apps. |
|
Xapp is (bear with me) a Mint thing and I am pretty confident the only reason it's in 90% of all popular distros is for cinnamon. Xapps shouldn't be the solution to all your problems, guys. While I am down for it, you need to think of what would be the best for everyone else and yourself. I don't care what the issue is but if you want to make life easier for everyone Cinnamon should bounce back to the MATE Polkit and only use it's parts or pick up maintainership. It's a popular DE not going around anywhere built for all types of Linux, not just Mint. But at this point the idea of what is needed is to have all these branches of GNOME 2(or 3, I suppose) to all use the same thing. In other words, don't make new stuff, maintain the old stuff and catch it up to current standards. MATE - I am sure they are willing to drop polkit if policykit-1-gnome is remaintained as caribou is-an alternative to GNOME's fancy stuff. XFCE would catch on aswell. This way Cinnamon keeps its stability and XFCE and MATE can have a bridge together with its own GNOME branch components. Hopefully we can get these repos out of the Archive section in the GNOME GitLab or host them here in Mint's GH. |
|
@smcv what agent does GNOME Flashback use in Debian? Afaik Shell's agent is part of Shell so it won't run in Flashback right? Do you ship Flashback with another agent? Do the polkits libs show a dialog and a basic UI agent in the absence of GNOME polkit? I'm asking because even though we depend on GNOME polkit, we only do so package-wise (in debian/control), and Debian has its own packaging, so it can perfectly remove that dependency and ship with the same solution as it uses for GNOME Flashback. |
@ItzSwirlz This question was inspired by the blog post @thomasphansen is complaining about. After reading the arguments to and fro in that blog, I had a look at LM Cinnamon bit differently and the history. You are looking after Ubuntu-Cinnamon, so could be interested. I thought @clefebvre would reply, without closing the thread. I am really interested, maybe others too, which gnome-shell version was forked to create Cinnamon. It is hard to believe, every time Gnome changed its shell, that was continuously forked. Having this doubt is a headache. |
|
@chdslv it was only forked once. I don't know exactly which version, but it was an early one. Since then, cinnamon has diverged from gnome shell considerably. They are now very different projects. There have been a handful of changes that have been copied from Gnome shell, but they are rare. |
Then, those people at that blog were right. Cinnamon was forked (copied, based) from a quite old, deprecated gnome shell. Of course, Cinnamon has diverged from Gnome considerably, just like gnome shell 3.38 is differ from 3.22, or Gnome 40 differ from 3.38. Nemo is old, forked from Nautilus 3.4, Mutter used in Muffin is deprecated. I do like old stuff. I use Openbox sometimes, but am worried it will stop working, if I keep on updating. Anyway as LM is based on Ubuntu LTS, LM has to depend on Ubuntu's packages, or hold all the packages in LM repos and block any kind of upstream updating. Ubuntu would surely move away from deprecated packages, and stop holding them in their repos. So, it is a real worry, mine and others, whether LM is ready to move with Ubuntu changes, like GTK4, like Wayland etc. There's only Xubuntu out there lagging behind, so some of the packages will be kept yet, but not all. Anyway, thanks for replying @collinss |
The post mentioned by @lestcape is one of them, in the comments section. The same subject is raised again by the same user in another post, here: |
|
PLEASE OPEN A SEPARATE TICKET. The topic of gtk4 is completely unrelated to "should cinnamon write a polkit agent in the main thread or keep relying on polkit-gnome or fork polkit-gnome". |
Isn't Policykit and GTK are interconnected somehow? |
Correct. GNOME Shell's agent is essentially the same code that Cinnamon removed a few years ago, as previously mentioned on this issue (a Javascript/Clutter UI layer, currently a system-modal dialog similar to the ones for shutdown/reboot and password prompts, plus some C glue to interface that with libpolkit-agent).
I don't use or maintain Flashback myself, but from the packaging changelog it looks as though an agent (presumably GTK-based) was added to it in 3.18.0, so it does not need or use an agent from a separate package.
No, the polkit client library and daemon are entirely non-GUI. In particular, they do not depend on a specific GUI toolkit like GTK, Qt or Clutter: the desktop environment is expected to provide a polkit agent, using a GUI toolkit and UI design that is appropriate for that desktop environment's requirements and conventions. The polkit agent could be part of the UI shell as in GNOME, or could be delegated to a separate program, whichever fits your design better. Most polkit clients are system daemons like udisks2 and NetworkManager, for which showing a dialog isn't possible. A few polkit clients, notably
The closest equivalent of the solution we use for GNOME Flashback would be for Cinnamon to have its own built-in agent, similar to #10177. I suspect that's not the answer you hoped for.
If that's the route you want to take, then I'd suggest that someone from Cinnamon should take responsibility for policykit-gnome (aka policykit-1-gnome) under a new name. GNOME developers are not going to maintain it for Cinnamon's benefit, but if there's nothing you'd want to change, then maintaining it under a new name should hopefully be low-effort. |
This is the chosen resolution. That said the dependency on GNOME polkit is only there in the Mint packaging, it doesn't exist in Cinnamon itself. In Debian, you're perfectly welcome to depend on lxde-polkit, mate-polkit or whatever alternative to gnome-polkit you want. Just depend on it in your own packaging and make sure to autostart it for Cinnamon sessions. |
Did not the Debian maintainers of polkit notice other packages depends on "policykit-1-gnome" package?
|
Those dependencies are part of a list of alternatives that also accepts other polkit agents (apart from cinnamon-control-center, but whatever is done for cinnamon presumably applies equally to c-c-c). |
As i said, merging ui should be a temporal things only and now GNOME is leaving Gtk completely behind for a more pure Cutter desktop. That ofcourse it's really interesting as Cinnamon is supposedly in the opposite direction. I think that if you want to continue to fork some GNOME packages, you will need to re-evaluate which direction you want to go. GNOME is getting rid of Gtk completely on the desktop, so it will most likely stop supporting embed any Gtk-related stuff into the desktop. This is surely going to impact anyone who instead wants to bring more Gtk stuff to the desktop, like can be Cinnamon. The more important changes are in the pull requests: 1- They are moving system tray icons away from Gtk: 2- Getting rid of Gtk completely in Mutter You are already alerted. |
|
hi, now in debian there are RC bugs against cinnamon and cinnamon-control-center for remove of policykit-1-gnome, are remained only them using it: |
|
I think xdg-desktop-portal-xapp has polkit support in it (does it?) |
I don't see any sign of it being a polkit agent. Polkit agents and portal backends are two separate components - in principle I think there would be nothing to prevent them from being hosted in the same executable, but I'm not aware of any desktop environment that actually does that. Polkit agents and portal backends have some things in common: they should match the desktop environment's desired UI behaviour and appearance, and their purpose is to ask the user whether to allow something. They also have some important differences: polkit agents are about getting permission for a system service to do something with root privileges in response to an application request, whereas portal backends are about getting permission for a sandboxed app to do something (usually with only ordinary user privileges, and not system-wide privileges) outside its sandbox. |
|
For consistency with Mint's behavior, what I would expect is that instead of using a 3rd party application with a hard to digest 3rd party name (mate-polkit), Mint would fork policykit-1-gnome in some sort of XApp and then it can be used where it is needed, but with a generic name like that. This at least is supposed to be the objective of the XApps and I think this case falls into the same bag. It is clear that it is not a grace to have to maintain another package, but isn't it the same thing that has already happened in other desktops environments? At least that way Mint would have the plus of the generic name. Even if no one else decides to use it, the fact of think about sharing things with others, it's a plus to said thanks to Mint. I hope others see it that way, although they certainly can't be forced to use these "generic" packages and we cannot forced others to name his own packages in a generically way like Mint does either. I need to said that this is not my preference, this just only what I hope will happen, from what I have seen that Mint has done in similar conditions. My preference is for a solution that uses Clutter as the GUI, as is the case in GNOME. It would certainly be nice if this solution ran in its own process or thread, but we already know that Clutter is not designed to be used as an app toolkit, but rather to run embedded within a desktop and also Clutter cannot run outside the main thread either. I don't really know how much the polkit could spam the compositor thread, but I would expect that polkit actually only uses the CPU when is executing a direct user command and not in other contexts. That being the case, I don't see that including the polkit inside the shell is really an overhead or have negative effects on the performance of Cinnamon as a whole. I think this is what should be investigate and evaluate. Removing code that isn't actually running isn't going to make Cinnamon any faster. |
This will allow us to launch programs as root in a wayland session. ref: linuxmint#10172 todo: - styling - multi-user selection - ?
This will allow us to launch programs as root in a wayland session. ref: linuxmint#10172 todo: - styling - multi-user selection - ?
This will allow us to launch programs as root in a wayland session. ref: linuxmint#10172 possible todo: - multi-user selection
This will allow us to launch programs as root in a wayland session. ref: linuxmint#10172 possible todo: - multi-user selection
This will allow us to launch programs as root in a wayland session. ref: linuxmint#10172 fixes: linuxmint/wayland#64 fixes: linuxmint/wayland#26 fixes: linuxmint/wayland#22 possible todo: - multi-user selection
This will allow us to launch programs as root in a wayland session. ref: linuxmint#10172 fixes: linuxmint/wayland#64 fixes: linuxmint/wayland#26 fixes: linuxmint/wayland#22 possible todo: - multi-user selection
This will allow us to launch programs as root in a wayland session. ref: #10172 fixes: linuxmint/wayland#64 fixes: linuxmint/wayland#26 fixes: linuxmint/wayland#22 possible todo: - multi-user selection
|
I hate all this spam from force-pushing... I've re-added polkit agent to Cinnamon, For now it's only going to be used for Wayland sessions, but it works in either session type. |
|
@mtwebster Big thanks for your works |
|
Oops, I'll add it back - at the moment our fallback mode (mate panel) still needs it. We might change our mind before Mint 22, but not sure. |
|
policykit-1-gnome will be removed before Debian 13 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990271), cinnamon is the only remained using it. |
|
I created #12272 while updating packages for Gentoo. |
The Debian maintainers of polkit noticed that the Debian package for Cinnamon 4.x depends on
policykit-1-gnome, and the same seems to be true in Linux Mint's packaging of Cinnamon 5.x.PolicyKit-gnome hasn't been used by GNOME since GNOME 3 (around 2010), and hasn't been used by GNOME Flashback since 2015, so it is no longer maintained by GNOME. The upstream project was officially deprecated 6 years ago and it has now been moved to a read-only archived state. This doesn't seem great for something that Cinnamon is using as a security-sensitive desktop component.
Please consider alternatives: either giving Cinnamon a built-in polkit agent similar to the one in GNOME Shell (which appears to have been removed from Cinnamon in 2013), or forking PolicyKit-gnome under the Cinnamon umbrella and taking responsibility for its maintenance and security, or using some other polkit agent.
The text was updated successfully, but these errors were encountered: