204

Is there a way to configure TortoiseHg to store my password?

I have a project hosted on Google Code that I access using TortoiseHg. Whenever I want to push changes to Google Code TortoiseHg prompts me for a username and password. Google Code requires me to use an auto-generated password, and it gets quite repetitive to look it up every time.

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
sourcenouveau
  • 29,356
  • 35
  • 146
  • 243

7 Answers7

269

Both existing answers suggest storing your username and password unencrypted in plain-text, which is a bit of a no-no.

You should use the Keyring extension instead, as it has been specifically designed for securely saving authentication passwords. It already comes bundled with TortoiseHg, so all you have to do is activate it by writing the following in your mercurial.ini file:

[extensions]
mercurial_keyring=

You will also have to associate your username with the push url by editing your repository-specific .hg\hgrc file like in the example below:

[paths]
default = https://<your_username>@bitbucket.org/tortoisehg/thg

For more details on associating your username with the url, see the Repository Configuration (SMTP) section of the Keyring extension page.

Vlad Iliescu
  • 8,074
  • 5
  • 27
  • 23
  • 3
    I just tried this solution and it worked great with windows 7. Very nice! Thanks! – mateuscb Mar 24 '11 at 14:14
  • works well for me - but I think you also need to include a username, either under an [auth] heading, or modify the path to the repository like username@host (as per the Keyring link above) – Tom Carver Apr 05 '11 at 10:17
  • What about saving the username and password if you are behind a web proxy? – Seth May 01 '12 at 00:41
  • @Seth I've never used it this way – Vlad Iliescu May 01 '12 at 07:36
  • 3
    The correct way would be to use the auth section to configure the username. You shouldn't have auth information in your repo path e.g. `[auth] \n bitbucket.org.prefix = bitbucket.org \n bitbucket.org.username = schlamar` – schlamar Jun 04 '13 at 08:58
  • @Seth This has nothing to do with proxy configuration?! – schlamar Jun 04 '13 at 09:00
  • "[the keyring extension] already comes bundled with TortoiseHg, so all you have to do is activate it by writing the following in your mercurial.ini file". This doesn't seem to apply to Linux. I added the extension in ~/.hgrc, but TortoiseHg has stored my username and password in plain text in the same file ~/.hgrc. Better than storing it within the repository directory, but still not what I would call secure. So either the keyring extension is not enabled by just adding [extensions] mercurial_keyring= in .hgrc in linux, or the concept of "keyring" it implements is pretty poor. – matteo Jan 01 '15 at 20:45
  • Where exactly is `mercurial.ini` located on Windows 8.1? – Dmitri Nesteruk May 11 '15 at 21:42
  • With TortoiseHg you don't have to edit Mercurial.ini, you can just check it in the list of extensions of the settings window – CharlesB Jan 18 '17 at 16:47
  • Note that `Keyring` *does not* come bundled with TortoiseHg for Mac. – Tom Granot Oct 22 '18 at 09:28
152

Three steps, watch screenshot. Note: This stores your password in plaintext.

enter image description here

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
bruha
  • 2,505
  • 1
  • 22
  • 21
72

Security warning

Although this answer is accepted as of 2017-09-15, it is not a recommended solution. You should never store your passwords in plain text. Use the mercurial_keyring extension instead. See another answer here.

You can change your push URL to https://username:password@hostname.com/repo.

This is explained in Google Code's and Mercurial's FAQs.

EDIT: Mercurial FAQ explains another way to do it:

With Mercurial 1.3 you can also add an auth section to your hgrc file: 
[auth]
example.prefix = https://hg.example.net/
example.username = foo
example.password = bar
texnic
  • 3,959
  • 4
  • 42
  • 75
Nicolás
  • 7,423
  • 33
  • 35
  • 51
    This is a bad answer! You should never store plaintext passwords in ANY file...!! The other option (with more votes) using mercurial_keyring is the only right thing to do! – Lars Corneliussen Oct 27 '11 at 19:04
  • 6
    +1. Considering that `hg push` is non-destructive (you can always `hg strip` unwanted changesets), pushing to a remote repository is hardly a highly privileged operation. For that reason, plaintext password storage is often perfectly sufficient, as long as one is aware of the security implications. – Søren Løvborg May 27 '12 at 21:13
  • 4
    The problem is not that someone can irretrievably corrupt the repository. The problems are: (1) people reuse passwords, so once someone manages to get to this text file, they'll be able to access unrelated resources; (2) arbitrary hacks may be sneaked into the source code... (3) the code may be secret (not all development is open source), and having it stolen is not always fun. – max Sep 12 '12 at 23:07
  • 6
    @max 1) Maybe true in theory, but OP specifically stated he's using an auto-generated password 2) version control stops this, you can see all changes that were checked in, how could this be an issue? 3) if someone has access to plaintext passwords stored on your computer, they have access to your code too. The password is meaningless here because they can just dump your code onto a dongle. – goldenratio Sep 27 '12 at 17:33
  • @goldenratio for auto generated passwords there seems to be no problem. On 2) though you wouldn't always review every commit from yourself. – max Sep 28 '12 at 19:15
  • 4
    @LarsCorneliussen This is not a bad answer. Not every use-case requires that level of security. The keyring extension is an option, just as this is. – Cypher Feb 11 '14 at 16:49
  • 1
    @LarsCorneliussen: "never" or "always" are nice in theory, the reality of IT is that you must account for insecure storage and you are sometimes forced to do this. keyring-based solutions may work in end-user environments, this is not the case in unattended setups where services talk to each other. Sooner or later you store something more or less insecurely (even if this means a smart card in Fort Knox) – WoJ Jan 14 '15 at 10:24
  • Is not a bad answer. Is a correct one. Maybe a bad practice though, but the notice is there. – Nande Apr 08 '17 at 21:58
12

If you want to configure it via TortoiseHg, Repository Setting dialog is available. After opening the dialog, please switch to 'Sync' tab. You can add a path with HTTPS auth information.

http://tortoisehg.bitbucket.io/manual/2.9/settings.html#module-web.settings

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
kuy
  • 944
  • 5
  • 12
2

Simply modify the hgrc file in the .hg directory of your local repository so it looks like this:

[paths]
default = https://name:password@yourproj.googlecode.com/hg/

where name is your Google Code login without the gmail/googlemail bit e.g. 'fredb' (not fredb@gmail.com), password is the Google-generated password, and yourproj is the name of your GC project. So something like:

default = https://fred:xyz123@fredproj.googlecode.com/hg/
  • 11
    Never store passwords in plain text. NEVER! Use mercurial_keyring - TortoiseHG then only asks for the password once. – Lars Corneliussen Oct 27 '11 at 19:06
  • 1
    Never say never :) Yes, SSH key is preferable than Keyring, Keyring is preferable than plaintext, but there are different situations, really. P.S. upvoted both the "keyring" answer and this one. – Alex Shesterov Jun 10 '16 at 21:32
0

This works for me using SSH. I know the password it's in text plain, but this is not a problem in this project. You have to change myUser and MyOPas for your credentials and the path to: TortoisePlink.exe. Edit the mercurial.ini

[reviewboard]
password = myPass
[ui]
username = myUser
ssh = "C:\Program Files\TortoiseHg\lib\TortoisePlink.exe" -l myUser -pw  myPass
Marcel Fernandez
  • 41
  • 5
0

If you want to store the password in mercurial.ini and it doesn't work anymore after you upgrade to TortoiseHg 4.9 or higher a possible solution is to add the port to the prefix:

[auth]
tax.prefix = http://server:8080
tax.username = cerveser
tax.password = mypassword
Cerveser
  • 752
  • 8
  • 23