mbox series

[web,0/4] Add web section reporting information about CVEs in QEMU

Message ID 20181018145203.11336-1-berrange@redhat.com (mailing list archive)
Headers show
Series Add web section reporting information about CVEs in QEMU | expand

Message

Daniel P. Berrangé Oct. 18, 2018, 2:51 p.m. UTC
At the QEMU maintainer's summit in Prague we discussed QEMU's woeful
reporting and recording of security flaws

 - No CVE information is published unless it happened to be mentioned in
   the commit message
 - No analysis or information on when the flaw was first introduced in
   the code, and thus which versions are impacted
 - There is no collated list of vulnerabilities
 - Users / downstreams are not alerted when CVEs are fixed
 - There is no description of the impact of the bug or possible
   workarounds that can be used

Various 3rd parties do have some of this information. For example there
are various sites which collate lists of CVEs affecting projects, but
the information is quite minimal usually lacking details on the impact,
or possible workarounds.

Distro vendors typically look at when a flaw was introduced to determine
affected versions, but this information is not recorded anywhere.

What information is found is usually free form text making it difficult
to reliably process the data for analysis or reporting needs.

At the maintainer summit I volunteered address the problem of security
flaw reporting for QEMU. It took a bit longer than I expected to get
around it it, but I just got it working before this year's maintainer
summit :-)

This series addresses the problems by adding a new section to the QEMU
website with the following content:

 - "Security notices" heading is added to the navigation bar

 - At /secnotice/index.xml is a list of all known security flaws in a
   machine readable format

 - At /secnotice/ is the same information in human readable HTML format,
   auto-generated from the XML.

 - At /secnotice/$YEAR/$NUM.xml is detailed information in machine
   readable format for a single discovered flaw.

 - At /secnotice/$YEAR/$NUM is the same information in human readable
   HTML format, auto-generated from the XML

 - At /secnotice/$YEAR/$NUM.txt is the same information in human
   readable plain text format, auto-generated from the XML. This is
   suited for sending as email to the mailing list as an announcement.

At this point it is best to actually look at it running on a real site,
so I put up a static build of the qemu-web.git content for this series

  https://berrange.fedorapeople.org/qemu-sec/secnotice/

Taking one issue with multiboot from earlier this year:

  https://berrange.fedorapeople.org/qemu-sec/secnotice/2018/003
  https://berrange.fedorapeople.org/qemu-sec/secnotice/2018/003.txt
  https://berrange.fedorapeople.org/qemu-sec/secnotice/2018/003.xml

You can see there are a few distinct pieces of content about each issue

 - Lifecycle dates for

       * when it was reported
       * when it went public. Usually date when patch was posted for
         review or when it was publically mention in BZ or mailing
         list. Might differ from reported date if the initial reporting
         had an embargo.
       * when the fix merged to GIT master (ie Peter applied a PULL
         request)

 - Credits. Names / email of the people who discovered and reported the
   flaws, and people involved in writing patches to fix it. The latter
   is usually the git author.

 - External references. Typically the CVE ID number, but could also be a
   bug tracker name + number

 - Several free text blocks

      * description of what the flaw is
      * impact on the system when triggered/exploited
      * any ways to mitigate / workaround the impact

 - Git repository info

     * Commit hash where the flaw was introduced
     * Commit hash(s) where the flaw was fixed
     * Commit hash(s) where the flaw was merged
     * Tags containing the flaw on all branches
     * Tags containing the fix on git master and optionally stable
       branches

Reporting on a new issue is fairly straightforward. The
secnotice/template.xml file is cloned to the next available security
notice number for the current year eg  secnotice/2018/012.xml

Then it is simply a case of filling in the blanks in the template with
as little or much information as is available - all the fields are
optional, so can be left out if the info is not yet available.

Many key pieces of info will be available from the downstream distro
vendor who coordinates with upstream. For example the Red Hat CVE
links https://bugzilla.redhat.com/CVE-XXX-XXX usually contain the basic
description and impact, along with dates and credit for who reported it.

The hardest part is examining the GIT history to determine when the fix
was first introduced into the code. This is a case of using "git blame"
to trace back where the lines of troublesome code came from - often back
to the very first point the file was commited to QEMU.

Once the original commit hash is found, then there is a tool
secnotice/_scripts/report-vulnerable-tags.pl which will examine git tags
to determine which tags and branches contain the flaw. It will print the
snippet of XML suitable for copying into the template. It can optionally
accept the hash of the merge commit fixing the problem too.

