Mercurial resolves settings from layered files — a system-wide hgrc, a per-user hgrc, and the repository's .hg/hgrc — and the set it reads depends on which account invokes hg. A paths alias or hook that works for a developer can stop applying when the same repository is served or built by a service account such as a CI runner or deploy user.The documented trust mechanism is the likely culprit: configuration in .hg/hgrc owned by a different account is treated as untrusted and skipped unless trusted.users or trusted.groups grants access. Extension loading compounds this — extensions enabled in one user's hgrc are invisible to another account, and path-based extension references may not resolve on the server. Assumed environment: Mercurial 5.x–6.x on Linux; the trust check's exact scope should be confirmed for the pinned release.The goal is one repository-level configuration that behaves identically regardless of which account runs hg, without duplicating settings into every user's hgrc or loosening trust unnecessarily.Open questions:Which configuration sections are withheld from an untrusted .hg/hgrc, and which still apply?Is trusted.users/groups the supported way to make hooks and paths aliases work under a deploy account, or should those settings live in the system-level hgrc?How do extension declarations in .hg/hgrc interact with the trust check when the extension file sits outside the repository?

Mercurial .hg/hgrc trust rules for deploy accounts

1 answer

SiddharthhelperCommunity Helper

5120 reputation · 22 Apr 2023, 12:08 UTC

Yes, Mercurial may ignore specific settings in .hg/hgrc when a deploy job runs as a different user. This occurs because Mercurial implements a security trust mechanism to prevent arbitrary code execution via repository-level configurations.

The Trust Mechanism

When a user invokes hg, Mercurial checks the ownership of the .hg/hgrc file. If the file is owned by a different account than the one executing the command, it is treated as untrusted. While basic configuration values may still be read, high-risk settings are ignored to prevent a malicious repository from executing code on a user's system.

What is withheld from untrusted files?

Hooks: Repository-level hooks are typically disabled because they can execute arbitrary shell commands.
Extensions: Extensions declared in an untrusted .hg/hgrc are generally not loaded.
Path-based References: If an extension or alias relies on a relative path that is only valid for the developer's home directory, it will fail for the deploy user.

Recommended Resolutions

To ensure consistent behavior between developers and deploy users without compromising security, use one of the following strategies:

Option 1: Use trusted.users or trusted.groups

If the deploy user is a trusted service account, you can authorize it to trust repository-level configs. This must be done in a higher-level configuration file (system-wide or the deploy user's own hgrc), as the trust setting cannot be defined within the untrusted file itself.

[ui]
trusted.users = deploy-user-name

Option 2: Move Shared Settings to System hgrc

For paths aliases or extensions that must be identical across all users on the server, move them to the system-wide hgrc. This bypasses the ownership check entirely.

Option 3: Standardize Extension Loading

Since extensions enabled in a developer's user-level hgrc are invisible to the deploy user, ensure all required extensions are enabled in the system-level config or passed via the command line during the deploy job.

Verification Steps

To diagnose which settings are actually being applied during a deploy job, run the following as the deploy user:

Check ownership: ls -l .hg/hgrc to confirm the file is not owned by the deploy user.
Dump active config: hg config. This command lists all active settings and their sources; if your .hg/hgrc settings are missing from this output, the trust check is blocking them.

Diagnostic Note: Please specify the exact version of Mercurial being used (e.g., 5.4.x), as the specific list of restricted sections can vary between major releases.

Your perspective belongs here.

Join the conversation

Does Mercurial ignore .hg/hgrc settings when a deploy job runs as a different user?