Add a security policy for reporting vulnerabilities

[mondeja]

Without a security policy defined, if someone finds a security vulnerability in the project and wants to submit a patch, they must make the patch public. This means potential attackers could exploit the vulnerability and compromise projects that are using Python-Markdown.

In practice, without a security policy, security researchers cannot properly author CVEs through any well-established system, and as a result Python-Markdown is not regularly checked for security vulnerabilities.

To begin addressing this, I am opening this issue to propose creating a SECURITY.md document, which will enable the Security policy in the repository’s Security tab.

For private patch submissions through the GitHub system, CVE researchers also need someone with write access to the repository settings to enable Private vulnerability reporting. The Security advisories tab can also be enabled without forcing reports to be public, since each advisory can later be marked as public or kept private.

Note: there is another approach you might want to consider. You can create a single global SECURITY.md file that applies to all repositories in your organization by creating a Python-Markdown/.github repository and placing the SECURITY.md file there.

[waylan]

My initial inclination is to say we don't care. Markdown is not secure by its design, and it is not the responsibility of a Markdown parser to ensure that no malicious content is being processed (see Markdown and XSS for a good summary). We do have a policy that the parser should never raise an error based on user provided Markdown content because we do recognize that that could crash a web server. However, any decent web developer should never assume that no errors will be raised and account for that in their code. Therefore, CVEs are not something we respond to or act on any differently than any other bug report. Obviously, some people disagree with me. What am I missing?

That said, if we can enable a feature here on GitHub which allows private reports to be submitted, then I don't see any harm in that. I was not aware GitHub offered such a feature. Can you point me to the documentation on that?

[mondeja]

I was not aware GitHub offered such a feature. Can you point me to the documentation on that?

See Secure coding documentation. The part that concers to this PR is Working with security advisories, concretely Configuring private vulnerability reporting for a repository and Creating a repository security advisory.

We do have a policy that the parser should never raise an error based on user provided Markdown content because we do recognize that that could crash a web server. However, any decent web developer should never assume that no errors will be raised and account for that in their code. Therefore, CVEs are not something we respond to or act on any differently than any other bug report. Obviously, some people disagree with me. What am I missing?

Fixing security vulnerabilities in a Markdown parser does not necessarily mean that the parser should sanitize the input to be served in webs. For example, you can sanitize inputs that could collide with substitution placeholders used internally by the parser. The consumer can't know which substitution placeholders are used in Python-Markdown, as they are used internally, and this doesn't affect the input nor the output. This is a common security vulnerability in programs like Python-Markdown.

Additionally, CVEs and security policies encourage security researchers to scan the project because their work will be properly attributed, so the project gets more visibility and high-quality reviews by independent specialized peers, which increases the overall quality of the code.

Anyway, any person can contact a CVE authority that accepts independent CVEs for projects that do not have their own security policy. So not configuring a standardized process does not prevent a project from receiving vulnerability reports or from being the subject of CVE disclosures.