docs-make: have markdown files use .md

1 files changed, 0 insertions, 110 deletions

diff --git a/docs/SECURITY b/docs/SECURITY
deleted file mode 100644
index 3c07e0bbe..000000000
--- a/docs/SECURITY
+++ /dev/null
@@ -1,110 +0,0 @@
-                                  _   _ ____  _
-                              ___| | | |  _ \| |
-                             / __| | | | |_) | |
-                            | (__| |_| |  _ <| |___
-                             \___|\___/|_| \_\_____|
-
-curl security for developers
-============================
-
-This document is intended to provide guidance to curl developers on how
-security vulnerabilities should be handled.
-
-Publishing Information
-----------------------
-
-All known and public curl or libcurl related vulnerabilities are listed on
-[the curl web site security page](https://curl.haxx.se/docs/security.html).
-
-Security vulnerabilities should not be entered in the project's public bug
-tracker unless the necessary configuration is in place to limit access to the
-issue to only the reporter and the project's security team.
-
-Vulnerability Handling
-----------------------
-
-The typical process for handling a new security vulnerability is as follows.
-
-No information should be made public about a vulnerability until it is
-formally announced at the end of this process. That means, for example that a
-bug tracker entry must NOT be created to track the issue since that will make
-the issue public and it should not be discussed on any of the project's public
-mailing lists. Also messages associated with any commits should not make
-any reference to the security nature of the commit if done prior to the public
-announcement.
-
-- The person discovering the issue, the reporter, reports the vulnerability
-  privately to `curl-security@haxx.se`. That's an email alias that reaches a
-  handful of selected and trusted people.
-
-- Messages that do not relate to the reporting or managing of an undisclosed
-  security vulnerability in curl or libcurl are ignored and no further action
-  is required.
-
-- A person in the security team sends an e-mail to the original reporter to
-  acknowledge the report.
-
-- The security team investigates the report and either rejects it or accepts
-  it.
-
-- If the report is rejected, the team writes to the reporter to explain why.
-
-- If the report is accepted, the team writes to the reporter to let him/her
-  know it is accepted and that they are working on a fix.
-
-- The security team discusses the problem, works out a fix, considers the
-  impact of the problem and suggests a release schedule. This discussion
-  should involve the reporter as much as possible.
-
-- The release of the information should be "as soon as possible" and is most
-  often synced with an upcoming release that contains the fix. If the
-  reporter, or anyone else, thinks the next planned release is too far away
-  then a separate earlier release for security reasons should be considered.
-
-- Write a security advisory draft about the problem that explains what the
-  problem is, its impact, which versions it affects, solutions or
-  workarounds, when the release is out and make sure to credit all
-  contributors properly.
-
-- Request a CVE number from
-  [distros@openwall](http://oss-security.openwall.org/wiki/mailing-lists/distros)
-  when also informing and preparing them for the upcoming public security
-  vulnerability announcement - attach the advisory draft for information. Note
-  that 'distros' won't accept an embargo longer than 19 days and they do not
-  care for Windows-specific flaws. For windows-specific flaws, request CVE
-  directly from MITRE.
-
-- Update the "security advisory" with the CVE number.
-
-- The security team commits the fix in a private branch. The commit message
-  should ideally contain the CVE number. This fix is usually also distributed
-  to the 'distros' mailing list to allow them to use the fix prior to the
-  public announcement.
-
-- At the day of the next release, the private branch is merged into the master
-  branch and pushed. Once pushed, the information is accessible to the public
-  and the actual release should follow suit immediately afterwards.
-
-- The project team creates a release that includes the fix.
-
-- The project team announces the release and the vulnerability to the world in
-  the same manner we always announce releases. It gets sent to the
-  curl-announce, curl-library and curl-users mailing lists.
-
-- The security web page on the web site should get the new vulnerability
-  mentioned.
-
-
-
-CURL-SECURITY (at haxx dot se)
-------------------------------
-
-Who is on this list? There are a couple of criteria you must meet, and then we
-might ask you to join the list or you can ask to join it. It really isn't very
-formal. We basically only require that you have a long-term presence in the
-curl project and you have shown an understanding for the project and its way
-of working. You must've been around for a good while and you should have no
-plans in vanishing in the near future.
-
-We do not make the list of partipants public mostly because it tends to vary
-somewhat over time and a list somewhere will only risk getting outdated.