After adding the new $YEAR/$ID.xml file, 'make' will build the
corresponding indexes and HTML/TXT renderings. Ideally the machine which
is hosting the QEMU website would run 'make' after pulling new
commits. In this series, however, I have just commited the rendered
content to git.

In this series I have created notices for all the CVEs I found affecting
QEMU in 2018 that were listed in the Red Hat bugzilla against
Fedora. I'm not entirely confident this is the full set from 2018. I
fully researched the git history for each issue here and suggested
mitigations where practical.

Looking back before 2018, there are ~200 further CVEs I have seen
affecting QEMU. Ideally we'd create records for each of those, but that
will be more time consuming and not a high priority.

Typically it has taken me about 10 minutes on average to create each CVE
file, including time to find historical commits, so the extra work is
quite small, especially compared to actually fixing the code. Ideally
maintainers responsible for the code would create the security notice,
but it could be anyone with an understanding of the issue/code.

Some ideas for future work to take advantage of the machine readable
data format

 - Instead of browsing a list of notices and checking each one to
   see if your version is affected, generate reports for each release
   tag in git listing the flaws that apply.

 - Automated report generation
    - How quickly bugs are fixed since being reported
    - Which areas of code are most affected by flaws (useful
      for distros deciding to cull features)
    - Long term rates of bug reporting (already see 2018
      appears much better than 2016/2017, possibly going
      to be lowest number of CVEs since 2012 !)

Finally, this will all look familiar to anyone following libvirt
as we use the same framework for libvirt security notices:

   https://security.libvirt.org/
   https://libvirt.org/git/?p=libvirt-security-notice.git;a=log

I've made a number of changes for QEMU to better suit the way
QEMU works (only 1 git repo to follow, merge commits, integration
with jekyll templating)

