.. -*- mode: rst; compile-command: "rst2html README.rst README.html" -*-
=======================================================
Mercurial Keyring
=======================================================
Mercurial Keyring is a Mercurial_ extension used to securely save HTTP
and SMTP authentication passwords in password databases (Gnome
Keyring, KDE KWallet, OSXKeyChain, Windows Vault etc).
With ``mercurial_keyring`` active, Mercurial remembers your passwords
and reuses them without prompting (as if you stored them in ``.hgrc``),
but password storage is reasonably secure.
Actual password storage is implemented by the keyring_ library, this
extension glues it to Mercurial.
.. contents::
:local:
:depth: 2
.. sectnum::
.. _keyring: http://pypi.python.org/pypi/keyring
How does it work
=======================================================
On your first pull or push to HTTP url (or first email sent via given
SMTP server), you are prompted for the password, just like bare
Mercurial does. But the password you entered is saved to appropriate
password database. On successive runs, whenever the password is
needed, ``mercurial_keyring`` checks for password in password
database, and uses it without troubling you.
In case password turns out to be incorrect (for example, because you
changed it, or entered it incorrectly), ``mercurial_keyring`` prompts
you again, and overwrites the password.
You can use many passwords (for various remote urls). Saved passwords
are identified by pair of username and url prefix. See below for
information how to configure those properly.
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…) requires 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 using source clone, install keyring_ according to the
instructions above, then clone::
hg clone https://foss.heptapod.net/mercurial/mercurial_keyring/
hg clone https://foss.heptapod.net/mercurial/mercurial-extension_utils/
and configure Mercurial using full path to the extension module::
[extensions]
mercurial_keyring = /path/to/mercurial_keyring/mercurial_keyring.py
.. _the code:
.. _mercurial_keyring.py: https://foss.heptapod.net/mercurial/mercurial_keyring/src/tip/mercurial_keyring.py
Password backend configuration
=======================================================
The most appropriate password backend should usually be picked without
configuration (considering installed libraries, operating system,
active desktop session). Still, if necessary, it can be configured
using ``keyringrc.cfg`` file. Refer to keyring_ docs for more
details.
.. note::
With current (as I write) keyring (5.6), this file is (on Linux)
located at ``~/.local/share/python_keyring/keyringrc.cfg`` and
it's example content looks like::
[backend]
default-keyring=keyring.backends.Gnome.Keyring
# default-keyring=keyring.backends.kwallet.Keyring
For list of known backends run ``pydoc keyring.backends`` or
``keyring --list-backends`` (which of those commands work,
depends on the keyring_ version).
``hgrc`` configuration (HTTP)
=======================================================
Mercurial Keyring uses standard Mercurial ``[auth]`` configuration to
detect your username (on given remote) and url prefix. You are
strongly advised to configure both.
Without the username ``mercurial_keyring`` can't save or restore
passwords, so it disables itself.
Without url prefix ``mercurial_keyring`` works, but binds passwords to
repository urls. That means you will have to (re)enter password for
every repository cloned from given remote (and that there will be many
copies of this password in secure storage).
Repository level configuration
------------------------------------
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.prefix = https://my.server.com/hgrepo
myremote.username = John
Simpler form with url-embedded name can also be used:
::
[paths]
bitbucket = https://John@my.server.com/hgrepo/someproject/
but is not recommended.
Note that all repositories sharing the same ``prefix`` share the same
password.
Mercurial allows also for password in ``.hg/hgrc`` (either given by
``«prefix».password``, or embedded in url). If such password is found,
Mercurial Keyring disables itself.
Account-level configuration
---------------------------
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
heptapod.prefix = https://foss.heptapod.net
heptapod.username = Mekk
mydep.prefix = https://dev.acmeorg.com
mydep.username = drmartin
and as long as you use ``acme`` alias for repositories like
``https://hg.acme.com/repositories/my_beautiful_app``, username
``johnny`` will be used, and the same password reused. Similarly
any ``hg push heptapod`` will assume username ``Mekk`` and share
the same password.
With such config repository-level ``.hg/hgrc`` need only contain
``[paths]``.
Additional advantage of this method is that it works also during
`clone`.
.. note::
Mercurial Keyring works well with `Path Pattern`_. On my setup I use
prefix as above, and::
[path_pattern]
heptapod.local = ~/devel/mercurial/{below}
heptapod.remote = https://foss.heptapod.net/mercurial/{below:/=-}
so all my repositories understand ``hg push bitbucket`` without
any repository-level configuration.
``hgrc`` 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
======================================================
Saving and restoring passwords
-------------------------------------------------------
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).
Checking password status (``hg keyring_check``)
-------------------------------------------------------
The ``keyring_check`` command can be used to check whether/which
password(s) are saved. It can be used in three ways:
- without parameters, it prints info related to all HTTP paths
defined for current repository (everything from ``hg paths``
that resolves to HTTP url)::
hg keyring_check
- given alias as param, it prints info about this alias::
hg keyring_check work
- finally, any path can be checked::
hg keyring_check https://foss.heptapod.net/mercurial/mercurial_keyring
Deleting saved password (``hg keyring_clear``)
-------------------------------------------------------
The ``keyring_clear`` command removes saved password related to given
path. It can be used in two ways:
- given alias as param, it drops password used by this alias::
hg keyring_clear work
- given full path, it drops password related to this path::
hg keyring_clear https://foss.heptapod.net/mercurial/mercurial_keyring
Managing passwords using GUI tools
------------------------------------------------------
Many password backends provide GUI tools for password management,
for example Gnome Keyring passwords can be managed using ``seahorse``,
and KDE Wallet using ``kwalletmanager``. Those GUI tools can be used
to review, edit, or delete saved passwords.
Unfortunately, as I write, keyring_ library does not allow one to
configure how/where exactly saved passwords are put in the hierarchy,
and the place is not always intuitive. For example, in KDE Wallet, all
passwords saved using ``mercurial_keyring`` show up in the folder
named ``Python``.
.. note::
This is slightly problematic in case ``mercurial_keyring`` is not
the only program using keyring_ library. Passwords saved by another
Python application or script (which also uses keyring_) will be put
into the same place, and it may be unclear which password belongs
to which program. To remedy this, ``mercurial_keyring`` applies
slightly unusual labels of the form
``«username»@@«urlprefix»@Mercurial`` - for example my bitbucket
password is labelled ``Mekk@@https://bitbucket.org@Mercurial``.
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`_.
Frequent problems
=======================================================
Most problems people face while using ``mercurial_keyring`` are in
fact problems with ``keyring`` library and it's backends. In
particular, those can manifest by:
- technical errors mentioning sentences like ``No recommended backend
was available. Install the keyrings.alt package…`` (or similar),
- warnings like ``keyring: keyring backend doesn't seem to work…``
- password prompts on every action (= passwords not being saved).
Those almost always mean that *natural* keyring backend for given
desktop type doesn't work, or is not present at all. For example,
some necessary runtime component can be down (say, you use Linux, but
neither Gnome Keyring, nor KDE Wallet, is running). Or appropriate
backend is not installed because it could not be build during keyring_
library installation (maybe because some required library was not
present at the moment of keyring installation, or maybe because
compiler as such is not present on the system).
To diagnose such problems, try using ``keyring`` utility, as described
on keyring_ documentation page, for example by::
keyring --list-backends
keyring -b keyrings.alt.Gnome.Keyring set testsvc testuser
keyring -b keyrings.alt.Gnome.Keyring get testsvc testuser
(of course using appropriate backend). If you miss the ``keyring`` command
as such, try ``python -m keyring`` instead::
python -m keyring --list-backends
python -m keyring -b keyrings.alt.Gnome.Keyring set testsvc testuser
python -m keyring -b keyrings.alt.Gnome.Keyring get testsvc testuser
If appropriate backend is missing (not listed), or doesn't work
(second or third command fails), your keyring is broken. Try looking
for further pointers in keyring_ documentation, that project mailing
list, or issue tracker. Typically it will turn out, that you need to
install some missing tool, or library, and reinstall keyring.
.. note::
Depending on keyring_ version, installation of some dependency may
resolve problem. For example (as of late 2018), I got KDE Wallet
backend working with pip-installed keyring after::
pip install dbus-python
Note also, that recent versions of keyring library (since version 12) use Python
entrypoints to find available backends. Those are incompatible with
some binary packaging methods (like ``py2app``) and may cause
problems. In particular there were packaged installations of TortoiseHG_
which were unable to load keyring backends. See `#61 <https://foss.heptapod.net/mercurial/mercurial_keyring/issues/61/tortoisehg-encounters-unknown-exception>`_ for some more details.
If ``keyring`` command works, but mercurial with mercurial_keyring does not,
try enforcing proper backend (by means of ``keyringrc.cfg``, see above).
Only if this doesn't help, there may be a bug in mercurial_keyring.
By far easiest way to have properly working keyring is to use packaged
binary version (like ``python-keyring`` Ubuntu package, or keyring
bundled with TortoiseHG_ on some systems). If you pip-installed keyring
and it doesn't work, you may consider removing it via ``pip uninstall
keyring`` and looking for binary package instead.
History
=======================================================
See `HISTORY.rst`_.
Repository, bug reports, enhancement suggestions
===================================================
Development is tracked on HeptaPod, see
https://foss.heptapod.net/mercurial/mercurial_keyring/
Use issue tracker there for bug reports and enhancement
suggestions.
Thanks to Octobus_ and `Clever Cloud`_ for hosting this service.
Additional notes
=======================================================
Information about this extension is also available
on Mercurial Wiki: https://www.mercurial-scm.org/wiki/KeyringExtension
Check also `other Mercurial extensions I wrote`_.
.. _Octobus: https://octobus.net/
.. _Clever Cloud: https://www.clever-cloud.com/
.. _other Mercurial extensions I wrote: http://code.mekk.waw.pl/mercurial.html
.. _HISTORY.rst: https://foss.heptapod.net/mercurial/mercurial_keyring/src/tip/HISTORY.rst
.. _TortoiseHg: https://foss.heptapod.net/mercurial/tortoisehg/thg
.. _Mercurial: https://www.mercurial-scm.org/
.. _mercurial_extension_utils: https://foss.heptapod.net/mercurial/mercurial-extension_utils/
.. _Path Pattern: https://foss.heptapod.net/mercurial/mercurial-path_pattern/
Raw data
{
"_id": null,
"home_page": "https://foss.heptapod.net/mercurial/mercurial_keyring",
"name": "mercurial-keyring",
"maintainer": null,
"docs_url": null,
"requires_python": null,
"maintainer_email": null,
"keywords": "mercurial hg keyring password",
"author": "Marcin Kasperski",
"author_email": "Marcin.Kasperski@mekk.waw.pl",
"download_url": "https://files.pythonhosted.org/packages/2a/57/f5801cb011c508a38ed331a9abf9c71136c2d616d6d923649f7342772bac/mercurial_keyring-1.4.4.tar.gz",
"platform": null,
"description": ".. -*- mode: rst; compile-command: \"rst2html README.rst README.html\" -*-\n\n=======================================================\nMercurial Keyring\n=======================================================\n\nMercurial Keyring is a Mercurial_ extension used to securely save HTTP\nand SMTP authentication passwords in password databases (Gnome\nKeyring, KDE KWallet, OSXKeyChain, Windows Vault etc).\n\nWith ``mercurial_keyring`` active, Mercurial remembers your passwords\nand reuses them without prompting (as if you stored them in ``.hgrc``),\nbut password storage is reasonably secure.\n\nActual password storage is implemented by the keyring_ library, this \nextension glues it to Mercurial.\n\n.. contents::\n :local:\n :depth: 2\n\n.. sectnum::\n\n.. _keyring: http://pypi.python.org/pypi/keyring\n\nHow does it work\n=======================================================\n\nOn your first pull or push to HTTP url (or first email sent via given\nSMTP server), you are prompted for the password, just like bare\nMercurial does. But the password you entered is saved to appropriate\npassword database. On successive runs, whenever the password is\nneeded, ``mercurial_keyring`` checks for password in password\ndatabase, and uses it without troubling you.\n\nIn case password turns out to be incorrect (for example, because you\nchanged it, or entered it incorrectly), ``mercurial_keyring`` prompts\nyou again, and overwrites the password.\n\nYou can use many passwords (for various remote urls). Saved passwords\nare identified by pair of username and url prefix. See below for\ninformation how to configure those properly.\n\nInstallation\n=======================================================\n\nPrerequisites\n-------------\n\nThis extension requires keyring_ and `mercurial_extension_utils`_ to\nwork. In many cases both will be installed automatically while you\ninstall ``mercurial_keyring``, but you may need to control the process.\n\nThe keyring_ library can usually be installed by::\n\n pip install --user keyring\n\n(or ``easy_install keyring``), but on some systems it is preferable to\nuse official distribution archive. For example, on Debian and Ubuntu,\nyou may install ``python-keyring`` and either ``python-keyring-gnome``\nor ``python-keyring-kwallet`` packages::\n\n sudo apt-get install python-keyring python-keyring-gnome\n\n(this will save you the need to provide working compiler and various\ndevelopment libraries).\n\nThe `mercurial_extension_utils`_ module is tiny Python-only module,\nwhich can be installed by::\n\n pip install --user mercurial_extension_utils\n\nbut in some cases (Windows\u2026) requires more care. See\n`mercurial_extension_utils`_ documentation.\n \n\nExtension installation\n----------------------\n\nThere are two possible ways of installing the extension: using PyPi package,\nor using source clone.\n\nTo install as a package::\n\n pip install --user mercurial_keyring\n\n(or ``sudo pip install mercurial_keyring`` for system-wide\ninstallation) and then enable it in ``~/.hgrc`` (or\n``/etc/mercurial/hgrc`` or ``Mercurial.ini``) using::\n\n [extensions]\n mercurial_keyring = \n\nTo install using source clone, install keyring_ according to the\ninstructions above, then clone::\n \n hg clone https://foss.heptapod.net/mercurial/mercurial_keyring/\n hg clone https://foss.heptapod.net/mercurial/mercurial-extension_utils/\n\nand configure Mercurial using full path to the extension module::\n\n [extensions]\n mercurial_keyring = /path/to/mercurial_keyring/mercurial_keyring.py\n\n.. _the code: \n.. _mercurial_keyring.py: https://foss.heptapod.net/mercurial/mercurial_keyring/src/tip/mercurial_keyring.py\n\nPassword backend configuration\n=======================================================\n\nThe most appropriate password backend should usually be picked without\nconfiguration (considering installed libraries, operating system,\nactive desktop session). Still, if necessary, it can be configured\nusing ``keyringrc.cfg`` file. Refer to keyring_ docs for more\ndetails.\n\n.. note::\n\n With current (as I write) keyring (5.6), this file is (on Linux)\n located at ``~/.local/share/python_keyring/keyringrc.cfg`` and\n it's example content looks like::\n\n [backend]\n default-keyring=keyring.backends.Gnome.Keyring\n # default-keyring=keyring.backends.kwallet.Keyring\n\n For list of known backends run ``pydoc keyring.backends`` or\n ``keyring --list-backends`` (which of those commands work,\n depends on the keyring_ version).\n\n\n``hgrc`` configuration (HTTP)\n=======================================================\n\nMercurial Keyring uses standard Mercurial ``[auth]`` configuration to\ndetect your username (on given remote) and url prefix. You are\nstrongly advised to configure both.\n\nWithout the username ``mercurial_keyring`` can't save or restore\npasswords, so it disables itself.\n\nWithout url prefix ``mercurial_keyring`` works, but binds passwords to\nrepository urls. That means you will have to (re)enter password for\nevery repository cloned from given remote (and that there will be many\ncopies of this password in secure storage).\n\nRepository level configuration\n------------------------------------\n\nEdit repository-local ``.hg/hgrc`` and save there the remote\nrepository path and the username, but do not save the password. For\nexample:\n\n::\n\n [paths]\n myremote = https://my.server.com/hgrepo/someproject\n\n [auth]\n myremote.prefix = https://my.server.com/hgrepo\n myremote.username = John\n\nSimpler form with url-embedded name can also be used:\n\n::\n\n [paths]\n bitbucket = https://John@my.server.com/hgrepo/someproject/\n\nbut is not recommended.\n\nNote that all repositories sharing the same ``prefix`` share the same\npassword.\n\nMercurial allows also for password in ``.hg/hgrc`` (either given by\n``\u00abprefix\u00bb.password``, or embedded in url). If such password is found,\nMercurial Keyring disables itself.\n\n\nAccount-level configuration\n---------------------------\n\nIf you are consistent about remote repository nicknames, you can\nconfigure the username in your `~/.hgrc` (`.hgrc` in your home\ndirectory). For example, write there::\n\n [auth]\n acme.prefix = hg.acme.com/repositories\n acme.username = johnny\n acme.schemes = http https\n heptapod.prefix = https://foss.heptapod.net\n heptapod.username = Mekk\n mydep.prefix = https://dev.acmeorg.com\n mydep.username = drmartin\n\nand as long as you use ``acme`` alias for repositories like\n``https://hg.acme.com/repositories/my_beautiful_app``, username\n``johnny`` will be used, and the same password reused. Similarly\nany ``hg push heptapod`` will assume username ``Mekk`` and share\nthe same password.\n\nWith such config repository-level ``.hg/hgrc`` need only contain\n``[paths]``.\n\nAdditional advantage of this method is that it works also during\n`clone`.\n\n\n.. note::\n\n Mercurial Keyring works well with `Path Pattern`_. On my setup I use\n prefix as above, and::\n\n [path_pattern]\n heptapod.local = ~/devel/mercurial/{below}\n heptapod.remote = https://foss.heptapod.net/mercurial/{below:/=-}\n \n so all my repositories understand ``hg push bitbucket`` without\n any repository-level configuration.\n\n\n``hgrc`` configuration (SMTP)\n=======================================================\n\nEdit either repository-local ``.hg/hgrc``, or ``~/.hgrc`` and set\nthere all standard email and smtp properties, including SMTP\nusername, but without SMTP password. For example:\n\n::\n\n [email]\n method = smtp\n from = Joe Doe <Joe.Doe@remote.com>\n\n [smtp]\n host = smtp.gmail.com\n port = 587\n username = JoeDoe@gmail.com\n tls = true\n\nJust as in case of HTTP, you *must* set username, but *must not* set\npassword here to use the extension, in other cases it will revert to\nthe default behavior.\n\nUsage\n======================================================\n\nSaving and restoring passwords\n-------------------------------------------------------\n\nConfigure the repository as above, then just ``hg pull``, ``hg push``,\netc. You should be asked for the password only once (per every\nusername and remote repository prefix or url combination).\n\nSimilarly, for email, configure as above and just ``hg email``.\nAgain, you will be asked for the password once (per every username and\nemail server address combination).\n\nChecking password status (``hg keyring_check``)\n-------------------------------------------------------\n\nThe ``keyring_check`` command can be used to check whether/which\npassword(s) are saved. It can be used in three ways:\n\n- without parameters, it prints info related to all HTTP paths\n defined for current repository (everything from ``hg paths``\n that resolves to HTTP url)::\n\n hg keyring_check\n\n- given alias as param, it prints info about this alias::\n\n hg keyring_check work\n\n- finally, any path can be checked::\n\n hg keyring_check https://foss.heptapod.net/mercurial/mercurial_keyring\n\nDeleting saved password (``hg keyring_clear``)\n-------------------------------------------------------\n\nThe ``keyring_clear`` command removes saved password related to given\npath. It can be used in two ways:\n\n- given alias as param, it drops password used by this alias::\n\n hg keyring_clear work\n\n- given full path, it drops password related to this path::\n\n hg keyring_clear https://foss.heptapod.net/mercurial/mercurial_keyring\n\nManaging passwords using GUI tools\n------------------------------------------------------\n\nMany password backends provide GUI tools for password management,\nfor example Gnome Keyring passwords can be managed using ``seahorse``,\nand KDE Wallet using ``kwalletmanager``. Those GUI tools can be used\nto review, edit, or delete saved passwords.\n\nUnfortunately, as I write, keyring_ library does not allow one to\nconfigure how/where exactly saved passwords are put in the hierarchy,\nand the place is not always intuitive. For example, in KDE Wallet, all\npasswords saved using ``mercurial_keyring`` show up in the folder\nnamed ``Python``.\n\n.. note::\n\n This is slightly problematic in case ``mercurial_keyring`` is not\n the only program using keyring_ library. Passwords saved by another\n Python application or script (which also uses keyring_) will be put\n into the same place, and it may be unclear which password belongs\n to which program. To remedy this, ``mercurial_keyring`` applies\n slightly unusual labels of the form\n ``\u00abusername\u00bb\ufeff@@\ufeff\u00aburlprefix\u00bb\ufeff@\ufeffMercurial`` - for example my bitbucket\n password is labelled ``Mekk\ufeff@@\ufeffhttps\ufeff://\ufeffbitbucket.org\ufeff@\ufeffMercurial``.\n\nImplementation details\n=======================================================\n\nThe extension is monkey-patching the mercurial ``passwordmgr`` class\nto replace the ``find_user_password`` method. Detailed order of operations\nis described in the comments inside `the code`_.\n\nFrequent problems\n=======================================================\n\nMost problems people face while using ``mercurial_keyring`` are in\nfact problems with ``keyring`` library and it's backends. In\nparticular, those can manifest by:\n\n- technical errors mentioning sentences like ``No recommended backend\n was available. Install the keyrings.alt package\u2026`` (or similar),\n\n- warnings like ``keyring: keyring backend doesn't seem to work\u2026``\n\n- password prompts on every action (= passwords not being saved).\n\nThose almost always mean that *natural* keyring backend for given\ndesktop type doesn't work, or is not present at all. For example,\nsome necessary runtime component can be down (say, you use Linux, but\nneither Gnome Keyring, nor KDE Wallet, is running). Or appropriate\nbackend is not installed because it could not be build during keyring_\nlibrary installation (maybe because some required library was not\npresent at the moment of keyring installation, or maybe because\ncompiler as such is not present on the system).\n\nTo diagnose such problems, try using ``keyring`` utility, as described\non keyring_ documentation page, for example by::\n\n keyring --list-backends\n keyring -b keyrings.alt.Gnome.Keyring set testsvc testuser\n keyring -b keyrings.alt.Gnome.Keyring get testsvc testuser\n\n(of course using appropriate backend). If you miss the ``keyring`` command\nas such, try ``python -m keyring`` instead::\n\n python -m keyring --list-backends\n python -m keyring -b keyrings.alt.Gnome.Keyring set testsvc testuser\n python -m keyring -b keyrings.alt.Gnome.Keyring get testsvc testuser\n\nIf appropriate backend is missing (not listed), or doesn't work\n(second or third command fails), your keyring is broken. Try looking\nfor further pointers in keyring_ documentation, that project mailing\nlist, or issue tracker. Typically it will turn out, that you need to\ninstall some missing tool, or library, and reinstall keyring.\n\n.. note::\n\n Depending on keyring_ version, installation of some dependency may\n resolve problem. For example (as of late 2018), I got KDE Wallet\n backend working with pip-installed keyring after::\n\n pip install dbus-python\n\n Note also, that recent versions of keyring library (since version 12) use Python\n entrypoints to find available backends. Those are incompatible with\n some binary packaging methods (like ``py2app``) and may cause\n problems. In particular there were packaged installations of TortoiseHG_\n which were unable to load keyring backends. See `#61 <https://foss.heptapod.net/mercurial/mercurial_keyring/issues/61/tortoisehg-encounters-unknown-exception>`_ for some more details.\n\n\nIf ``keyring`` command works, but mercurial with mercurial_keyring does not,\ntry enforcing proper backend (by means of ``keyringrc.cfg``, see above).\nOnly if this doesn't help, there may be a bug in mercurial_keyring.\n\nBy far easiest way to have properly working keyring is to use packaged\nbinary version (like ``python-keyring`` Ubuntu package, or keyring\nbundled with TortoiseHG_ on some systems). If you pip-installed keyring\nand it doesn't work, you may consider removing it via ``pip uninstall\nkeyring`` and looking for binary package instead.\n\n\n\n\nHistory\n=======================================================\n\nSee `HISTORY.rst`_.\n\nRepository, bug reports, enhancement suggestions\n===================================================\n\nDevelopment is tracked on HeptaPod, see \nhttps://foss.heptapod.net/mercurial/mercurial_keyring/\n\nUse issue tracker there for bug reports and enhancement\nsuggestions.\n\nThanks to Octobus_ and `Clever Cloud`_ for hosting this service.\n\n\n\nAdditional notes\n=======================================================\n\nInformation about this extension is also available\non Mercurial Wiki: https://www.mercurial-scm.org/wiki/KeyringExtension\n\nCheck also `other Mercurial extensions I wrote`_.\n\n.. _Octobus: https://octobus.net/\n.. _Clever Cloud: https://www.clever-cloud.com/\n\n.. _other Mercurial extensions I wrote: http://code.mekk.waw.pl/mercurial.html\n\n.. _HISTORY.rst: https://foss.heptapod.net/mercurial/mercurial_keyring/src/tip/HISTORY.rst\n.. _TortoiseHg: https://foss.heptapod.net/mercurial/tortoisehg/thg\n.. _Mercurial: https://www.mercurial-scm.org/\n.. _mercurial_extension_utils: https://foss.heptapod.net/mercurial/mercurial-extension_utils/\n.. _Path Pattern: https://foss.heptapod.net/mercurial/mercurial-path_pattern/\n\n\n",
"bugtrack_url": null,
"license": "BSD",
"summary": "Mercurial Keyring Extension",
"version": "1.4.4",
"project_urls": {
"Homepage": "https://foss.heptapod.net/mercurial/mercurial_keyring"
},
"split_keywords": [
"mercurial",
"hg",
"keyring",
"password"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "2a57f5801cb011c508a38ed331a9abf9c71136c2d616d6d923649f7342772bac",
"md5": "26884e2a1604d1a6e44a9161fbf953dd",
"sha256": "1d113955c57e3230957cbe71e8929d97d2c7edc83d16321b7bd95fa13be4f302"
},
"downloads": -1,
"filename": "mercurial_keyring-1.4.4.tar.gz",
"has_sig": false,
"md5_digest": "26884e2a1604d1a6e44a9161fbf953dd",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 26604,
"upload_time": "2024-06-15T20:34:29",
"upload_time_iso_8601": "2024-06-15T20:34:29.026203Z",
"url": "https://files.pythonhosted.org/packages/2a/57/f5801cb011c508a38ed331a9abf9c71136c2d616d6d923649f7342772bac/mercurial_keyring-1.4.4.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-06-15 20:34:29",
"github": false,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"lcname": "mercurial-keyring"
}
JSON