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).