Publishing CVE's

Help / Discuss
, ,
1

Reading the Release Notes for XWiki 17.10.8 (XWiki.org) with the note

This is a bug fix release. It contains security fixes, with the highest severity being 9.3/10.

is confusing and hard to decide on the risks associated with our deployment.

Reading the section on XWiki Security Policy - XWiki and the note

  • Once the CVE has been released and the security issues are public, they’ll appear in past release notes.

is not clear. Does that mean the CVE’s fixed in 17.10.8 will be made available after 17.10.9 will be released?

2

No. As far as I understood past discussions it’s 3 month after 17.10.8. So should be around 17.10.11 then.

3

Hello @peter.viskup,

You can see our disclosure best practices, as well and everything related to our security policy at https://dev.xwiki.org/xwiki/bin/view/Community/SecurityPolicy/#HHowlongdoesittaketopublishaCVE3F

Once an issue has been fixed and released, an embargo of at least 3 months is starting to allow anyone working with XWiki to perform actions before the publication of the CVE. The embargo might be longer than 3 months, in which case extending the embargo might be decided through a vote on the forum. The sponsoring companies are automatically informed as soon as a security issues has been discovered through the security communication channels.

For example, if a security issue has been fixed and released in 11.10.2 and in 12.0, respectively released the 5th of February and the 29th of January, the CVE could be published 3 months after latest release: i.e. the 5th of May.

So in short, when you see that a release note mentions security fixes you know that you have at least 3 months after that to upgrade before the issues are disclosed.

4

Note that bug fix releases are not released every month. They’re released as needed (depending on the bug fixes done for them). See https://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices/

  • For Bugfix releases we have the following release strategy:
    • For the LTS branch:
      • Try to release regularly without too much time spent between 2 bugfix releases (right now it’s left at the appreciation of the committers to review the list of fixed issues and decide when to release).
      • We allow to perform a release that has blocker issues fixed, even if there are still other important issues not fixed (including other blocker issues). The goal is to provide a LTS as stable as possible, as quickly as possible.
    • For other branches:
      • Left at the discretion of the committers to decide (it depends how close we are to releasing a new minor versions for example).