Store password in TortoiseHg

Question

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.

Solution 1

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:[email protected]/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

Solution 2

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.

Solution 3

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

Solution 4

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

Solution 5

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

[paths]
default = https://name:[email protected]/hg/

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

default = https://fred:[email protected]/hg/

View more solutions

Comments

[mateuscb]

I just tried this solution and it worked great with windows 7. Very nice! Thanks!

[Tom Carver]

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)

[vobject]

Good answer, definitly the way to go.

[sandeep pathak]

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!

[sandeep pathak]

Never store passwords in plain text. NEVER! Use mercurial_keyring - TortoiseHG then only asks for the password once.

[Vlad Iliescu]

it looks like this also stores the password in plaintext - if you have the keyring extension enabled, then the password field becomes disabled

[Seth]

What about saving the username and password if you are behind a web proxy?

[Vlad Iliescu]

@Seth I've never used it this way

[Søren Løvborg]

+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.

[max]

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.

[goldenratio]

@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.

[max]

@goldenratio for auto generated passwords there seems to be no problem. On 2) though you wouldn't always review every commit from yourself.

[Despertar]

Only works if you are using https protocol, when setting to http the padlock goes away.

[schlamar]

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]

@Seth This has nothing to do with proxy configuration?!

[Cypher]

@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.

[matteo]

"[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.

[WoJ]

@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)

[Dmitri Nesteruk]

Where exactly is mercurial.ini located on Windows 8.1?

[Alex Shesterov]

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.

[CharlesB]

With TortoiseHg you don't have to edit Mercurial.ini, you can just check it in the list of extensions of the settings window

[Nande]

Is not a bad answer. Is a correct one. Maybe a bad practice though, but the notice is there.

[William T. Mallard]

Accepted legacy answers suck, this should have the green chekky!

[Tom Granot]

Note that Keyring does not come bundled with TortoiseHg for Mac.