mercurial_keyring always asks for user/password

Create issue
Issue #49 resolved
Former user created an issue

latest TortoiseHG version 3.6.2 with latest mercurial_keyring always asks for user/password and a console message is shown:

[command returned code 255 Wed Dec 23 16:59:49 2015] % hg outgoing --template {node}^M http://myuser@ comparing with http://myuser@ keyring: username not specified in hgrc (or in url). Password will not be saved.

Previous TortoiseHG version 3.6.1 works great.

Comments (12)

  1. Joseph Foley

    I am having a similar problem with Linux mint 17.3 keyring: username not specified in hgrc (or in url). Password will not be saved. http authorization required

    hg keyring_check keyring password save status: default: password not available, user unknown, url https://XXXX/ Using seahorse, I notice that the entry in the login keychain is username@@https://XXXX/

  2. Justinas

    i can confirm that if specifying both prefix and username in hgrc works.

    default.username = gamesh
    default.prefix =

    default is the name of the default path.

    but if i remove default.username and move the username into URL it does not, the message says "username not specified in hgrc (or in url)" obviously the extension does not see the username in url.

  3. Hemisphera

    Confirmed. Updated to TortoiseHg 3.6.2 and since then it stopped working. I have never used usernames in [auth] but always included them in the URL. Worked fine earlier.

    Looks like something broke when you swtiched to mercurial.util.url in commit bfd781f.

    Running a

    hg pull --debug

    keyring says:

    keyring: base url: http://br-hgsrvprd1:8080/scm/hg/xxxx, url user: , url pwd:

    Although my URL is http://<username>@br-hgsrvprd1:8080/

    Reading through the configuration you state that using it this way is not recommended. Is this an intended change?

  4. Diego Bonfil Traver

    I think something changed in hg side, because the authuri that is passed to get_credentials method does not have the user/password inside. So hg must have stripped them before...

    Maybe an API change?

    Easily checked with (line 294 of

    ui.debug(_('keyring: base url: %s, url user: %s, url pwd: %s, authuri: %s\n') %
                     (base_url, url_user or '', url_passwd and '******' or '', authuri))
  5. Marcin Kasperski repo owner

    well, I still have this is sth in general I fixed in 1.0.1 but mayhaps it is mercurial dependant.

    Test on hg 3.3.2 on my linux (quoted url or it's prefix is not in any way configured anywhere - I use here for this purpose as normally I use and configure

    $ hg keyring_check
    keyring password save status: password not available, once entered, will be bound to user Mekk, url

    as you see „will be bound to user Mekk”, user is recognized at least here

    (I must find some different destination for pushing as hg push ‹url above› translated to

    Could anyone experiencing the problem execute hg keyring_check and confirm whether it also experiences username problems? And please quote hg version

  6. Marcin Kasperski repo owner

    Looks like something has changed in Mercurial core, and passwordmgr.find_user_password gets now url which lacks username. Bah, even basic_http_error_auth_reqed.

    Looks like some deeper patching may be needed to find out what original url was. I will take some look ……… but still defining the prefix is recommended solution

  7. Marcin Kasperski repo owner

    In the end it turned out to be a bug in my code (which showed up due to some subtle mercurial changes, but still) – the function ignored username extracted from urllib cache.

    I fixed it, will make release soon (fix will be in 1.1.1)

  8. Log in to comment