/usr/share/pyshared/mercurial_keyring-0.6.1.egg-info/PKG-INFO is in mercurial-keyring 0.6.1-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 | Metadata-Version: 1.1
Name: mercurial-keyring
Version: 0.6.1
Summary: Mercurial Keyring Extension
Home-page: http://bitbucket.org/Mekk/mercurial_keyring
Author: Marcin Kasperski
Author-email: Marcin.Kasperski@mekk.waw.pl
License: BSD
Description: .. -*- mode: rst -*-
=================
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, specific solutions for Win32 and
command line). This extension uses and wraps services of the keyring_
library.
.. _keyring: http://pypi.python.org/pypi/keyring
.. _Mercurial: http://mercurial.selenic.com
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. On successive runs 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
-------------
Install the keyring_ library:
::
easy_install keyring
(or ``pip keyring``). On Debian "Sid" the library can be also
installed from the official archive (packages ``python-keyring``
and either ``python-keyring-gnome`` or ``python-keyring-kwallet``).
Note: keyring >= 0.3 is strongly recommended, especially in case text
backend is to be used.
.. _this keyring fork: https://bitbucket.org/sborho/python-keyring-lib
Extension installation
----------------------
There are two possible ways of installing the extension: using PyPi package,
or using individual file.
To install as a package use ``easy_install``:
::
easy_install mercurial_keyring
and then enable it in ``~/.hgrc`` (or ``/etc/mercurial/hgrc``) using:
::
[extensions]
mercurial_keyring =
To install using individual file, download the
`mercurial_keyring.py`_ file, save it anywhere you like, and
put the following in ``~/.hgrc`` (or ``/etc/mercurial/hgrc``):
::
[extensions]
hgext.mercurial_keyring = /path/to/mercurial_keyring.py
.. _the code:
.. _mercurial_keyring.py: http://bitbucket.org/Mekk/mercurial_keyring/src/tip/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`_.
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
Keywords: mercurial hg keyring password
Platform: UNKNOWN
Classifier: Development Status :: 4 - Beta
Classifier: Environment :: Console
Classifier: Intended Audience :: Developers
Classifier: License :: DFSG approved
Classifier: License :: OSI Approved :: BSD License
Classifier: Operating System :: OS Independent
Classifier: Topic :: Software Development :: Libraries
Classifier: Topic :: Software Development :: Libraries :: Python Modules
Classifier: Topic :: Software Development :: Version Control
|