Fedora 34 Change proposal: Modular GNOME Keyring services (Self-Contained Change)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/ModularGnomeKeyring

== Summary ==
The monolithic daemon provided by GNOME Keyring will be split into
dedicated sub-daemons, so that they can be consistently managed by
systemd.

== Owner ==
* Name: [[User:ueno|Daiki Ueno]]
* Email: dueno(a)redhat.com
* Name: [[User:benzea|Benjamin Berg]]
* Email: bberg(a)redhat.com
* Product: Workstation
* Responsible WG: Workstation

== Detailed Description ==

GNOME Keyring provides multiple services from a single daemon program
called gnome-keyring-daemon. This daemon is launched by the session
manager (gnome-session) or PAM, depending on desktop environments.
That design makes troubleshooting hard when any issue arises, as well
as the individual services cannot be easily turned off.

Despite its original goal to be the central cryptographic service on
desktop, the scope of GNOME Keyring has been gradually reduced over
years. Notable examples are
[https://bugzilla.gnome.org/show_bug.cgi?id=750514 gpg-agent removal]
in 2015, [https://bugzilla.gnome.org/show_bug.cgi?id=791401 PKCS #11
module deprecation] and
[https://bugzilla.gnome.org/show_bug.cgi?id=775981 ssh-agent rewrite
to wrap ssh-agent from OpenSSH] in 2018. Now that only the essential
services remaining in gnome-keyring-daemon are D-Bus secret-service
and the ssh-agent wrapper, it would be straightforward to split the
daemon into sub-daemons per functionality.

== Benefit to Fedora ==
This will bring in consistent experience of setting up and managing
the individual services provided by GNOME Keyring, taking advantage of
systemd service manager.

== Scope ==
* Proposal owners: gnome-keyring-daemon currently provides 3 services:
D-Bus secret-service, ssh-agent wrapper, and a control socket for PAM
to automatically unlock the login keyring. Those services are either
split out, or removed in favor of other means, in the following steps:
** Make the D-Bus secret-service D-Bus activatable
** Make the ssh-agent wrapper service socket activatable
** Move the ssh-agent wrapper service to gcr
** Modify the PAM module to use libsecret API to unlock the login
keyring, instead of the control socket
** Install systemd unit files for those services, modify the current
session initialization sequence to use them
** (Stretch goal) move the D-Bus secret-service implementation to libsecret
** (Stretch goal) remove the gnome-keyring package from the default compose

* Other developers: N/A (not a System Wide Change)
* Release engineering:
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:

== Upgrade/compatibility impact ==
N/A (not a System Wide Change)

== How To Test ==
Check if the GNOME Keyring services are now managed by systemd, using
systemctl status. Check if the existing applications (Seahorse, SSH
clients, etc.) still work.

== User Experience ==
No visible change should be observed by normal users.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)

== Documentation ==
N/A (not a System Wide Change)

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis

[Michael Catanzaro]

On Wed, Nov 4, 2020 at 1:12 pm, Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  Despite its original goal to be the central cryptographic service on
>  desktop, the scope of GNOME Keyring has been gradually reduced over
>  years. Notable examples are
>  [https://bugzilla.gnome.org/show_bug.cgi?id=750514 gpg-agent removal]
>  in 2015, [https://bugzilla.gnome.org/show_bug.cgi?id=791401 PKCS #11
>  module deprecation] 
Any plans to finish the PKCS#11 module deprecation work? Currently the 
module cannot be removed as it implements public gcr API needed by 
GNOME applications like geary.

[Daiki Ueno]

Michael Catanzaro <mcatanzaro(a)gnome.org&gt; writes:

>  On Wed, Nov 4, 2020 at 1:12 pm, Ben Cotton <bcotton(a)redhat.com&gt;
> wrote:
> > Despite its original goal to be the central cryptographic service on
> > desktop, the scope of GNOME Keyring has been gradually reduced over
> > years. Notable examples are
> > [https://bugzilla.gnome.org/show_bug.cgi?id=750514 gpg-agent removal]
> > in 2015, [https://bugzilla.gnome.org/show_bug.cgi?id=791401 PKCS #11
> > module deprecation]
>
>  Any plans to finish the PKCS#11 module deprecation work? Currently the
>  module cannot be removed as it implements public gcr API needed by
>  GNOME applications like geary. 
It's a bit off-topic to this Change proposal, but let me briefly answer:
the original plan was to make the gcr API to use p11-kit-trust.so
instead of gnome-keyring.so to store the trust assertion information.
Later we realized that this approach requires significant effort,
including the enablement of p11-kit-trust's per-user trust store by
default, which is currently disabled at compile time.

On the other hand, the use-case is quite limited (the only affected
application I know of is geary).  I suspect a more practical plan might
be to let gcr maintain trust assertions in a local file by its own.  I
haven't had time to investigate this possibility further, but if anyone
is willing to work on it, that would be certainly appreciated.

Regards,
-- 
Daiki Ueno