Daniel P. Berrangé (4):
  Underline the current page section
  Introduce content and tools for managing security notices
  Add vulnerability reports for 2018
  Update pre-rendered content

 _config.yml                                  |    4 +
 _includes/nav.html                           |    3 +-
 _layouts/secnotice.html                      |   22 +
 assets/css/style-desktop.css                 |    2 +
 assets/css/style.css                         |   47 +
 secnotice/2018/001.html                      | 1043 +++++++++++++++++
 secnotice/2018/001.txt                       |  210 ++++
 secnotice/2018/001.xml                       |  248 ++++
 secnotice/2018/002.html                      | 1044 +++++++++++++++++
 secnotice/2018/002.txt                       |  206 ++++
 secnotice/2018/002.xml                       |  242 ++++
 secnotice/2018/003.html                      |  766 +++++++++++++
 secnotice/2018/003.txt                       |  160 +++
 secnotice/2018/003.xml                       |  191 ++++
 secnotice/2018/004.html                      | 1045 +++++++++++++++++
 secnotice/2018/004.txt                       |  206 ++++
 secnotice/2018/004.xml                       |  243 ++++
 secnotice/2018/005.html                      |  952 ++++++++++++++++
 secnotice/2018/005.txt                       |  191 ++++
 secnotice/2018/005.xml                       |  225 ++++
 secnotice/2018/006.html                      | 1056 ++++++++++++++++++
 secnotice/2018/006.txt                       |  210 ++++
 secnotice/2018/006.xml                       |  247 ++++
 secnotice/2018/007.html                      |  820 ++++++++++++++
 secnotice/2018/007.txt                       |  169 +++
 secnotice/2018/007.xml                       |  201 ++++
 secnotice/2018/008.html                      |  952 ++++++++++++++++
 secnotice/2018/008.txt                       |  191 ++++
 secnotice/2018/008.xml                       |  225 ++++
 secnotice/2018/009.html                      |  952 ++++++++++++++++
 secnotice/2018/009.txt                       |  192 ++++
 secnotice/2018/009.xml                       |  225 ++++
 secnotice/2018/010.html                      |  940 ++++++++++++++++
 secnotice/2018/010.txt                       |  188 ++++
 secnotice/2018/010.xml                       |  223 ++++
 secnotice/2018/011.html                      |  823 ++++++++++++++
 secnotice/2018/011.txt                       |  169 +++
 secnotice/2018/011.xml                       |  199 ++++
 secnotice/2018/index.html                    |   46 +
 secnotice/2018/index.xml                     |   13 +
 secnotice/Makefile                           |   40 +
 secnotice/README-template.md                 |   78 ++
 secnotice/README.md                          |   20 +
 secnotice/_scripts/index-html.xsl            |   72 ++
 secnotice/_scripts/index-xml                 |   28 +
 secnotice/_scripts/notice-html.xsl           |  286 +++++
 secnotice/_scripts/notice-txt.xsl            |  277 +++++
 secnotice/_scripts/report-vulnerable-tags.pl |  135 +++
 secnotice/index.html                         |   46 +
 secnotice/index.xml                          |   13 +
 secnotice/template.xml                       |   50 +
 51 files changed, 16135 insertions(+), 1 deletion(-)
 create mode 100644 _layouts/secnotice.html
 create mode 100644 secnotice/2018/001.html
 create mode 100644 secnotice/2018/001.txt
 create mode 100644 secnotice/2018/001.xml
 create mode 100644 secnotice/2018/002.html
 create mode 100644 secnotice/2018/002.txt
 create mode 100644 secnotice/2018/002.xml
 create mode 100644 secnotice/2018/003.html
 create mode 100644 secnotice/2018/003.txt
 create mode 100644 secnotice/2018/003.xml
 create mode 100644 secnotice/2018/004.html
 create mode 100644 secnotice/2018/004.txt
 create mode 100644 secnotice/2018/004.xml
 create mode 100644 secnotice/2018/005.html
 create mode 100644 secnotice/2018/005.txt
 create mode 100644 secnotice/2018/005.xml
 create mode 100644 secnotice/2018/006.html
 create mode 100644 secnotice/2018/006.txt
 create mode 100644 secnotice/2018/006.xml
 create mode 100644 secnotice/2018/007.html
 create mode 100644 secnotice/2018/007.txt
 create mode 100644 secnotice/2018/007.xml
 create mode 100644 secnotice/2018/008.html
 create mode 100644 secnotice/2018/008.txt
 create mode 100644 secnotice/2018/008.xml
 create mode 100644 secnotice/2018/009.html
 create mode 100644 secnotice/2018/009.txt
 create mode 100644 secnotice/2018/009.xml
 create mode 100644 secnotice/2018/010.html
 create mode 100644 secnotice/2018/010.txt
 create mode 100644 secnotice/2018/010.xml
 create mode 100644 secnotice/2018/011.html
 create mode 100644 secnotice/2018/011.txt
 create mode 100644 secnotice/2018/011.xml
 create mode 100644 secnotice/2018/index.html
 create mode 100644 secnotice/2018/index.xml
 create mode 100644 secnotice/Makefile
 create mode 100644 secnotice/README-template.md
 create mode 100644 secnotice/README.md
 create mode 100644 secnotice/_scripts/index-html.xsl
 create mode 100755 secnotice/_scripts/index-xml
 create mode 100644 secnotice/_scripts/notice-html.xsl
 create mode 100644 secnotice/_scripts/notice-txt.xsl
 create mode 100644 secnotice/_scripts/report-vulnerable-tags.pl
 create mode 100644 secnotice/index.html
 create mode 100644 secnotice/index.xml
 create mode 100644 secnotice/template.xml

Comments

Paolo Bonzini Oct. 18, 2018, 9:36 p.m. UTC | #1
On 18/10/2018 16:51, Daniel P. Berrangé wrote:
> 
> After adding the new $YEAR/$ID.xml file, 'make' will build the
> corresponding indexes and HTML/TXT renderings. Ideally the machine which
> is hosting the QEMU website would run 'make' after pulling new
> commits. In this series, however, I have just commited the rendered
> content to git.

