From 0d379be41b516711a7e212b334f1e0d3285e453c Mon Sep 17 00:00:00 2001 From: Peter Krempa Date: Mon, 7 Mar 2022 14:56:53 +0100 Subject: [PATCH] docs: Convert 'securityprocess' page to rST MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit Signed-off-by: Peter Krempa Reviewed-by: JÃ¡n Tomko --- 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 @@ - - - - - -

Security Process

- -

- 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@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 and - published online - in text, HTML and XML formats. Security notices are published - on the libvirt-announce mailing list - 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. - 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. -

- - 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@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 `__ and +`published online `__ in text, HTML and XML +formats. Security notices are published on the `libvirt-announce mailing +list `__ 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 `__. 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.47.2