Show More
@@ -1,430 +1,430 b'' | |||
|
1 | 1 | .. -*- mode: rst; compile-command: "rst2html README.rst 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 | 18 | .. contents:: |
|
19 | 19 | :local: |
|
20 | 20 | :depth: 2 |
|
21 | 21 | |
|
22 | 22 | .. sectnum:: |
|
23 | 23 | |
|
24 | 24 | .. _keyring: http://pypi.python.org/pypi/keyring |
|
25 | 25 | |
|
26 | 26 | How does it work |
|
27 | 27 | ======================================================= |
|
28 | 28 | |
|
29 | 29 | On your first pull or push to HTTP url (or first email sent via given |
|
30 | 30 | SMTP server), you are prompted for the password, just like bare |
|
31 | 31 | Mercurial does. But the password you entered is saved to appropriate |
|
32 | 32 | password database. On successive runs, whenever the password is |
|
33 | 33 | needed, ``mercurial_keyring`` checks for password in password |
|
34 | 34 | database, and uses it without troubling you. |
|
35 | 35 | |
|
36 | 36 | In case password turns out to be incorrect (for example, because you |
|
37 | 37 | changed it, or entered it incorrectly), ``mercurial_keyring`` prompts |
|
38 | 38 | you again, and overwrites the password. |
|
39 | 39 | |
|
40 | 40 | You can use many passwords (for various remote urls). Saved passwords |
|
41 | 41 | are identified by pair of username and url prefix. See below for |
|
42 | 42 | information how to configure those properly. |
|
43 | 43 | |
|
44 | 44 | Installation |
|
45 | 45 | ======================================================= |
|
46 | 46 | |
|
47 | 47 | Prerequisites |
|
48 | 48 | ------------- |
|
49 | 49 | |
|
50 | 50 | This extension requires keyring_ and `mercurial_extension_utils`_ to |
|
51 | 51 | work. In many cases both will be installed automatically while you |
|
52 | 52 | install ``mercurial_keyring``, but you may need to control the process. |
|
53 | 53 | |
|
54 | 54 | The keyring_ library can usually be installed by:: |
|
55 | 55 | |
|
56 | 56 | pip install --user keyring |
|
57 | 57 | |
|
58 | 58 | (or ``easy_install keyring``), but on some systems it is preferable to |
|
59 | 59 | use official distribution archive. For example, on Debian and Ubuntu, |
|
60 | 60 | you may install ``python-keyring`` and either ``python-keyring-gnome`` |
|
61 | 61 | or ``python-keyring-kwallet`` packages:: |
|
62 | 62 | |
|
63 | 63 | sudo apt-get install python-keyring python-keyring-gnome |
|
64 | 64 | |
|
65 | 65 | (this will save you the need to provide working compiler and various |
|
66 | 66 | development libraries). |
|
67 | 67 | |
|
68 | 68 | The `mercurial_extension_utils`_ module is tiny Python-only module, |
|
69 | 69 | which can be installed by:: |
|
70 | 70 | |
|
71 | 71 | pip install --user mercurial_extension_utils |
|
72 | 72 | |
|
73 | 73 | but in some cases (Windowsβ¦) requires more care. See |
|
74 | 74 | `mercurial_extension_utils`_ documentation. |
|
75 | 75 | |
|
76 | 76 | |
|
77 | 77 | Extension installation |
|
78 | 78 | ---------------------- |
|
79 | 79 | |
|
80 | 80 | There are two possible ways of installing the extension: using PyPi package, |
|
81 | 81 | or using source clone. |
|
82 | 82 | |
|
83 | 83 | To install as a package:: |
|
84 | 84 | |
|
85 | 85 | pip install --user mercurial_keyring |
|
86 | 86 | |
|
87 | 87 | (or ``sudo pip install mercurial_keyring`` for system-wide |
|
88 | 88 | installation) and then enable it in ``~/.hgrc`` (or |
|
89 | 89 | ``/etc/mercurial/hgrc`` or ``Mercurial.ini``) using:: |
|
90 | 90 | |
|
91 | 91 | [extensions] |
|
92 | 92 | mercurial_keyring = |
|
93 | 93 | |
|
94 | 94 | To install using source clone, install keyring_ according to the |
|
95 | 95 | instructions above, then clone:: |
|
96 | 96 | |
|
97 | 97 | hg clone https://foss.heptapod.net/mercurial/mercurial_keyring/ |
|
98 | 98 | hg clone https://foss.heptapod.net/mercurial/mercurial-extension_utils/ |
|
99 | 99 | |
|
100 | 100 | and configure Mercurial using full path to the extension module:: |
|
101 | 101 | |
|
102 | 102 | [extensions] |
|
103 | 103 | mercurial_keyring = /path/to/mercurial_keyring/mercurial_keyring.py |
|
104 | 104 | |
|
105 | 105 | .. _the code: |
|
106 | 106 | .. _mercurial_keyring.py: https://foss.heptapod.net/mercurial/mercurial_keyring/src/tip/mercurial_keyring.py |
|
107 | 107 | |
|
108 | 108 | Password backend configuration |
|
109 | 109 | ======================================================= |
|
110 | 110 | |
|
111 | 111 | The most appropriate password backend should usually be picked without |
|
112 | 112 | configuration (considering installed libraries, operating system, |
|
113 | 113 | active desktop session). Still, if necessary, it can be configured |
|
114 | 114 | using ``keyringrc.cfg`` file. Refer to keyring_ docs for more |
|
115 | 115 | details. |
|
116 | 116 | |
|
117 | 117 | .. note:: |
|
118 | 118 | |
|
119 | 119 | With current (as I write) keyring (5.6), this file is (on Linux) |
|
120 | 120 | located at ``~/.local/share/python_keyring/keyringrc.cfg`` and |
|
121 | 121 | it's example content looks like:: |
|
122 | 122 | |
|
123 | 123 | [backend] |
|
124 | 124 | default-keyring=keyring.backends.Gnome.Keyring |
|
125 | 125 | # default-keyring=keyring.backends.kwallet.Keyring |
|
126 | 126 | |
|
127 | 127 | For list of known backends run ``pydoc keyring.backends`` or |
|
128 | 128 | ``keyring --list-backends`` (which of those commands work, |
|
129 | 129 | depends on the keyring_ version). |
|
130 | 130 | |
|
131 | 131 | |
|
132 | 132 | ``hgrc`` configuration (HTTP) |
|
133 | 133 | ======================================================= |
|
134 | 134 | |
|
135 | 135 | Mercurial Keyring uses standard Mercurial ``[auth]`` configuration to |
|
136 | 136 | detect your username (on given remote) and url prefix. You are |
|
137 | 137 | strongly advised to configure both. |
|
138 | 138 | |
|
139 | 139 | Without the username ``mercurial_keyring`` can't save or restore |
|
140 | 140 | passwords, so it disables itself. |
|
141 | 141 | |
|
142 | 142 | Without url prefix ``mercurial_keyring`` works, but binds passwords to |
|
143 | 143 | repository urls. That means you will have to (re)enter password for |
|
144 | 144 | every repository cloned from given remote (and that there will be many |
|
145 | 145 | copies of this password in secure storage). |
|
146 | 146 | |
|
147 | 147 | Repository level configuration |
|
148 | 148 | ------------------------------------ |
|
149 | 149 | |
|
150 | 150 | Edit repository-local ``.hg/hgrc`` and save there the remote |
|
151 | 151 | repository path and the username, but do not save the password. For |
|
152 | 152 | example: |
|
153 | 153 | |
|
154 | 154 | :: |
|
155 | 155 | |
|
156 | 156 | [paths] |
|
157 | 157 | myremote = https://my.server.com/hgrepo/someproject |
|
158 | 158 | |
|
159 | 159 | [auth] |
|
160 | 160 | myremote.prefix = https://my.server.com/hgrepo |
|
161 | 161 | myremote.username = John |
|
162 | 162 | |
|
163 | 163 | Simpler form with url-embedded name can also be used: |
|
164 | 164 | |
|
165 | 165 | :: |
|
166 | 166 | |
|
167 | 167 | [paths] |
|
168 | 168 | bitbucket = https://John@my.server.com/hgrepo/someproject/ |
|
169 | 169 | |
|
170 | 170 | but is not recommended. |
|
171 | 171 | |
|
172 | 172 | Note that all repositories sharing the same ``prefix`` share the same |
|
173 | 173 | password. |
|
174 | 174 | |
|
175 | 175 | Mercurial allows also for password in ``.hg/hgrc`` (either given by |
|
176 | 176 | ``Β«prefixΒ».password``, or embedded in url). If such password is found, |
|
177 | 177 | Mercurial Keyring disables itself. |
|
178 | 178 | |
|
179 | 179 | |
|
180 | 180 | Account-level configuration |
|
181 | 181 | --------------------------- |
|
182 | 182 | |
|
183 | 183 | If you are consistent about remote repository nicknames, you can |
|
184 | 184 | configure the username in your `~/.hgrc` (`.hgrc` in your home |
|
185 | 185 | directory). For example, write there:: |
|
186 | 186 | |
|
187 | 187 | [auth] |
|
188 | 188 | acme.prefix = hg.acme.com/repositories |
|
189 | 189 | acme.username = johnny |
|
190 | 190 | acme.schemes = http https |
|
191 | 191 | bitbucket.prefix = https://bitbucket.org |
|
192 | 192 | bitbucket.username = Mekk |
|
193 | 193 | mydep.prefix = https://dev.acmeorg.com |
|
194 | 194 | mydep.username = drmartin |
|
195 | 195 | |
|
196 | 196 | and as long as you use ``acme`` alias for repositories like |
|
197 | 197 | ``https://hg.acme.com/repositories/my_beautiful_app``, username |
|
198 | 198 | ``johnny`` will be used, and the same password reused. Similarly |
|
199 | 199 | any ``hg push bitbucket`` will share the same password. |
|
200 | 200 | |
|
201 | 201 | With such config repository-level ``.hg/hgrc`` need only contain |
|
202 | 202 | ``[paths]``. |
|
203 | 203 | |
|
204 | 204 | Additional advantage of this method is that it works also during |
|
205 | 205 | `clone`. |
|
206 | 206 | |
|
207 | 207 | |
|
208 | 208 | .. note:: |
|
209 | 209 | |
|
210 | 210 | Mercurial Keyring works well with `Path Pattern`_. On my setup I use |
|
211 | 211 | prefix as above, and:: |
|
212 | 212 | |
|
213 | 213 | [path_pattern] |
|
214 | 214 | bitbucket.local = ~/devel/{below} |
|
215 | 215 | bitbucket.remote = https://bitbucket.org/Mekk/{below:/=-} |
|
216 | 216 | |
|
217 | 217 | so all my repositories understand ``hg push bitbucket`` without |
|
218 | 218 | any repository-level configuration. |
|
219 | 219 | |
|
220 | 220 | |
|
221 | 221 | ``hgrc`` configuration (SMTP) |
|
222 | 222 | ======================================================= |
|
223 | 223 | |
|
224 | 224 | Edit either repository-local ``.hg/hgrc``, or ``~/.hgrc`` and set |
|
225 | 225 | there all standard email and smtp properties, including SMTP |
|
226 | 226 | username, but without SMTP password. For example: |
|
227 | 227 | |
|
228 | 228 | :: |
|
229 | 229 | |
|
230 | 230 | [email] |
|
231 | 231 | method = smtp |
|
232 | 232 | from = Joe Doe <Joe.Doe@remote.com> |
|
233 | 233 | |
|
234 | 234 | [smtp] |
|
235 | 235 | host = smtp.gmail.com |
|
236 | 236 | port = 587 |
|
237 | 237 | username = JoeDoe@gmail.com |
|
238 | 238 | tls = true |
|
239 | 239 | |
|
240 | 240 | Just as in case of HTTP, you *must* set username, but *must not* set |
|
241 | 241 | password here to use the extension, in other cases it will revert to |
|
242 | 242 | the default behavior. |
|
243 | 243 | |
|
244 | 244 | Usage |
|
245 | 245 | ====================================================== |
|
246 | 246 | |
|
247 | 247 | Saving and restoring passwords |
|
248 | 248 | ------------------------------------------------------- |
|
249 | 249 | |
|
250 | 250 | Configure the repository as above, then just ``hg pull``, ``hg push``, |
|
251 | 251 | etc. You should be asked for the password only once (per every |
|
252 | 252 | username and remote repository prefix or url combination). |
|
253 | 253 | |
|
254 | 254 | Similarly, for email, configure as above and just ``hg email``. |
|
255 | 255 | Again, you will be asked for the password once (per every username and |
|
256 | 256 | email server address combination). |
|
257 | 257 | |
|
258 | 258 | Checking password status (``hg keyring_check``) |
|
259 | 259 | ------------------------------------------------------- |
|
260 | 260 | |
|
261 | 261 | The ``keyring_check`` command can be used to check whether/which |
|
262 | 262 | password(s) are saved. It can be used in three ways: |
|
263 | 263 | |
|
264 | 264 | - without parameters, it prints info related to all HTTP paths |
|
265 | 265 | defined for current repository (everything from ``hg paths`` |
|
266 | 266 | that resolves to HTTP url):: |
|
267 | 267 | |
|
268 | 268 | hg keyring_check |
|
269 | 269 | |
|
270 | 270 | - given alias as param, it prints info about this alias:: |
|
271 | 271 | |
|
272 | 272 | hg keyring_check work |
|
273 | 273 | |
|
274 | 274 | - finally, any path can be checked:: |
|
275 | 275 | |
|
276 | 276 | hg keyring_check https://foss.heptapod.net/mercurial/mercurial_keyring |
|
277 | 277 | |
|
278 | 278 | Deleting saved password (``hg keyring_clear``) |
|
279 | 279 | ------------------------------------------------------- |
|
280 | 280 | |
|
281 | 281 | The ``keyring_clear`` command removes saved password related to given |
|
282 | 282 | path. It can be used in two ways: |
|
283 | 283 | |
|
284 | 284 | - given alias as param, it drops password used by this alias:: |
|
285 | 285 | |
|
286 | 286 | hg keyring_clear work |
|
287 | 287 | |
|
288 | 288 | - given full path, it drops password related to this path:: |
|
289 | 289 | |
|
290 | 290 | hg keyring_clear https://foss.heptapod.net/mercurial/mercurial_keyring |
|
291 | 291 | |
|
292 | 292 | Managing passwords using GUI tools |
|
293 | 293 | ------------------------------------------------------ |
|
294 | 294 | |
|
295 | 295 | Many password backends provide GUI tools for password management, |
|
296 | 296 | for example Gnome Keyring passwords can be managed using ``seahorse``, |
|
297 | 297 | and KDE Wallet using ``kwalletmanager``. Those GUI tools can be used |
|
298 | 298 | to review, edit, or delete saved passwords. |
|
299 | 299 | |
|
300 | 300 | Unfortunately, as I write, keyring_ library does not allow one to |
|
301 | 301 | configure how/where exactly saved passwords are put in the hierarchy, |
|
302 | 302 | and the place is not always intuitive. For example, in KDE Wallet, all |
|
303 | 303 | passwords saved using ``mercurial_keyring`` show up in the folder |
|
304 | 304 | named ``Python``. |
|
305 | 305 | |
|
306 | 306 | .. note:: |
|
307 | 307 | |
|
308 | 308 | This is slightly problematic in case ``mercurial_keyring`` is not |
|
309 | 309 | the only program using keyring_ library. Passwords saved by another |
|
310 | 310 | Python application or script (which also uses keyring_) will be put |
|
311 | 311 | into the same place, and it may be unclear which password belongs |
|
312 | 312 | to which program. To remedy this, ``mercurial_keyring`` applies |
|
313 | 313 | slightly unusual labels of the form |
|
314 | 314 | ``Β«usernameΒ»ο»Ώ@@ο»ΏΒ«urlprefixΒ»ο»Ώ@ο»ΏMercurial`` - for example my bitbucket |
|
315 | 315 | password is labelled ``Mekkο»Ώ@@ο»Ώhttpsο»Ώ://ο»Ώbitbucket.orgο»Ώ@ο»ΏMercurial``. |
|
316 | 316 | |
|
317 | 317 | Implementation details |
|
318 | 318 | ======================================================= |
|
319 | 319 | |
|
320 | 320 | The extension is monkey-patching the mercurial ``passwordmgr`` class |
|
321 | 321 | to replace the ``find_user_password`` method. Detailed order of operations |
|
322 | 322 | is described in the comments inside `the code`_. |
|
323 | 323 | |
|
324 | 324 | Frequent problems |
|
325 | 325 | ======================================================= |
|
326 | 326 | |
|
327 | 327 | Most problems people face while using ``mercurial_keyring`` are in |
|
328 | 328 | fact problems with ``keyring`` library and it's backends. In |
|
329 | 329 | particular, those can manifest by: |
|
330 | 330 | |
|
331 | 331 | - technical errors mentioning sentences like ``No recommended backend |
|
332 | 332 | was available. Install the keyrings.alt packageβ¦`` (or similar), |
|
333 | 333 | |
|
334 | 334 | - warnings like ``keyring: keyring backend doesn't seem to workβ¦`` |
|
335 | 335 | |
|
336 | 336 | - password prompts on every action (= passwords not being saved). |
|
337 | 337 | |
|
338 | 338 | Those almost always mean that *natural* keyring backend for given |
|
339 | 339 | desktop type doesn't work, or is not present at all. For example, |
|
340 | 340 | some necessary runtime component can be down (say, you use Linux, but |
|
341 | 341 | neither Gnome Keyring, nor KDE Wallet, is running). Or appropriate |
|
342 | 342 | backend is not installed because it could not be build during keyring_ |
|
343 | 343 | library installation (maybe because some required library was not |
|
344 | 344 | present at the moment of keyring installation, or maybe because |
|
345 | 345 | compiler as such is not present on the system). |
|
346 | 346 | |
|
347 | 347 | To diagnose such problems, try using ``keyring`` utility, as described |
|
348 | 348 | on keyring_ documentation page, for example by:: |
|
349 | 349 | |
|
350 | 350 | keyring --list-backends |
|
351 | 351 | keyring -b keyrings.alt.Gnome.Keyring set testsvc testuser |
|
352 | 352 | keyring -b keyrings.alt.Gnome.Keyring get testsvc testuser |
|
353 | 353 | |
|
354 | 354 | (of course using appropriate backend). If you miss the ``keyring`` command |
|
355 | 355 | as such, try ``python -m keyring`` instead:: |
|
356 | 356 | |
|
357 | 357 | python -m keyring --list-backends |
|
358 | 358 | python -m keyring -b keyrings.alt.Gnome.Keyring set testsvc testuser |
|
359 | 359 | python -m keyring -b keyrings.alt.Gnome.Keyring get testsvc testuser |
|
360 | 360 | |
|
361 | 361 | If appropriate backend is missing (not listed), or doesn't work |
|
362 | 362 | (second or third command fails), your keyring is broken. Try looking |
|
363 | 363 | for further pointers in keyring_ documentation, that project mailing |
|
364 | 364 | list, or issue tracker. Typically it will turn out, that you need to |
|
365 | 365 | install some missing tool, or library, and reinstall keyring. |
|
366 | 366 | |
|
367 | 367 | .. note:: |
|
368 | 368 | |
|
369 | 369 | Depending on keyring_ version, installation of some dependency may |
|
370 | 370 | resolve problem. For example (as of late 2018), I got KDE Wallet |
|
371 | 371 | backend working with pip-installed keyring after:: |
|
372 | 372 | |
|
373 | 373 | pip install dbus-python |
|
374 | 374 | |
|
375 | 375 | Note also, that recent versions of keyring library (since version 12) use Python |
|
376 | 376 | entrypoints to find available backends. Those are incompatible with |
|
377 | 377 | some binary packaging methods (like ``py2app``) and may cause |
|
378 | problems. In particular there were packaged installations of TortoiseHG | |
|
378 | problems. In particular there were packaged installations of TortoiseHG_ | |
|
379 | 379 | 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. |
|
380 | 380 | |
|
381 | 381 | |
|
382 | 382 | If ``keyring`` command works, but mercurial with mercurial_keyring does not, |
|
383 | 383 | try enforcing proper backend (by means of ``keyringrc.cfg``, see above). |
|
384 | 384 | Only if this doesn't help, there may be a bug in mercurial_keyring. |
|
385 | 385 | |
|
386 | 386 | By far easiest way to have properly working keyring is to use packaged |
|
387 | 387 | binary version (like ``python-keyring`` Ubuntu package, or keyring |
|
388 | bundled with TortoiseHG on some systems). If you pip-installed keyring | |
|
388 | bundled with TortoiseHG_ on some systems). If you pip-installed keyring | |
|
389 | 389 | and it doesn't work, you may consider removing it via ``pip uninstall |
|
390 | 390 | keyring`` and looking for binary package instead. |
|
391 | 391 | |
|
392 | 392 | |
|
393 | 393 | |
|
394 | 394 | |
|
395 | 395 | History |
|
396 | 396 | ======================================================= |
|
397 | 397 | |
|
398 | 398 | See `HISTORY.rst`_. |
|
399 | 399 | |
|
400 | 400 | Repository, bug reports, enhancement suggestions |
|
401 | 401 | =================================================== |
|
402 | 402 | |
|
403 | 403 | Development is tracked on HeptaPod, see |
|
404 | 404 | https://foss.heptapod.net/mercurial/mercurial_keyring/ |
|
405 | 405 | |
|
406 | 406 | Use issue tracker there for bug reports and enhancement |
|
407 | 407 | suggestions. |
|
408 | 408 | |
|
409 | 409 | Thanks to Octobus_ and `Clever Cloud`_ for hosting this service. |
|
410 | 410 | |
|
411 | 411 | |
|
412 | 412 | |
|
413 | 413 | Additional notes |
|
414 | 414 | ======================================================= |
|
415 | 415 | |
|
416 | 416 | Information about this extension is also available |
|
417 | 417 | on Mercurial Wiki: https://www.mercurial-scm.org/wiki/KeyringExtension |
|
418 | 418 | |
|
419 | 419 | Check also `other Mercurial extensions I wrote`_. |
|
420 | 420 | |
|
421 | 421 | .. _Octobus: https://octobus.net/ |
|
422 | 422 | .. _Clever Cloud: https://www.clever-cloud.com/ |
|
423 | 423 | |
|
424 | 424 | .. _other Mercurial extensions I wrote: http://code.mekk.waw.pl/mercurial.html |
|
425 | 425 | |
|
426 | 426 | .. _HISTORY.rst: https://foss.heptapod.net/mercurial/mercurial_keyring/src/tip/HISTORY.rst |
|
427 | 427 | .. _TortoiseHg: https://foss.heptapod.net/mercurial/tortoisehg/thg |
|
428 | 428 | .. _Mercurial: https://www.mercurial-scm.org/ |
|
429 | 429 | .. _mercurial_extension_utils: https://foss.heptapod.net/mercurial/mercurial-extension_utils/ |
|
430 | 430 | .. _Path Pattern: https://foss.heptapod.net/mercurial/mercurial-path_pattern/ |
General Comments 0
You need to be logged in to leave comments.
Login now