Submission checklist
Feature type
Integration support
Feature summary
Systemd implements the password agent protocol -- a lightweight system that allows arbitrary services asking for deferred human input. "Password agent" is the part that provides said passwords (generally directly from human input)
Historically, only root could run a password agent, but since systemd v257, support for password agents for unprivileged users has been introduced.
It would be quite handy if Noctalia could act as a systemd password agent for the current user.
Motivation / use case
Frankly, I am quite annoyed by the eye-watering zoo of all the various password prompts my system tends to throw at me: pinentry, gcr-prompter, bespoke application prompts, etc. Granted, this problem can't be solved overnight by implementing a somewhat obscure protocol. But at least I could easily replace pinentry with Noctalia's password prompter, and that would already be quite a lot in my case. With some elbow grease, I could also replace gcr-prompter. Overall, I believe systemd's password agent protocol is the closest thing we have to something resembling a standard here.
Proposed solution
Noctalia already registers itself as a polkit agent. Working as a systemd password agent seems like a relatively natural extension of that. The protocol is relatively simple and boils down to watching a directory for files, reading an ini and writing to some unix sockets.
Alternatives considered
- Adding a
noctalia msg request-password <prompt>, but that seems very ad-hoc.
- Implementing pinentry protocol (via some moral equivalent of
noctalia msg pinentry), but the protocol itself is a bit naff, and it's basically instant legacy code.
- Implement gnome's
org.gnome.keyring.SystemPrompter interface. This seems overly specific to a particular DE (which also seems to be moving ideologically in a completely different direction). So does not sound like a good idea. Also, the protocol there is quite complicated.
References / related projects
https://systemd.io/PASSWORD_AGENTS/ -- particularly note the "Unprivileged Per-User Password Agents" at the bottom there.
Additional context
No response
Submission checklist
Feature type
Integration support
Feature summary
Systemd implements the password agent protocol -- a lightweight system that allows arbitrary services asking for deferred human input. "Password agent" is the part that provides said passwords (generally directly from human input)
Historically, only root could run a password agent, but since systemd v257, support for password agents for unprivileged users has been introduced.
It would be quite handy if Noctalia could act as a systemd password agent for the current user.
Motivation / use case
Frankly, I am quite annoyed by the eye-watering zoo of all the various password prompts my system tends to throw at me: pinentry, gcr-prompter, bespoke application prompts, etc. Granted, this problem can't be solved overnight by implementing a somewhat obscure protocol. But at least I could easily replace pinentry with Noctalia's password prompter, and that would already be quite a lot in my case. With some elbow grease, I could also replace gcr-prompter. Overall, I believe systemd's password agent protocol is the closest thing we have to something resembling a standard here.
Proposed solution
Noctalia already registers itself as a polkit agent. Working as a systemd password agent seems like a relatively natural extension of that. The protocol is relatively simple and boils down to watching a directory for files, reading an ini and writing to some unix sockets.
Alternatives considered
noctalia msg request-password <prompt>, but that seems very ad-hoc.noctalia msg pinentry), but the protocol itself is a bit naff, and it's basically instant legacy code.org.gnome.keyring.SystemPrompterinterface. This seems overly specific to a particular DE (which also seems to be moving ideologically in a completely different direction). So does not sound like a good idea. Also, the protocol there is quite complicated.References / related projects
https://systemd.io/PASSWORD_AGENTS/ -- particularly note the "Unprivileged Per-User Password Agents" at the bottom there.
Additional context
No response