From Fedora Project Wiki
mNo edit summary
No edit summary
Line 1: Line 1:
{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.<br/> '''Copy the source to a ''new page'' before making changes!  DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}
= Modular GNOME Keyring services =
 
{{admon/tip | Guidance | For details on how to fill out this form, see the [https://docs.fedoraproject.org/en-US/program_management/changes_guide/ documentation].}}
 
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
 
= Modular GNOME Keyring <!-- The name of your change proposal --> =


== Summary ==
== Summary ==
Line 11: Line 5:


== Owner ==
== Owner ==
<!--
* Name: [[User:ueno|Daiki Ueno]]
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages.
* Email: dueno@redhat.com
This should link to your home wiki page so we know who you are.
 
-->
* Name: [[User:benzea|Benjamin Berg]]
* Name: [[User:ueno|Daiki Ueno]], [[User:benzea|Benjamin Berg]]
* Email: bberg@redhat.com
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
* Email: dueno@redhat.com, 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 52: Line 44:
== Detailed Description ==
== Detailed Description ==


While GNOME Keyring was originally aiming to be the central cryptographic service on desktop, its scope 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] in 2018, and [https://bugzilla.gnome.org/show_bug.cgi?id=775981 ssh-agent rewrite to defer the operations to the OpenSSH ssh-agent] in 2018.
While GNOME Keyring was originally aiming at the central cryptographic service on desktop, its scope 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.


Those services were exposed as part of the single daemon program called gnome-keyring-daemon, launched by the gnome-session or PAM depending on desktop environments. Now that only the essential service remaining in gnome-keyring-daemon is the D-Bus secret-service, it would be worth considering the split of the daemon into small sub-services, which can be activated by systemd.
All the GNOME Keyring services are 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. 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.


<!-- 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 91: Line 83:
     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)
-->
-->
Consistent experience of managing the services due to fine grained service units. This would simplify the desktop secret management and allow further extension of it towards modern security mechanisms e.g., hardware-based security.
This will bring in consistent experience of setting up and managing the GNOME Keyring services thanks to 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.


== Scope ==
== Scope ==
* Proposal owners:
* Proposal owners:
** Move the ssh-agent code from the gnome-keyring package to gcr, making it socket activatable
 
** The remaining secret-service is made to be D-Bus activatable
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:
** Install systemd unit files for those sub services, replacing the monolithic gnome-keyring-daemon service
 
** The D-Bus secret-service is made to be D-Bus activatable
** Move the ssh-agent code from the gnome-keyring package to the gcr package, making it socket activatable
** Modify the PAM module to use libsecret API to unlock the login keyring, instead of through the control socket
** Install systemd unit files for those services, modify the current session initialization sequence to use them
 
As a stretch goal, we may move the D-Bus secret-service implementation to libsecret, so we can 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?-->


Line 118: Line 116:
== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
The migration should be transparent.


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 123: Line 122:


== How To Test ==
== How To Test ==
Check if the sub-services are managed by systemd, using systemctl status.
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.
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.  
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.  


Revision as of 05:33, 26 October 2020

Modular GNOME Keyring services

Summary

The monolithic gnome-keyring-daemon will be split into dedicated sub-daemons, so that they can be consistently managed by systemd.

Owner

  • Product: Workstation
  • Responsible WG: Workstation

Current status

  • Targeted release: Fedora 34
  • Last updated: 2020-10-26
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

While GNOME Keyring was originally aiming at the central cryptographic service on desktop, its scope 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.

All the GNOME Keyring services are 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. 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.


Feedback

Benefit to Fedora

This will bring in consistent experience of setting up and managing the GNOME Keyring services thanks to 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.

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:

    • The D-Bus secret-service is made to be D-Bus activatable
    • Move the ssh-agent code from the gnome-keyring package to the gcr package, making it socket activatable
    • Modify the PAM module to use libsecret API to unlock the login keyring, instead of through the control socket
    • Install systemd unit files for those services, modify the current session initialization sequence to use them

As a stretch goal, we may move the D-Bus secret-service implementation to libsecret, so we can 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

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/ModularGnomeKeyring&oldid=592199"