Security Policy for XWiki

Sounds a bit weird to make high risk issues public and not the others. I feel we should simply apply the same 3 months rule before making the jira issue public (basically the main difference being that there is no CVE).

If we start disclosing all security issues then we need a CVE for all (the less important ones will just have a less important CVE). Otherwise, I don’t see how users will get to know them. Most companies will monitor CVEs so if no CVE is issues it’s likely they won’t notice them. How complex is it to have CVE for all? That’s the only reason I could think of of not doing it as otherwise it makes more sense to me.

It would make sense to send a warning on the security ML when we proceed to releasing public some security issues.

I don’t see the point if we list them in the release notes. What’s interesting to disclose on the security list is when they are found but that should already been taken care of by the “Confidential” jira issue list. We just need to decide if all members of the security lists also have the permissions in jira to see them.

Actually I’m starting to wonder if we shouldn’t provide a Release Note section about security issue when we perform a release containing confidential issue specifying that some important security issues have been fixed and information about them will be published in some times. This section would contain the JIRA request to display the confidential issue when they are publicly released (we might need some special label for that).

Why not but this proposal is missing the grace period. You need to leave some time after they been fixed so that users and companies can upgrade before making them known to the world. So I wouldn’t show them (even if they’re just about showing the jira ids since it’s easy to go check the GitHub history with a search in the id to check how to implement an attack).

The CVE process is not cost-free since it requires to perform all the appropriate check to determine when the security issue started etc. I’m afraid that it would be an heavy process for each of our security issues, now it would make the process far more easy to understand: no more CVE based on the severity of the issue, all the security issues would be handled basically the same way.

The point is about timing and about companies monitoring CVE as you said. If we don’t publish a CVE, even if we list the issues in RN they’re not published for all users, so sending a mail on the security list is the communication channel to inform about the fact that those issues become public. I agree we don’t need that if we have CVE.

Well it’s not: as I wrote the proposal is to display something like “XX important security issues have been fixed in this release notes” and then to call a JIRA request with something like “label = ‘security-published’”. Then you don’t display any security issue in the RN until they have been made public and you rely on a JIRA query with a label to not have to put specific JIRA keys.

ok, I missed this part and didn’t do a diff of the proposal text (not very easy to do).

You mean to compute the XX?

WDYM by “until”? I don’t see a proposal about how it would work.

PS: I’m not checking the proposal since I cannot differentiate what was there before from anything new. I’m only checking the comment replies here. It could be better to not touch it BTW since otherwise the comments thereafter make no sense. Better to write a new reply with the changes.

ok I guess I need to see the proposal written clearly since I’m replying blind here :slight_smile:

Where could I see the new proposal?


So since this is a different topic I just wrote a proposal here: better to use that new thread to continue this discussion.

So with 3 votes +1 and 0 other votes, I’m now closing this vote as accepted. I will publish our security policy on and on Github.