February 07, 2016 • ∞
Not so long ago, the immensely useful Mercurial Keyring extension has stopped working for certain TortoiseHg versions in a specific scenario.
The problem is as follows: when operating on URLs that include a username (like
http://email@example.com/hg), Keyring extension keeps on prompting for username and password.
One thing to note here is that this is decidedly not a TortoiseHg issue per se, since all TortoiseHg is doing is shelling out to Mercurial and parsing the output (in reality, internal workings are quite more complicated, but the essential idea remains the same). Hence, the issue lies elsewhere.
My quick testing has shown that the regression started to manifest itself in TortoiseHg 3.6.2 (the
hg.exe is the one that comes with TortoiseHg; output truncated for readability):
$ hg version Mercurial Distributed SCM (version 3.6.2) (see https://mercurial-scm.org for more information) ... $ hg pull -R d:\projects\hgrpclib --debug pulling from http://firstname.lastname@example.org/hg/hglab/hgrpclib using http://live.hglabhq.com/hg/hglab/hgrpclib http auth: user anton.gogolev, password not set sending capabilities command ... keyring: base url: http://live.hglabhq.com/hg/hglab/hgrpclib, url user: , url pwd: ... keyring: username not specified in hgrc (or in url). Password will not be saved. http authorization required realm: HgLab Live url: http://live.hglabhq.com/hg/hglab/hgrpclib user: interrupted!
Downgrading to TortoiseHg 3.6.1 fixed the issue:
$ hg version Mercurial Distributed SCM (version 3.6.1) (see https://mercurial-scm.org for more information) ... $ hg pull -R d:\projects\hgrpclib --debug pulling from http://email@example.com/hg/hglab/hgrpclib using http://live.hglabhq.com/hg/hglab/hgrpclib http auth: user anton.gogolev, password not set sending capabilities command [HgKeyring] Keyring URL: http://live.hglabhq.com/hg/hglab/hgrpclib [HgKeyring] Looking for password for user anton.gogolev and url http://live.hglabhq.com/hg/hglab/hgrpclib [HgKeyring] Keyring password found. Url: http://live.hglabhq.com/hg/hglab/hgrpclib, user: anton.gogolev, passwd: ******** preparing listkeys for "bookmarks" ...
To completely cross off TortoiseHg from a list of suspects, I decided to review changes between tags 3.6.1 and 3.6.2. As expected, there was nothing suspicious. Next on the list: Mercurial.
Mercurial Wiki on Using Mercurial Extensions tells that keyring extension is not distributed together with Mercurial proper, which is confirmed by the fact that no code changes in Mercurial between tags 3.6.1 and 3.6.2 either related to keyring or in any way change the internal API.
Next up: Keyring extension.
Looking at the commit history, there were quite a few changes, but which of these made it to TortoiseHg 3.6.2? Turns out, there is a separate TortoiseHg-related repository, tortoisehg/thg-winbuild, which has several interesting changesets, ultimately bumping bundled Keyring extension from 0.7.1 to 1.0.1.
So here is the situation: TortoiseHg 3.6.2 upgraded to Mercurial 3.6.2, plus upgraded several extension, most notably Keyring. Somewhere along the way there was something that started causing the issue. Keyring 0.7.1 was working just fine Mercurial 3.6.1. Keyring 1.0.1 has stopped working with Mercurial 3.6.2, yet there were no internal API changes introduced in this minor version bump.
I’m not very well-versed in Python or proficient in writing Mercurial extension, so I’m out of my depth trying to solve the root cause of this issue. Meanwhile, there’s a way to work around this issue without downgrading TortoiseHg or fiddling with source code.
[auth] bitbucket.prefix = https://bitbucket.org/ bitbucket.username = username-at-bitbucket hglab.prefix = http://hglab.example.com/ hglab.username = username-at-hglab
HgLab is a behind-the-firewall self-hosted Mercurial server and source control management system which gives you:
Interested in HgLab and Mercurial? Want to know when new releases are out? Join the HgLab HQ Mailing List for to get notified when something interesting happens.