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
