##// END OF EJS Templates
ToC in README
Marcin Kasperski -
r190:ed776eb5 default
parent child Browse files
Show More
@@ -1,273 +1,279 b''
1 1 .. -*- mode: rst; compile-command: "rst2html README.txt README.html" -*-
2 2
3 3 =================
4 4 Mercurial Keyring
5 5 =================
6 6
7 7 Mercurial Keyring is a Mercurial_ extension used to securely save HTTP
8 8 and SMTP authentication passwords in password databases (Gnome
9 9 Keyring, KDE KWallet, OSXKeyChain, Windows Vault etc).
10 10
11 11 With ``mercurial_keyring`` active, Mercurial remembers your passwords
12 12 and reuses them without prompting (as if you stored them in ``.hgrc``),
13 13 but password storage is reasonably secure.
14 14
15 15 Actual password storage is implemented by the keyring_ library, this
16 16 extension glues it to Mercurial.
17 17
18 .. contents::
19 :local:
20 :depth: 2
21
22 .. sectnum::
23
18 24 .. _keyring: http://pypi.python.org/pypi/keyring
19 25 .. _Mercurial: http://mercurial.selenic.com
20 26
21 27 How does it work
22 28 ================
23 29
24 30 On your first pull or push to HTTP url (or first email sent via given
25 31 SMTP server), you are prompted for the password, just like bare
26 32 Mercurial does. But the password you entered is saved to appropriate
27 33 password database. On successive runs, whenever the password is
28 34 needed, ``mercurial_keyring`` checks for password in password
29 35 database, and uses it without troubling you.
30 36
31 37 In case password turns out to be incorrect (for example, because you
32 38 changed it, or entered it incorrectly), ``mercurial_keyring`` wipes
33 39 it, and prompts you again.
34 40
35 41 You can use many passwords (for various remote urls). Saved passwords
36 42 are identified by pair of username and url prefix. See below for
37 43 information how to configure those properly.
38 44
39 45 Installation
40 46 ============
41 47
42 48 Prerequisites
43 49 -------------
44 50
45 51 This extension requires keyring_ and `mercurial_extension_utils`_ to
46 52 work. In many cases both will be installed automatically while you
47 53 install ``mercurial_keyring``, but you may need to control the process.
48 54
49 55 The keyring_ library can usually be installed by::
50 56
51 57 pip install --user keyring
52 58
53 59 (or ``easy_install keyring``), but on some systems it is preferable to
54 60 use official distribution archive. For example, on Debian and Ubuntu,
55 61 you may install ``python-keyring`` and either ``python-keyring-gnome``
56 62 or ``python-keyring-kwallet`` packages::
57 63
58 64 sudo apt-get install python-keyring python-keyring-gnome
59 65
60 66 (this will save you the need to provide working compiler and various
61 67 development libraries).
62 68
63 69 The `mercurial_extension_utils`_ module is tiny Python-only module,
64 70 which can be installed by::
65 71
66 72 pip install --user mercurial_extension_utils
67 73
68 74 but in some cases (Windows…) require more care. See
69 75 `mercurial_extension_utils`_ documentation.
70 76
71 77
72 78 Extension installation
73 79 ----------------------
74 80
75 81 There are two possible ways of installing the extension: using PyPi package,
76 82 or using source clone.
77 83
78 84 To install as a package::
79 85
80 86 pip install --user mercurial_keyring
81 87
82 88 (or ``sudo pip install mercurial_keyring`` for system-wide
83 89 installation) and then enable it in ``~/.hgrc`` (or
84 90 ``/etc/mercurial/hgrc`` or ``Mercurial.ini``) using::
85 91
86 92 [extensions]
87 93 mercurial_keyring =
88 94
89 95 To install as source clone, install keyring_ according to instructions above, then
90 96 clone::
91 97
92 98 hg clone https://bitbucket.org/Mekk/mercurial_keyring/
93 99 hg clone https://bitbucket.org/Mekk/mercurial-extension_utils/
94 100
95 101 and configure Mercurial by telling it full path to the extension
96 102 (in )::
97 103
98 104 [extensions]
99 105 mercurial_keyring = /path/to/mercurial_keyring/mercurial_keyring.py
100 106
101 107 .. _the code:
102 108 .. _mercurial_keyring.py: http://bitbucket.org/Mekk/mercurial_keyring/src/tip/mercurial_keyring.py
103 109
104 110 Password backend configuration
105 111 ==============================
106 112
107 113 The library should usually pick the most appropriate password backend
108 114 without configuration. Still, if necessary, it can be configured using
109 115 ``keyringrc.cfg`` file. Refer to keyring_ docs for more details.
110 116
111 117 .. note::
112 118
113 119 With current (as I write) keyring (5.6), this file is (on Linux)
114 120 located at ``~/.local/share/python_keyring/keyringrc.cfg`` and
115 121 it's example content look like::
116 122
117 123 [backend]
118 124 default-keyring=keyring.backends.Gnome.Keyring
119 125 # default-keyring=keyring.backends.kwallet.Keyring
120 126
121 127 For list of known backends run ``pydoc keyring.backends``.
122 128
123 129
124 130 ``hgrc`` configuration (HTTP)
125 131 ===============================
126 132
127 133 Mercurial Keyring uses standard Mercurial ``[auth]`` configuration to
128 134 detect your username (on given remote) and url prefix. You are
129 135 strongly advised to configure both.
130 136
131 137 Without the username ``mercurial_keyring`` can't save or restore
132 138 passwords, so it disables itself.
133 139
134 140 Without url prefix ``mercurial_keyring`` works, but binds passwords to
135 141 repository urls. That means you will have to (re)enter password for
136 142 every repository cloned from given remote (and that there will be many
137 143 copies of this password in secure storage).
138 144
139 145 Repository level configuration
140 146 ------------------------------------
141 147
142 148 Edit repository-local ``.hg/hgrc`` and save there the remote
143 149 repository path and the username, but do not save the password. For
144 150 example:
145 151
146 152 ::
147 153
148 154 [paths]
149 155 myremote = https://my.server.com/hgrepo/someproject
150 156
151 157 [auth]
152 158 myremote.prefix = https://my.server.com/hgrepo
153 159 myremote.username = John
154 160
155 161 Simpler form with url-embedded name can also be used:
156 162
157 163 ::
158 164
159 165 [paths]
160 166 bitbucket = https://John@my.server.com/hgrepo/someproject/
161 167
162 168 Note that all repositories sharing the same ``prefix`` share the same
163 169 password.
164 170
165 171 Mercurial allows also for password in ``.hg/hgrc`` (either given by
166 172 ``Β«prefixΒ».password``, or embedded in url). If such password is found,
167 173 Mercurial Keyring disables itself.
168 174
169 175
170 176 Account-level configuration
171 177 ---------------------------
172 178
173 179 If you are consistent about remote repository nicknames, you can
174 180 configure the username in your `~/.hgrc` (`.hgrc` in your home
175 181 directory). For example, write there::
176 182
177 183 [auth]
178 184 acme.prefix = hg.acme.com/repositories
179 185 acme.username = johnny
180 186 acme.schemes = http https
181 187 bitbucket.prefix = https://bitbucket.org
182 188 bitbucket.username = Mekk
183 189 mydep.prefix = https://dev.acmeorg.com
184 190 mydep.username = drmartin
185 191
186 192 and as long as you will be using alias ``acme`` for repositories like
187 193 ``https://hg.acme.com/repositories/my_beautiful_app``, username
188 194 ``johnny`` will be used, and the same password reused. Similarly
189 195 any ``hg push bitbucket`` will share the same password.
190 196
191 197 With such config repository-level ``.hg/hgrc`` need only contain
192 198 ``[paths]``.
193 199
194 200 Additional advantage of this method is that it works also during
195 201 `clone`.
196 202
197 203
198 204 .. note::
199 205
200 206 Mercurial Keyring works well with `Path Pattern`_. On my setup I use::
201 207
202 208 [path_pattern]
203 209 bitbucket.local = ~/devel/{below}
204 210 bitbucket.remote = https://bitbucket.org/Mekk/{below:/=-}
205 211
206 212 so all my repositories understand ``hg push bitbucket`` without
207 213 any repository-level configuration.
208 214
209 215
210 216 ``hgrc`` configuration (SMTP)
211 217 ===============================
212 218
213 219 Edit either repository-local ``.hg/hgrc``, or ``~/.hgrc`` and set
214 220 there all standard email and smtp properties, including SMTP
215 221 username, but without SMTP password. For example:
216 222
217 223 ::
218 224
219 225 [email]
220 226 method = smtp
221 227 from = Joe Doe <Joe.Doe@remote.com>
222 228
223 229 [smtp]
224 230 host = smtp.gmail.com
225 231 port = 587
226 232 username = JoeDoe@gmail.com
227 233 tls = true
228 234
229 235 Just as in case of HTTP, you *must* set username, but *must not* set
230 236 password here to use the extension, in other cases it will revert to
231 237 the default behavior.
232 238
233 239 Usage
234 240 =====
235 241
236 242 Configure the repository as above, then just ``hg pull``, ``hg push``,
237 243 etc. You should be asked for the password only once (per every
238 244 username and remote repository prefix or url combination).
239 245
240 246 Similarly, for email, configure as above and just ``hg email``.
241 247 Again, you will be asked for the password once (per every username and
242 248 email server address combination).
243 249
244 250 Implementation details
245 251 ======================
246 252
247 253 The extension is monkey-patching the mercurial ``passwordmgr`` class
248 254 to replace the ``find_user_password`` method. Detailed order of operations
249 255 is described in the comments inside `the code`_.
250 256
251 257 History
252 258 ==========
253 259
254 260 See `HISTORY.txt`_.
255 261
256 262 Development
257 263 ===========
258 264
259 265 Development is tracked on BitBucket, see
260 266 http://bitbucket.org/Mekk/mercurial_keyring/
261 267
262 268
263 269 Additional notes
264 270 ================
265 271
266 272 Information about this extension is also available
267 273 on Mercurial Wiki: http://mercurial.selenic.com/wiki/KeyringExtension
268 274
269 275 .. _HISTORY.txt: http://bitbucket.org/Mekk/mercurial_keyring/src/tip/HISTORY.txt
270 276 .. _TortoiseHg: http://tortoisehg.bitbucket.org/
271 277 .. _Mercurial: http://mercurial.selenic.com
272 278 .. _mercurial_extension_utils: https://bitbucket.org/Mekk/mercurial-extension_utils/
273 279 .. _Path Pattern: https://bitbucket.org/Mekk/mercurial-path_pattern/
General Comments 0
You need to be logged in to leave comments. Login now