Issue #117 resolved

passwords encoded in URLs are problematic

Jean-Pierre Bergamin
created an issue

I just installed the latest thg Version 1.9.2: TortoiseHg version 1.9.2+63-fdbbfe403d45 with Mercurial-1.7.5+4-8f5c865b7b4a, Python-2.6.6, PyQt-4.8.2, Qt-4.7.1

Using a http repo with basic auth fails. The .hg/hgrc file contains: {{{ [paths] default = http://james:mypassword@host/hg/repo }}}

When I open the synchronize dialog and click on "Filter outgoing changesets to specified URL" I get the following error:

{{{ % hg --repository C:\Users\james\Documents\er outgoing http://james:***@host/hg/repo abgebrochen: unsupported URL component: "host/hg/repo" }}}

Previous versions of TortoiseHg had no problem, using http auth with the same path settings in the hgrc file.

Another issue arises, when I try to store username and password for a http repo with the "Security" dialog. Open the synchronize dialog Click on "Security" Enter a username and password Click "Save" -> Nothing is saved yet, so "Save" maybe a misleading naming for this button Click the "Save" button next to the "Security" button to actually save the new auth settings A dialog pops up to actually save the values, where the password is masked with When saving, the * are actually written into the hgrc file, which is obviously wrong ;-) * I have a question mark in my password. Older Versions of TortoiseHG haved the question mark url-encoded with %3F in the hgrc file like

{{{ [paths] default = http://james:password_with_%3F@host/hg/repo }}} This may be a problem as well here.

Comments (14)

  1. Steve Borho

    You should really be using the mercurial keyring extension so you don't keep your passwords in clear text in your hgrc file.

    You are also quite confused about how URL encoded passwords and the security dialog work. When you save the username and password in the security dialog, it writes an [auth] section for the host so that it will use that username and password for all HTTPS connections to that host. However the [auth] section is ignored when you encode a username and password in the URL itself.

  2. Jean-Pierre Bergamin reporter

    I'll definitively have a look at the keyring extension. But I'm still really confused about how the security dialog *should* work without using the keyring... ;-)

    Currently, the keyring extension is turned off.

    I open the security dialog and enter a username and password and hit save. When I hit the Save button in the synchronize dialog, another dialog pops up with the title "Save Peer Path", where I can change the Alias and the URL again. The URL appears with a masked password like "http://james:***@host/repo". When I then press "Save", my hgrc file is updated with

    default = http://james:***@host/repo

    The correct password should be stored in the hgrc file and not *.

  3. Steve Borho

    The security dialog manages your user configuration file (/.hgrc or Mercurial.ini)

    It adds entries in an [auth] section for user authentication and entries in [hostfingerprints] for, you guessed it, host fingerprints.

    The auth section will look like

    hostname.prefix = hostname
    hostname.username = yourusername
    hostname.password = password

    Mercurial will use this info for any HTTPS connection to 'hostname' so long as the URL doesn't specify a different username or a password.

    So this trades having your password in plain text in every repo/.hg/hgrc file to having it in plain text in one place in your user configuration file.

    The next step is to enable mercurial_keyring and delete the 'alias.password =' lines from your user configuration file. The next time you login it will prompt for a password and then store it cryptographically in the best back-end it can find for your platform (Windows crypto, Mac OS X Keyring, Gnome/KDE Keyring, etc).

    The security dialog is going to have a help page that explains all this, but currently that button does nothing.

  4. Steve Borho

    Looking into the original issue, the question mark in the pw is confusing Python's urlparse.urlparse() method, making it think most of the URL is a query.

    I'm tempted not to fix this particular bug, as we do not want users to keep passwords in their URLs, but I do need to fix the behavior of the URL save dialog.

  5. Steve Borho

    sync: provide a safe mechanism for clearing username/pw from URL (refs #117)

    Never show the user's password, but don't actually provide a method for changing or setting the URL password. Only allow it to be deleted along with the username, and default the checkbox to favor deletion.


  6. Jean-Pierre Bergamin reporter

    It may be off-topic, but since we have discussed the keyring functionality, I have an addition... :-)

    I downloaded the newest version. In this version, the security button in the synchronize window is disabled, when http is chosen as the protocol. But actually I also want to store my password for http connections in the keyring. "man hgrc" says that this is possible by adding "xy.schemes = http" to mercurial.ini like:

    juniteam.schemes = http
    juniteam.prefix = juniteam
    juniteam.username = james

    So it would be nice if thg would add this xy.schemes line to mercurial.ini if the protocol is http.

  7. Steve Borho

    It *could* but I purposefully don't. What's the point of storing passwords cryptographically if you're going to send them over the wire in plain-text.

    If you want to expose yourself that way, you'll have to open the INI file in an editor and add the schemes item yourself.

  8. Jean-Pierre Bergamin reporter

    I understand your concerns. When I know how to manually set that in the mercurial.ini, I'm fine.

    Our SSL connections terminate on our reverse proxy that makes our internal hg repo available in the internet. In our LAN, we access the repo over http, over the internet via https. We use digest authentication, so no password is sent over the wire anyway - be it http or https.

  9. Log in to comment