mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-11-03 20:01:16 +00:00
0e7457e501
Wikipedia's list of common misspellings [1] has a machine-readable version. This patch fixes those misspellings mentioned in the list which don't have multiple right variants (as e.g. "accension", which can be both "accession" and "ascension"), such misspellings are left untouched. The list of changes was manually re-checked for false positives. [1] https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machines Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
114 lines
4.6 KiB
XML
114 lines
4.6 KiB
XML
<?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 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 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>
|