mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-11-05 04:41:20 +00:00
114 lines
4.6 KiB
HTML
114 lines
4.6 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||
|
|
<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 name="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 name="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 co-ordinate
|
||
|
|
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 name="embargo">Publication embargo policy</a></h2>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
The libvirt security team operates a policy of
|
||
|
|
<a href="http://en.wikipedia.org/wiki/Responsible_disclosure">responsible disclosure</a>.
|
||
|
|
As such any security issue reported, that is not already publically disclosed
|
||
|
|
elswhere, will have an embargo date assigned. Members of the security team agree
|
||
|
|
not to publically 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 embargos 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 name="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 name="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>
|
||
|
|
|
||
|
|
<h2><a name="notification">Notification of issues</a></h2>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
When an embargo expires, security issues will be announced on both
|
||
|
|
the libvirt development and announcement <a href="http://libvirt.org/contact.html#email">mailing lists</a>.
|
||
|
|
</p>
|
||
|
|
</body>
|
||
|
|
</html>
|