shaba/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-22 17:34:18 +03:00
Code Releases Activity

docs: Convert 'securityprocess' page to rST

Browse Source 
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This commit is contained in:
Peter Krempa 2022-03-07 14:56:53 +01:00
parent 7f3d5914a1
commit 0d379be41b
3 changed files with 92 additions and 120 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/meson.build
View File

@ -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',

119
docs/securityprocess.html.in
View File

@ -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
View 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.