"git push" is already running Jekyll, which has a templating mechanism
similar to the one used for blog posts
(https://jekyllrb.com/docs/collections/).  Basically one security notice
would be a file in a _secnotices directory, with the metadata in a YAML
preamble like this:

---
title: Speculative store bypass
id: 2018-001
date: 2018-05-21
reported: 2018-03-12
fixed: 2018-06-26

credits:
  - reporter:
    - name: Ken Johnson (Microsoft Security Response Center)
    - name: Jann Horn (Google Project Zero)
  - patcher:
    - name: Daniel P. Berrangé
      email: berrange@redhat.com
    - name: Konrad Rzeszutek Wilk
      email: konrad.wilk@oracle.com

advisories:
  - type: CVE
    id: 2018-3639

branches:
  - master:
      state: fixed
      change:
      - d19d1f965904a533998739698020ff4ee8a103da: fixed
      - 403503b162ffc33fb64cfefdf7b880acf41772cd: fixed
      - 4f50c1673a89b07f376ce5c42d22d79a79cd466d: merged
      - a764f3f7197f4d7ad8fe8424269933de912224cb: fixed
      - e409d9a158c77c650651e8118f6c86c8dc76eba6: merged
      - 7ba1e61953f4592606e60b2e7507ff6a6faf861a: vulnerable
      tag:
      - v0.10.1: vulnerable
    ...
+---

{% contentfor description %}
An industry-wide issue was found in the way many modern microprocessor
designs have implemented speculative execution of Load & Store
instructions (a commonly used performance optimization).
+
+It relies on the presence of a precisely-defined instruction sequence
in the privileged code as well as the fact that memory read from address
to which a recent memory write has occurred may see an older value and
subsequently cause an update into the microprocessor's data cache even
for speculatively executed instructions that never actually commit (retire).
{% endcontentfor %}

{% contentfor impact %}
As a result, an unprivileged attacker could use this flaw to read
privileged memory by conducting targeted cache side-channel attacks.
{% endcontentfor %}

{% contentfor mitigation %}
None
{% endcontentfor %}


(Requires the jekyll-contentblocks plugin).

I am not a YAML fan, but I still would probably have to hide if I
suggested using XSLT to convert the XML files to YAML. :)  Still, one
question is obvious: is the XML an industry standard?  That would make
it more palatable...
Daniel P. Berrangé Oct. 19, 2018, 10:25 a.m. UTC | #2
On Thu, Oct 18, 2018 at 11:36:39PM +0200, Paolo Bonzini wrote:
> On 18/10/2018 16:51, Daniel P. Berrangé wrote:
> > 
> > After adding the new $YEAR/$ID.xml file, 'make' will build the
> > corresponding indexes and HTML/TXT renderings. Ideally the machine which
> > is hosting the QEMU website would run 'make' after pulling new
> > commits. In this series, however, I have just commited the rendered
> > content to git.
> 
> "git push" is already running Jekyll, which has a templating mechanism
> similar to the one used for blog posts
> (https://jekyllrb.com/docs/collections/).  Basically one security notice
> would be a file in a _secnotices directory, with the metadata in a YAML
> preamble like this:
> 
> ---
> title: Speculative store bypass
> id: 2018-001
> date: 2018-05-21
> reported: 2018-03-12
> fixed: 2018-06-26
> 
> credits:
>   - reporter:
>     - name: Ken Johnson (Microsoft Security Response Center)
>     - name: Jann Horn (Google Project Zero)
>   - patcher:
>     - name: Daniel P. Berrangé
>       email: berrange@redhat.com
>     - name: Konrad Rzeszutek Wilk
>       email: konrad.wilk@oracle.com
> 
> advisories:
>   - type: CVE
>     id: 2018-3639
> 
> branches:
>   - master:
>       state: fixed
>       change:
>       - d19d1f965904a533998739698020ff4ee8a103da: fixed
>       - 403503b162ffc33fb64cfefdf7b880acf41772cd: fixed
>       - 4f50c1673a89b07f376ce5c42d22d79a79cd466d: merged
>       - a764f3f7197f4d7ad8fe8424269933de912224cb: fixed
>       - e409d9a158c77c650651e8118f6c86c8dc76eba6: merged
>       - 7ba1e61953f4592606e60b2e7507ff6a6faf861a: vulnerable
>       tag:
>       - v0.10.1: vulnerable
>     ...
> +---
> 
> {% contentfor description %}
> An industry-wide issue was found in the way many modern microprocessor
> designs have implemented speculative execution of Load & Store
> instructions (a commonly used performance optimization).
> +
> +It relies on the presence of a precisely-defined instruction sequence
> in the privileged code as well as the fact that memory read from address
> to which a recent memory write has occurred may see an older value and
> subsequently cause an update into the microprocessor's data cache even
> for speculatively executed instructions that never actually commit (retire).
> {% endcontentfor %}
> 
> {% contentfor impact %}
> As a result, an unprivileged attacker could use this flaw to read
> privileged memory by conducting targeted cache side-channel attacks.
> {% endcontentfor %}
> 
> {% contentfor mitigation %}
> None
> {% endcontentfor %}
> 
> 
> (Requires the jekyll-contentblocks plugin).

I really don't want to use an application specific templating system.
While we're using Jekyll for the website today, I don't think it is
a good idea to assume that for the longer term.

Even today I can't actually run the jekyll website on my laptop because
the qemu-web content uses templating syntax from an older version of
Jekyll that has been deleted in the current Jekyll versions. So I have
to hack the code to remove pieces, in order to do testing.

> I am not a YAML fan, but I still would probably have to hide if I
> suggested using XSLT to convert the XML files to YAML. :)  Still, one
> question is obvious: is the XML an industry standard?  That would make
> it more palatable...

