Gnome Keyring System Dialogs

In many cases gnome-keyring uses system modal dialogs to prompt for passwords or other information. The overriding principal is to prompt as little as possible, and when possible during prompting offer the option to save the password or response for future automatic use.

Use cases

Unlocking a keyring:

• An application wishes to use a password in a gnome-keyring keyring.
• The keyring is not yet unlocked and needs to be unlocked, and cannot be unlocked automatically.
• The user is prompted for the password in a system modal dialog, and is presented (when possible) with the option to save this password in the login keyring, so that the keyring can be unlocked automatically in the future.
• If the user types the wrong password, a message to that effect is displayed, and the dialog does not go away until the user unlocks the keyring or cancels the dialog.
• Process requesting prompt: gnome-keyring-daemon on behalf of another application

SSH key password:

• openssh wishes to use an SSH key.
• The key is encrypted with a password, and cannot be unlocked automatically.
• The user is prompted for the password for the key in a system modal dialog, and is presented (when possible) with the option to save this password in the login keyring, so that the key can be unlocked automatically in the future.
• Process requesting prompt: gnome-keyring-daemon on behalf of openssh

SSH key access:

• The user has SSH agent forwarding running so that remote systems can use a key on behalf of the user.
• The user has requested (via a setting in the seahorse key manager) that each use of a given key, is confirmed by the user, so that remote systems cannot use the password without the users awareness
• System dialog is shown, with descriptive text and descriptive continue/cancel buttons.
• Similar use case with kerberos ticket forwarding in the future.

TODO: other use cases: new pin for smart card, new password for keyring, etc...

Design

As passwords for keyrings, PINs for smart cards and access confirmation for key use, be prompted for, the architecture design must be generic enough to handle these various use cases.

• Since this is about system modal dialogs, only one prompt shown at a time.
• Multiple requests may make up one prompt (prompt password, password invalid, prompt password again), and the modal dialog should dissappear go away between requests.
• Between requests of a single prompt, if a short amount of time is taken (validating password), then a spinner should show in place of the usual icon, and the prompt should be disabled.
• Corner case: If multiple applications are both trying to prompt the user, then all the various requests of a single prompt should complete before the second applications prompts are shown.
• Corner case: If multiple applications competing for prompt, then after waiting for prompting to be available, then the second one must check whether the prompt is still necessary, before proceeding.
• The look is very similar to current system modal dialogs, and would be made to follow them wherever possible.

Ascii art:

 --------------------------------------------------------
 | ------                                               |
 | |ICON|     Request for password                      |
 | ------                                               |
 |            Description of what the password is       |
 |            needed for                                |
 |                                                      |
 |            Password: [ xxxx              ]           |
 |                      /Password was incorrect/        |
 |                      [x] Automatically unlock choice |
 |                                                      |
 | [Cancel]                               [Continue]    |
 --------------------------------------------------------

 --------------------------------------------------------
 | ------                                               |
 | |ICON|     Request for confirmation                  |
 | ------                                               |
 |            Long description                          |
 |                                                      |
 | [Cancel]                               [Continue]    |
 --------------------------------------------------------

Architecture

• Use http://developer.gnome.org/gcr/unstable/gcr-GcrSecretExchange.html to transfer secrets across dbus, so that passwords won't be accidentally logged, or paged to disk while in transit.

• Prompter base class, and prompt client class in the gcr library, which use an internal dbus interface to communicate with one another.
• The shell implements a prompter, which when used grays the screen in the normal shell style and puts up a system modal dialog.
• Gcr provides a default implementation of the prompter, which simply shows a GTK+ dialog. This is for use on systems where the shell is not running.