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.

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

• send a CVE allocation request with the summary to cve-assign@mitre.org

• 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