From Fedora Project Wiki
mNo edit summary
(Change deferred by owner)
(13 intermediate revisions by 2 users not shown)
Line 5: Line 5:


== Owner ==
== Owner ==
* Name: [[User:ueno|Daiki Ueno]]
* Name: [[User:ueno|Daiki Ueno]], [[User:benzea|Benjamin Berg]]
* Email: dueno@redhat.com
* Email: dueno@redhat.com, bberg@redhat.com
 
* Name: [[User:benzea|Benjamin Berg]]
* Email: bberg@redhat.com
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
Line 18: Line 15:


== Current status ==
== Current status ==
[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF39]]


<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
Line 29: Line 26:
<!-- [[Category:SystemWideChange]] -->
<!-- [[Category:SystemWideChange]] -->


* Targeted release: [[Releases/34 | Fedora 34 ]]  
* Targeted release: [[Releases/39 | Fedora Linux 39 ]]  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
Line 38: Line 35:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* FESCo issue: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/2502 #2502]
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1899998 #1899998]
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/605 #605]


== Detailed Description ==
== Detailed Description ==


GNOME Keyring provides multiple services exposed as part of a single daemon program called gnome-keyring-daemon, launched by the session manager (gnome-session) or PAM, depending on desktop environments. That design makes the desktop integration quite complex and troubleshooting is hard when any issue arises.
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 service remaining in gnome-keyring-daemon are D-Bus secret-service and the ssh-agent wrapper, it would be worth splitting the daemon into sub-daemons, so they can be managed by systemd.
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.


<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
Line 83: Line 80:
     https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
     https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
-->
-->
This will bring in consistent experience of setting up and managing the GNOME Keyring services, taking advantage of the fine grained systemd service units. This would simplify the security related services running on desktop, and make it easier to adopt modern security features e.g., hardware-based security.
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 ==
== 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:
* 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 D-Bus secret-service D-Bus activatable
** Make the ssh-agent wrapper code socket 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
** 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
** Install systemd unit files for those services, modify the current session initialization sequence to use them
** (Stretch goal) move the service implementations from gnome-keyring to more appropriate packages (gcr and libsecret) and remove the gnome-keyring package from the default compose
** (Stretch goal) move the D-Bus secret-service implementation to libsecret
** (Stretch goal) remove the gnome-keyring package from the default compose
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->



Revision as of 20:42, 13 February 2023

Modular GNOME Keyring services

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

  • Product: Workstation
  • Responsible WG: Workstation

Current status

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 gpg-agent removal in 2015, PKCS #11 module deprecation and 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.


Feedback

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)
  • 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

The migration should be transparent.

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.

N/A (not a System Wide Change)

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), Yes/No
  • Blocks product? product

Documentation

N/A (not a System Wide Change)

Release Notes