9:59 a.m.
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
docs/meson.build | 2 +-
docs/securityprocess.html.in | 119 -----------------------------------
docs/securityprocess.rst | 91 +++++++++++++++++++++++++++
3 files changed, 92 insertions(+), 120 deletions(-)
delete mode 100644 docs/securityprocess.html.in
create mode 100644 docs/securityprocess.rst
diff --git a/docs/meson.build b/docs/meson.build
index b3432cc6f6..ab020ab090 100644
--- a/docs/meson.build
+++ b/docs/meson.build
@@ -61,7 +61,6 @@ docs_html_in_files = [
'php',
'python',
'remote',
- 'securityprocess',
'storage',
'testapi',
'testsuites',
@@ -108,6 +107,7 @@ docs_rst_files = [
'pci-addresses',
'platforms',
'programming-languages',
+ 'securityprocess',
'strategy',
'styleguide',
'submitting-patches',
diff --git a/docs/securityprocess.html.in b/docs/securityprocess.html.in
deleted file mode 100644
index 0e4802a1de..0000000000
--- a/docs/securityprocess.html.in
+++ /dev/null
@@ -1,119 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
- <body>
-
- <h1>Security Process</h1>
-
- <ul id="toc"></ul>
-
- <p>
- The libvirt project believes in responsible disclosure of
- security problems, to allow vendors time to prepare and
- distribute patches for problems ahead of their publication.
- This page describes how the process works and how to report
- potential security issues.
- </p>
-
- <h2><a id="reporting">Reporting security
issues</a></h2>
-
- <p>
- In the event that a bug in libvirt is found which is
- believed to have (potential) security implications there
- is a dedicated contact to which a bug report / notification
- should be directed. Send an email with as many details of
- the problem as possible (ideally with steps to reproduce)
- to the following email address:
- </p>
-
- <pre>
-<a
href="mailto:libvirt-security@redhat.com">libvirt-security@redhat.com</a></pre>
-
- <p>
- NB. while this email address is backed by a mailing list, it
- is invitation only and moderated for non-members. As such you
- will receive an auto-reply indicating the report is held for
- moderation. Postings by non-members will be approved by a
- moderator and the reporter copied on any replies.
- </p>
-
- <h2><a id="secnotice">Security notices</a></h2>
-
- <p>
- Information for all historical security issues is maintained in
- machine parsable format in the
- <a
href="https://gitlab.com/libvirt/libvirt-security-notice">li...
GIT repository</a> and
- <a href="https://security.libvirt.org">published online</a>
- in text, HTML and XML formats. Security notices are published
- on the <a
href="https://libvirt.org/contact.html#email">libvirt-announce mailing
list</a>
- when any embargo is lifted, or as soon as triaged if already
- public knowledge.
- </p>
-
- <h2><a id="seclist">Security team</a></h2>
-
- <p>
- The libvirt security team is made up of a subset of the libvirt
- core development team which covers the various distro maintainers
- of libvirt, along with nominated security engineers representing
- the various vendors who distribute libvirt. The team is responsible
- for analysing incoming reports from users to identify whether a
- security problem exists and its severity. It then works to produce
- a fix for all official stable branches of libvirt and coordinate
- embargo dates between vendors to allow simultaneous release of the
- fix by all affected parties.
- </p>
-
- <p>
- If you are a security representative of a vendor distributing
- libvirt and would like to join the security team, send an email
- to the afore-mentioned security address. Typically an existing
- member of the security team will have to vouch for your credentials
- before membership is approved. All members of the security team
- are <strong>required to respect the embargo policy</strong>
- described below.
- </p>
-
- <h2><a id="embargo">Publication embargo
policy</a></h2>
-
- <p>
- The libvirt security team operates a policy of
- <a
href="https://en.wikipedia.org/wiki/Responsible_disclosure">...
disclosure</a>.
- As such any security issue reported, that is not already publicly disclosed
- elsewhere, will have an embargo date assigned. Members of the security team agree
- not to publicly disclose any details of the security issue until the embargo
- date expires.
- </p>
-
- <p>
- The general aim of the team is to have embargo dates which
- are two weeks or less in duration. If a problem is identified
- with a proposed patch for a security issue, requiring further
- investigation and bug fixing, the embargo clock may be restarted.
- In exceptional circumstances longer initial embargoes may be
- negotiated by mutual agreement between members of the security
- team and other relevant parties to the problem. Any such extended
- embargoes will aim to be at most one month in duration.
- </p>
-
-
- <h2><a id="cve">CVE allocation</a></h2>
-
- <p>
- The libvirt security team will associate each security issue with
- a CVE number. The CVE numbers will usually be allocated by one of
- the vendor security engineers on the security team.
- </p>
-
- <h2><a id="branches">Branch fixing policy</a></h2>
-
- <p>
- The libvirt community maintains one or more stable release branches
- at any given point in time. The security team will aim to publish
- fixes for GIT master (which will become the next major release) and
- each currently maintained stable release branch. The distro maintainers
- will be responsible for backporting the officially published fixes to
- other release branches where applicable.
- </p>
- </body>
-</html>
diff --git a/docs/securityprocess.rst b/docs/securityprocess.rst
new file mode 100644
index 0000000000..adddbf76b0
--- /dev/null
+++ b/docs/securityprocess.rst
@@ -0,0 +1,91 @@
+================
+Security Process
+================
+
+.. contents::
+
+The libvirt project believes in responsible disclosure of security problems, to
+allow vendors time to prepare and distribute patches for problems ahead of their
+publication. This page describes how the process works and how to report
+potential security issues.
+
+Reporting security issues
+-------------------------
+
+In the event that a bug in libvirt is found which is believed to have
+(potential) security implications there is a dedicated contact to which a bug
+report / notification should be directed. Send an email with as many details of
+the problem as possible (ideally with steps to reproduce) to the following email
+address:
+
+::
+
+ libvirt-security(a)redhat.com
+
+NB. while this email address is backed by a mailing list, it is invitation only
+and moderated for non-members. As such you will receive an auto-reply indicating
+the report is held for moderation. Postings by non-members will be approved by a
+moderator and the reporter copied on any replies.
+
+Security notices
+----------------
+
+Information for all historical security issues is maintained in machine parsable
+format in the `libvirt-security-notice GIT
+repository <https://gitlab.com/libvirt/libvirt-security-notice>`__ and
+`published online <https://security.libvirt.org>`__ in text, HTML and XML
+formats. Security notices are published on the `libvirt-announce mailing
+list <https://libvirt.org/contact.html#email>`__ when any embargo is lifted, or
+as soon as triaged if already public knowledge.
+
+Security team
+-------------
+
+The libvirt security team is made up of a subset of the libvirt core development
+team which covers the various distro maintainers of libvirt, along with
+nominated security engineers representing the various vendors who distribute
+libvirt. The team is responsible for analysing incoming reports from users to
+identify whether a security problem exists and its severity. It then works to
+produce a fix for all official stable branches of libvirt and coordinate embargo
+dates between vendors to allow simultaneous release of the fix by all affected
+parties.
+
+If you are a security representative of a vendor distributing libvirt and would
+like to join the security team, send an email to the afore-mentioned security
+address. Typically an existing member of the security team will have to vouch
+for your credentials before membership is approved. All members of the security
+team are **required to respect the embargo policy** described below.
+
+Publication embargo policy
+--------------------------
+
+The libvirt security team operates a policy of `responsible
+disclosure <https://en.wikipedia.org/wiki/Responsible_disclosure>`__. As such
+any security issue reported, that is not already publicly disclosed elsewhere,
+will have an embargo date assigned. Members of the security team agree not to
+publicly disclose any details of the security issue until the embargo date
+expires.
+
+The general aim of the team is to have embargo dates which are two weeks or less
+in duration. If a problem is identified with a proposed patch for a security
+issue, requiring further investigation and bug fixing, the embargo clock may be
+restarted. In exceptional circumstances longer initial embargoes may be
+negotiated by mutual agreement between members of the security team and other
+relevant parties to the problem. Any such extended embargoes will aim to be at
+most one month in duration.
+
+CVE allocation
+--------------
+
+The libvirt security team will associate each security issue with a CVE number.
+The CVE numbers will usually be allocated by one of the vendor security
+engineers on the security team.
+
+Branch fixing policy
+--------------------
+
+The libvirt community maintains one or more stable release branches at any given
+point in time. The security team will aim to publish fixes for GIT master (which
+will become the next major release) and each currently maintained stable release
+branch. The distro maintainers will be responsible for backporting the
+officially published fixes to other release branches where applicable.
--
2.35.1