Security Disclosure Process

How we handle security issues.

1. What do we NOT consider a security vulnerability?

One of the most commonly reported classes of vulnerability is third-party web applications passing unfiltered input from web users to the hg command line interface. This is a security vulnerability in the web application, not in Mercurial.

Mercurial's command line uses a security model appropriate for a command line: a user who can run a Mercurial command is allowed to do anything that the operating system will let that user do, including running other commands. See SecuringRepositories for guidance on how to secure a Mercurial repository published via the Internet.

Users should bear in mind that the single largest threat vector for a source control system is the code checked into a repository itself. If you compile or run code from untrusted sources, no exploit of Mercurial itself is necessary.

2. Reporting vulnerabilities (for researchers)

• Send mail to security@mercurial-scm.org

• Let us know if you've allocated or intend to allocate a CVE identifier

3. Summarize and allocate a CVE (for maintainers)

• summary should be a short paragraph that describes:
  • cause (eg "buffer overflow")
  • impact ("arbitrary code execution")
  • affected users ("git subrepo users")
  • affected versions

• Visit https://iwantacve.org/ to get a CVE identifier

• develop a fix
• confirm fix with researcher

4. Early notification process (for maintainters)

• Send an announcement to mercurial-security-announce containing:
  • "(confidential)" in subject
  • planned release date
  • summary of CVEs
  • bundle against stable tip containing planned fixes
  • GPG signature

5. Release process

• apply patches on stable branch just prior to release

• do release as normal point release (see ReleaseChecklist)

• paste CVE summary into release notes