mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-23 21:34:54 +03:00
d2b6cba4f4
We forgot to tell anyone that we were publishing security notices online at https://security.libvirt.org Reviewed-by: Laine Stump <laine@laine.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
120 lines
4.8 KiB
XML
120 lines
4.8 KiB
XML
<?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://libvirt.org/git/?p=libvirt-security-notice.git;a=log">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 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 id="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 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>
|