Commit Graph

7 Commits

Author SHA1 Message Date
Daniel P. Berrangé
d2b6cba4f4 docs: link to security.libvirt.org website
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>
2018-03-16 17:05:56 +00:00
Daniel P. Berrange
e371b3bf41 Use https:// links for most sites
This adds a rule to require https links for the libvirt, qemu
and kvm websites.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-10-16 10:22:34 +01:00
Daniel P. Berrange
b1c81567c7 docs: switch to using HTML5 doctype declaration
The HTML5 doctype is simply

  <!DOCTYPE html>

no DTD is present because HTML5 is no longer defined as an
extension of SGML.

XSL has no way to natively output a doctype without a public
or system identifier, so we have to use an <xsl:text> hack
instead.

See also

  https://dev.w3.org/html5/html-author/#doctype-declaration

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-08-02 17:00:11 +01:00
Daniel P. Berrange
4e42ff6b7e docs: switch to using 'id' attribute instead of 'name' for links
The 'name' attribute on <a...> elements is deprecated in favour
of the 'id' attribute which is allowed on any element. HTML5
drops 'name' support entirely.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-08-02 17:00:11 +01:00
Martin Kletzander
0e7457e501 Fix common misspellings
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>
2015-03-23 09:01:30 +01:00
Yuri Chornoivan
73a03e3063 Fix three minor typos 2013-11-26 18:37:09 +08:00
Daniel P. Berrange
49e6a16f82 Document security reporting & handling process
Historically security issues in libvirt have been primarily
triaged & fixed by the Red Hat libvirt members & Red Hat
security team, who then usually notify other vendors via
appropriate channels. There have been a number of times
when vendors have not been properly notified ahead of
announcement. It has also disadvantaged community members
who have to backport fixes to releases for which there are
no current libvirt stable branches.

To address this, we want to make the libvirt security process
entirely community focused / driven. To this end I have setup
a new email address "libvirt-security@redhat.com" for end
users to report bugs which have (possible) security implications.

This email addr is backed by an invitation only, private
archive, mailing list. The intent is for the list membership
to comprise a subset of the libvirt core team, along with any
vendor security team engineers who wish to participate in a
responsible disclosure process for libvirt. Members of the
list will be responsible for analysing the problem to determine
if a security issue exists and then issue fixes for all current
official stable branches & git master.

I am proposing the following libvirt core team people as
members of the security team / list (all cc'd):

   Daniel Berrange (Red Hat)
   Eric Blake (Red Hat)
   Jiri Denemar (Red Hat)
   Daniel Veillard (Red Hat)
   Jim Fehlig (SUSE)
   Doug Goldstein (Gentoo)
   Guido Günther (Debian)

We don't have anyone from Ubuntu on the libvirt core team.
Serge Hallyn is the most frequent submitter of patches from
Ubuntu in recent history, so I'd like to invite him to join.
Alternatively, Serge, feel free to suggest someone else to
represent Ubuntu's interests.

If any other vendors/distros have security people who are
responsible for dealing with libvirt security issues, and
want to join to get early disclosure of issues, they can
suggest people. Existing security team members will vet /
approve such requests to ensure they are genuine.

Anyone on the team / list will be **required** to honour any
embargo period agreed between members for non-public issues
that are reported. The aim will be to have a maximum 2 week
embargo period in the common case, extendable to 1 month if
there is sufficient justification made. If anyone feels they
are unable to follow such an embargo process for whatever
reason, please decline membership of the security list/team.

The patch which follows puts up some docs on the website
about all of this....

Document how to report security bugs and the process that
will be used for addressing them.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-07-01 11:08:58 +08:00