mirror of
https://github.com/libvirt/libvirt.git
synced 2025-02-25 18:55:26 -06:00
docs: Convert 'securityprocess' page to rST
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
This commit is contained in:
parent
7f3d5914a1
commit
0d379be41b
@ -61,7 +61,6 @@ docs_html_in_files = [
|
|||||||
'php',
|
'php',
|
||||||
'python',
|
'python',
|
||||||
'remote',
|
'remote',
|
||||||
'securityprocess',
|
|
||||||
'storage',
|
'storage',
|
||||||
'testapi',
|
'testapi',
|
||||||
'testsuites',
|
'testsuites',
|
||||||
@ -108,6 +107,7 @@ docs_rst_files = [
|
|||||||
'pci-addresses',
|
'pci-addresses',
|
||||||
'platforms',
|
'platforms',
|
||||||
'programming-languages',
|
'programming-languages',
|
||||||
|
'securityprocess',
|
||||||
'strategy',
|
'strategy',
|
||||||
'styleguide',
|
'styleguide',
|
||||||
'submitting-patches',
|
'submitting-patches',
|
||||||
|
@ -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">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>
|
|
91
docs/securityprocess.rst
Normal file
91
docs/securityprocess.rst
Normal file
@ -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 <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.
|
Loading…
Reference in New Issue
Block a user