[PATCH 10/17] docs: Convert 'securityprocess' page to rST

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx>
---
 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@xxxxxxxxxx";>libvirt-security@xxxxxxxxxx</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";>libvirt-security-notice 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";>responsible 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@xxxxxxxxxx
+
+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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux