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 firstname.lastname@example.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