XML itself is an industry standard, so every OS has tools for querying
and transforming the documents in standard manner, which is the key thing
which is appealing to me.

Even though JSON itself is a standard, there's no standard equvalent to
XSLT or XPath for querying and transforming JSON. You end up having to
write programs to parse, and then reformat the data in alternative formats,
and the program itself has to be written portably. Document format
transformation is what XSLT excells at, IMHO.

This particular XML format isn't an industry standard.  NIST has an XML
schema for reporting CVEs, but it only partially overlaps with the bits
of data I record here.  So we would have to use XML namespaces to add
fields for the extra pieces we want - the GIT data is the biggest
pieces.

As with many standards though, NIST schema goes for extreme generality
at the cost of making it a very unfriendly document format for humans
to read. So don't think I could recommend using the NIST schema as a
master format - even I would hate using it. It is the kind of thing
you would want to generate from our more friendly format instead.

eg compare this NIST data for a recent QEMU flaw:

  <entry id="CVE-2018-5683">
    <vuln:vulnerable-configuration id="http://nvd.nist.gov/">
      <cpe-lang:logical-test operator="OR" negate="false">
        <cpe-lang:fact-ref name="cpe:/a:qemu:qemu"/>
      </cpe-lang:logical-test>
    </vuln:vulnerable-configuration>
    <vuln:vulnerable-software-list>
      <vuln:product>cpe:/a:qemu:qemu</vuln:product>
    </vuln:vulnerable-software-list>
    <vuln:cve-id>CVE-2018-5683</vuln:cve-id>
    <vuln:published-datetime>2018-01-23T13:29:00.580-05:00</vuln:published-datetime>
    <vuln:last-modified-datetime>2018-09-07T06:29:06.303-04:00</vuln:last-modified-datetime>
    <vuln:cvss>
      <cvss:base_metrics>
        <cvss:score>2.1</cvss:score>
        <cvss:access-vector>LOCAL</cvss:access-vector>
        <cvss:access-complexity>LOW</cvss:access-complexity>
        <cvss:authentication>NONE</cvss:authentication>
        <cvss:confidentiality-impact>NONE</cvss:confidentiality-impact>
        <cvss:integrity-impact>NONE</cvss:integrity-impact>
        <cvss:availability-impact>PARTIAL</cvss:availability-impact>
        <cvss:source>http://nvd.nist.gov</cvss:source>
        <cvss:generated-on-datetime>2018-02-12T11:20:01.123-05:00</cvss:generated-on-datetime>
      </cvss:base_metrics>
    </vuln:cvss>
    <vuln:cwe id="CWE-125"/>
    <vuln:references xml:lang="en" reference_type="VENDOR_ADVISORY">
      <vuln:source>MLIST</vuln:source>
      <vuln:reference href="http://www.openwall.com/lists/oss-security/2018/01/15/2" xml:lang="en">[oss-security] 20180115 CVE-2018-5683 Qemu: Out-of-bounds read in vga_draw_text routine</vuln:reference>
    </vuln:references>
    <vuln:references xml:lang="en" reference_type="VENDOR_ADVISORY">
      <vuln:source>BID</vuln:source>
      <vuln:reference href="http://www.securityfocus.com/bid/102518" xml:lang="en">102518</vuln:reference>
    </vuln:references>
    <vuln:references xml:lang="en" reference_type="UNKNOWN">
      <vuln:source>REDHAT</vuln:source>
      <vuln:reference href="https://access.redhat.com/errata/RHSA-2018:0816" xml:lang="en">RHSA-2018:0816</vuln:reference>
    </vuln:references>
    <vuln:references xml:lang="en" reference_type="UNKNOWN">
      <vuln:source>REDHAT</vuln:source>
      <vuln:reference href="https://access.redhat.com/errata/RHSA-2018:1104" xml:lang="en">RHSA-2018:1104</vuln:reference>
    </vuln:references>
    <vuln:references xml:lang="en" reference_type="UNKNOWN">
      <vuln:source>REDHAT</vuln:source>
      <vuln:reference href="https://access.redhat.com/errata/RHSA-2018:2162" xml:lang="en">RHSA-2018:2162</vuln:reference>
    </vuln:references>
    <vuln:references xml:lang="en" reference_type="UNKNOWN">
      <vuln:source>MLIST</vuln:source>
      <vuln:reference href="https://lists.debian.org/debian-lts-announce/2018/09/msg00007.html" xml:lang="en">[debian-lts-announce] 20180906 [SECURITY] [DLA 1497-1] qemu security update</vuln:reference>
    </vuln:references>
    <vuln:references xml:lang="en" reference_type="VENDOR_ADVISORY">
      <vuln:source>MLIST</vuln:source>
      <vuln:reference href="https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg02597.html" xml:lang="en">[Qemu-devel] 20180112 Re: [Qemu-devel] [PATCH v3] vga: check the validation of memory addr when draw text</vuln:reference>
    </vuln:references>
    <vuln:references xml:lang="en" reference_type="UNKNOWN">
      <vuln:source>UBUNTU</vuln:source>
      <vuln:reference href="https://usn.ubuntu.com/3575-1/" xml:lang="en">USN-3575-1</vuln:reference>
    </vuln:references>
    <vuln:references xml:lang="en" reference_type="UNKNOWN">
      <vuln:source>DEBIAN</vuln:source>
      <vuln:reference href="https://www.debian.org/security/2018/dsa-4213" xml:lang="en">DSA-4213</vuln:reference>
    </vuln:references>
    <vuln:summary>The vga_draw_text function in Qemu allows local OS guest privileged users to cause a denial of service (out-of-bounds read and QEMU process crash) by leveraging improper memory address validation.</vuln:summary>
  </entry>

