Mercurial Keyring Extension
Project description
mercurial_keyring is a Mercurial extension used to securely save HTTP and SMTP authentication passwords in password databases (Gnome Keyring, KDE KWallet, OSXKeyChain, specific solutions for Win32 and command line). This extension uses and wraps services of the keyring library.
How does it work
The extension prompts for the password on the first pull/push (in case of HTTP) or first email (in case of SMTP), just like it is done by default, but saves the password in password database. On successive runs, whenever the password is needed, it checks for the username in .hg/hgrc, then for suitable password in the password database, and uses those credentials (if found).
In case password turns out to be incorrect (either because it was invalid, or because it was changed on the server) or missing, it just prompts the user again.
Passwords are identified by the combination of username and remote address, so they can be reused between repositories if they access the same remote repository (or the same SMTP server).
Installation
Prerequisites
This extension requires keyring and mercurial_extension_utils to work. In many cases both will be installed automatically while you install mercurial_keyring, but you may need to control the process.
The keyring library can usually be installed by:
pip install --user keyring
(or easy_install keyring), but on some systems it is preferable to use official distribution archive. For example, on Debian and Ubuntu, you may install python-keyring and either python-keyring-gnome or python-keyring-kwallet packages:
sudo apt-get install python-keyring python-keyring-gnome
(this will save you the need to provide working compiler and various development libraries).
The mercurial_extension_utils module is tiny Python-only module, which can be installed by:
pip install --user mercurial_extension_utils
but in some cases (Windows…) require more care. See mercurial_extension_utils documentation.
Extension installation
There are two possible ways of installing the extension: using PyPi package, or using source clone.
To install as a package:
pip install --user mercurial_keyring
(or sudo pip install mercurial_keyring for system-wide installation) and then enable it in ~/.hgrc (or /etc/mercurial/hgrc or Mercurial.ini) using:
[extensions] mercurial_keyring =
To install as source clone, install keyring according to instructions above, then clone:
hg clone https://bitbucket.org/Mekk/mercurial_keyring/ hg clone https://bitbucket.org/Mekk/mercurial-extension_utils/
and configure Mercurial by telling it full path to the extension (in ):
[extensions] mercurial_keyring = /path/to/mercurial_keyring/mercurial_keyring.py
Password backend configuration
The library should usually pick the most appropriate password backend without configuration. Still, if necessary, it can be configured using ~/keyringrc.cfg file (keyringrc.cfg in the home directory of the current user). Refer to keyring docs for more details.
I considered handling similar options in hgrc, but decided that single user may use more than one keyring-based script. Still, I am open to suggestions.
Repository configuration (HTTP)
Edit repository-local .hg/hgrc and save there the remote repository path and the username, but do not save the password. For example:
[paths] myremote = https://my.server.com/hgrepo/someproject [auth] myremote.schemes = http https myremote.prefix = my.server.com/hgrepo myremote.username = mekk
Simpler form with url-embedded name can also be used:
[paths] bitbucket = https://User@bitbucket.org/User/project_name/
If prefix is specified, it is used to identify the password (so all repositories with the same prefix and the same username will share the same password). Otherwise full repository URL is used for this purpose.
Note: if both username and password are given in .hg/hgrc, extension will use them without using the password database. If username is not given, extension will prompt for credentials every time, also without saving the password.
Finally, if you are consistent about remote repository nicknames, you can configure the username in your ~/.hgrc (.hgrc in your home directory). For example, write there:
[auth] acme.prefix = hg.acme.com/repositories acme.username = johnny acme.schemes = http https
and as long as you will be using alias acme for repositories like https://hg.acme.com/repositories/my_beautiful_app, username johnnny will be used, and the same password reused.
The advantage of this method is that it works also for clone.
Repository configuration (SMTP)
Edit either repository-local .hg/hgrc, or ~/.hgrc and set there all standard email and smtp properties, including SMTP username, but without SMTP password. For example:
[email] method = smtp from = Joe Doe <Joe.Doe@remote.com> [smtp] host = smtp.gmail.com port = 587 username = JoeDoe@gmail.com tls = true
Just as in case of HTTP, you must set username, but must not set password here to use the extension, in other cases it will revert to the default behavior.
Usage
Configure the repository as above, then just hg pull, hg push, etc. You should be asked for the password only once (per every username and remote repository prefix or url combination).
Similarly, for email, configure as above and just hg email. Again, you will be asked for the password once (per every username and email server address combination).
Implementation details
The extension is monkey-patching the mercurial passwordmgr class to replace the find_user_password method. Detailed order of operations is described in the comments inside the code.
History
See HISTORY.txt.
Development
Development is tracked on BitBucket, see http://bitbucket.org/Mekk/mercurial_keyring/
Additional notes
Information about this extension is also available on Mercurial Wiki: http://mercurial.selenic.com/wiki/KeyringExtension
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.