Indicate if there are security issues in the Release Notes

Hi devs,

It would be interesting for our users to know releases which have security issues since that makes it more compelling to them to upgrade. It also allows them to not upgrade if the new versions don’t have security issues fixed. See LTS updates with security issues

So here are 3 choices:

  1. Just indicate that the release contains security issues fixed
  2. Indicate the number of security issues fixed
  3. Indicate the number the number of high, medium and low security issues fixed

On my side, I’m fine with the 3 options. I think that 3) is acceptable.

WDYT?

Thanks

I prefer 1.

-0 for 2 and 3.

Note that the reason I think 2 and 3 are not a problem is because anyone who wants to find and exploit security flaws in XWiki doesn’t need to look at the release notes: they just need to look at the commits and the source code. Thus I don’t think it matters that we mention the # of issues and severities in the release notes. Actually I think it does matter that we do as it’ll definitely help users to be motivated to upgrade if they know that, say, an important security flaw has been fixed in a given version.

1 Like

Reviving this proposal since we just had the need with 13.9 release.
I’m +1 for 1 and 2, -0 for 3 but mainly because it’s more work when releasing and I don’t think it’s such an important thing to indicate.

Now as @tmortagne mentioned on Matrix, we also need to decide if we display those info only in RN or also in the blog and forum posts when a release is done.
We also probably need to add that in the release note template, and add the related check in release plan.

Yes.

+1 for 1 and 2
+0 for 3

+1 to display the information in the blog and forum posts.

I don’t think it’s more work (or really marginal) because we are already supposed to do the analysis and tag the security issues in jira accordingly. So it’d be just about copying that information.

Re the important part, I think it’s very different for a user to know if a release contains a critical security fix (it mean they MUST upgrade) from some low level security fix (they can wait to upgrade without problems).

In short 3) means putting the jira security tags visible in the RN.

Note: I still think that the main interesting point for our users are 3) ie. to know the severities and thus how important it is for them to upgrade. But we need to agree.

Once we start displaying more information about security fixes in the RN, our users will likely want to contact us to know more about the specific issues. So I think we need to anticipate this and add a paragraph in the RN linking to the Security Policy and link explicitly to the part mentioning when they’ll be made public.

+1 for 2.

Thanks,
Marius

What about indicating a) if security issues were fixed and b) the highest severity of the security issues fixed for the release? I don’t think the number of issues says much (there could many tiny issues or one very important one) but the highest severity might be interesting to know how urgent an update is.

A link to our security policy should also always be included to let users know what this severity means and to reference the disclosure policy.