New section in Release Notes to display information about security issues

Development
1

Hi everyone,

as part of the Security Policy vote I throw an idea about adding some more information in the release notes about security issues. It was just a wild idea, that I’ll try to formalize here as a proposal. Note that in this proposal I assume we agree on a grace period between the publication of the release notes and the publication of the confidential security issues. I don’t make assumption on how long is this grace period though: could be a week, 3 months or a year it doesn’t change this proposal.

I’m proposing to add 2 new sections in the releases notes, one entitled “Fixed Security Issues” and another one entitled “Known Security Issues”.

At the moment of the release, Fixed Security Issues would contain a standard message, such as:

XX security issues have been fixed as part of this release. Those fixed security issues will appear below whenever they get published.

where “XX” is the known (by the release master) number of issues marked as confidential and fixed in the release.
Below that message we would insert a JIRA macro with a query like this:

Project in ("XWiki Commons", "XWiki Rendering", "XWiki Platform") and fixVersion in ("11.10.11") and labels in ("security-public")

Then each time a security issues get published (by setting the confidential field), we would also set the dedicated label “security-public” so it would appear in the release notes.

Now in the section “Known Security Issues”, we would display in the contrary a JIRA macro or a JIRA link with the same kind of query but for affectVersion:

Project in ("XWiki Commons", "XWiki Rendering", "XWiki Platform") and affectVersion in ("11.10.11") and labels in ("security-public")

This would allow to be able to have a very quick idea of the security state of a specific release.
WDYT?

2

We don’t really need a dedicated “security-public” label since the request won’t return confidential issues anyway. We should just use the “security” label we already usually put in those issues.

3

ok, I think we need the message to explain why, but that’s a detail.

Manual process? Would need a new step in the RP.

Actually Category = 10000 is better :wink:

We just need to remove the “confidential” security field to make an issue public.

Thus we can run this query all the time and won’t have to update the RN after it’s been published.

Ok, so this is to see in the future the disclosed issues that were affecting this release. Makes sense. Note that we will need a big disclaimer since this can only a be a best effort. Also you need to use <= and not in. It’s a best effort because we don’t put ALL versions that are affected by an issue, it would be too much work. Sometimes we put affects = “12.6” when actually version “8.3” is also affected but since we haven’t tested we’re not sure…

4

Ok makes sense then. I wasn’t sure how confidential issues were handled by the macro.

Sure the message should be refined.

Indeed.

The idea was not to update the RN, but to add the label to the issues. But as Thomas mentioned we don’t need a special label, so indeed removing the “confidential” would be enough.

Yes indeed.

Good point.

5

The macro use the REST API and the REST API won’t let you see confidential issues if you don’t have the right to.