With what I have proposed here:

    <security-notice xmlns="http://qemu.org/xmlns/security-notice/1.0">
      <id>2018-002</id>
    
      <summary>VGA out of bounds in vga_draw_text</summary>
    
      <description>
    <![CDATA[Quick Emulator(QEMU) built with the VGA emulator support is
    vulnerable to an out-of-bounds access issue in vga_draw_text. It
    could occur while updating vga display area.]]>
      </description>
    
      <impact>
    <![CDATA[A privileged user inside guest could use this flaw to crash
    the Qemu process resulting in DoS.]]>
      </impact>
    
      <mitigation>
    <![CDATA[Disable graphics adapters if the virtual machines can be
    operated via the serial console]]>
      </mitigation>
    
      <credits>
        <reporter>
          <name>Jiang Xin</name>
          <email>jiangxin1@huawei.com</email>
        </reporter>
        <patcher>
          <name>Lin ZheCheng</name>
          <email>linzhecheng@huawei.com</email>
        </patcher>
      </credits>
    
      <lifecycle>
        <reported>20171228</reported>
        <published>20171225</published>
        <fixed>20180125</fixed>
      </lifecycle>
    
    
      <reference>
        <advisory type="CVE" id="2018-5683"/>
      </reference>
    
      <repository>
        <branch>
          <name>master</name>
          <tag state="fixed">v2.12.0</tag>
          <change state="fixed">191f59dc17396bb5a8da50f8c59b6e0a430711a4</change>
          <change state="merged">b3bbe959b5dc3bf07041946455cc8e8d562bfd1f</change>
          <tag state="vulnerable">v0.4.4</tag>
          <tag state="vulnerable">v0.5.0</tag>
          ...snip...
        </branch>
        <branch>
          <name>stable-2.11</name>
          <tag state="vulnerable">v2.11.1</tag>
          <tag state="vulnerable">v2.11.2</tag>
          <change state="vulnerable">e89f66eca974d2a9d5d89271c6041daefdab2105</change>
        </branch>
      </repository>
    
    </security-notice>

Regards,
Daniel
Paolo Bonzini Oct. 19, 2018, 12:08 p.m. UTC | #3
On 19/10/2018 12:25, Daniel P. Berrangé wrote:
> I really don't want to use an application specific templating system.
> While we're using Jekyll for the website today, I don't think it is
> a good idea to assume that for the longer term.
> 
> Even today I can't actually run the jekyll website on my laptop because
> the qemu-web content uses templating syntax from an older version of
> Jekyll that has been deleted in the current Jekyll versions. So I have
> to hack the code to remove pieces, in order to do testing.

Note that you can use

   bundle install --path .gems
   bundle exec jekyll serve

in order to use locally-downloaded gems.

That said, we should indeed update Jekyll to a more recent version.

Paolo