#pragma section-numbers 2

= Security Disclosure Process =

How we handle security issues.

<<TableOfContents>>

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

== 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

== 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

== 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

== 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

----
## list categories here