Configuring Mercurial Trust

Why Mercurial is ignoring your config files and what to do about it

1. Why is Mercurial ignoring my settings?

If you're having trouble getting Mercurial to pay attention to your hgrc setttings on a server, you're probably in the right place.

If you've seen a message like this, you're definitely in the right place:

Not trusting file /home/alice/repo/.hg/hgrc from untrusted user alice, group users

For security reasons, Mercurial only trusts hgrc files owned by the user running Mercurial. Settings from untrusted files will generally be ignored.

2. Why is this a security issue?

Imagine the following scenario:

• Alice has a repository in /repos/alice/project

• It contains a .hg/hgrc owned by Alice

• Bob looks at the repository with hg log

If Bob's hg command trusted Alice's .hg/hgrc, then it could be tricked into loading and running whatever hooks, extensions, and so forth that Alice had configured. If Alice was malicious, she could set up a hook to give her access to Bob's account, read his mail, personal files, etc.

Instead, Mercurial ignores these settings, which means that hooks and extensions (malicious or not!) that Alice has enabled will be ignored.

3. I'm Alice! Why am I seeing this?

You're actually running Mercurial as a different user for some reason. The id command on a Unix-like system may help here.

4. What if I think Alice is trustworthy?

4.1. How NOT to fix it

For some reason, users invariably try to fix this issue backwards by having Alice declare in her hgrc file that she trusts Bob. This doesn't help: the problem is that Bob doesn't trust Alice, so nothing Alice can put in her config file will change things. Make sure you know which way the trust needs to go!

4.2. How to declare trust

Users can add settings to their $HOME/.hgrc to tell Mercurial to trust other users. For instance, if Bob has decided he can trust Alice not to try to delete his files when he looks at her repository, he could add:

[trusted]
users = alice, carl, dan

Alternately, Bob can decide to trust a group of people (as specified in an operating system group)

[trusted]
groups = dev-team

Bob shouldn't do this unless he actually trusts Alice!

More info can be found in hgrc manpage.

5. I'm still confused, I'm getting this message in my webserver logs?

In this case, the user running your Apache server (such as apache, daemon, nobody or www-data) is Bob in our example and the user who owns the repository is Alice. In other words, the web server user doesn't trust the repository owner.

Once you've understood the security implications above, there are several possibilities for fixing this:

• Ignore it - hooks and extensions aren't required

• Add a trust setting in the .hgrc file of the web server user's home directory

• Change the repository to be owned by the web server (note that setting the group is not the same as setting the owner)

• Add a global trust setting in /etc/mercurial/ or similar (only if you trust everyone!)

6. Ok, what about with SSH?

When you get an error from push or pull that looks like this:

bob$ hg pull ssh://bob@server//repos/alice/test
destination directory: test
remote: Not trusting file test/.hg/hgrc from untrusted user alice,
group users
remote: Not trusting file /repos/alice/test/.hg/hgrc from untrusted
user alice, group users
adding changesets
adding manifests
adding file changes
added 2 changesets with 3 changes to 2 files
updating to branch default
2 files updated, 0 files merged, 0 files removed, 0 files unresolved

...that 'remote:' prefix indicates the error is coming from the remote server. Thus, the error is about users and permissions and trust settings on the remote machine. Bob's local hgrc settings are not involved. To fix this, he'll need to ssh to the remote machine and add appropriate settings to his .hgrc file there.

7. Can I configure a server so users will default-trust the hooks?

Consider the common situation of a central repository. You, the server administrator, want some hooks to run on this server for incoming patches. You have several options:

• Only provide repository access via the web/http interface (not ssh). See above section regarding webserver logs.
• Make a shared ssh account, which owns the hgrc, and require users to use that account for pushing.

• add

  [trusted]
  users = root

  to /etc/mercurial/hgrc, and then have your repository's hgrc owned by root.

The first option is good if you are already running a web server, but might be more overhead if your users already have individual ssh accounts (you will need to create 'duplicate' accounts on the web server—more maintenance).

The second option (shared ssh account) might be considered low-security because it will be hard to revoke user access, attribute usage, and shared passwords are harder to keep secret.

The third option provides more secure ssh access by configuring the default settings of all users on the machine to trust 'root'. Mercurial does not directly trust root regarding hgrc files... Mercurial will ‘trust’ the global /etc/mercurial/hgrc file (which typically should be locked down to root), and from there you must explicitly declare that users should trust root-owned hgrc files. (can this be overridden by a user's $HOME/.hgrc to remove root-trust and thus skip hook execution?)