we discussed in the past about dealing with old security issue in this thread: Dealing with old fixed security issues - #14 by surli. I recently discussed again this topic with XWiki SAS to also have their opinion, so I’m coming back with a final proposal that I submit to a vote so that we can move on on this subject.
My proposal concerns only the tickets on https://jira.xwiki.org that have a security level set as Confidential, and which have been closed before that we put in place our security policy (which has been put in place during XWiki 11.x cycle, so I’m counting here the issues with a fix version until 11.10.x).
The proposal is two folds, it consists in:
to remove the confidential label for all issues fixed with a fix version before XWiki 8.4.6, without creating any CVE for them
to remove the confidential label in one year for the remaining issues that are not part of our standard process, with a case by case review with XWiki SAS: e.g. some issues might get a CVE, some others might be just disclosed, and some might be delayed. Ideally this work won’t be done as batch in one year, but during the whole year by reviewing some tickets each month.
This vote is opened for two weeks, until September, tuesday the 13th.
However, shouldn’t also add a forum post for our users, to highlight the importance of upgrading because of security issues and a jira link to all disclosed security issues?
Also, make sure to add the security label in jira before your remove the confidential status.
I’ve noticed several issues in the “Security” component. Note that this component is good only when the fix is inside xwiki-platform-security modules. It’s very possible that this component was not used correctly for a lot of security issues and that it was used instead of the “security” label.
I don’t really see the point of creating such post now: it’s a general recommendation that any upgrade could contain security fixes. Not even necessarily coming from our code base, but also because it includes also lib upgrades. The fact that we disclose in few weeks some old security issues doesn’t change that. If we really want to create such post, I would advise to do it now actually to specify that we’re planning to disclose some old security issues and that it’s recommended to upgrade right now.
Regarding listing and linking the disclosed issues, I was not planning to do it. First because I didn’t wanted to advertise about those, but also because IMO those are old ones. Now I can keep at least a private list of the issues we disclose then to easily retrieve them (won’t be easy to list them afterwards), so that if somebody wants the list we can send them.
I think it’s something we have to do over and over and the more the better (not everyone thinks about this). And it doesn’t cost us much.
Why now? Because we’re about to disclose lots of security issues and thus it’s even more important since badly-intentioned people will be able to see these issues and take advantage of them. So it’s important that the good people are aware of what we’re doing (it’s a service to them) and that they know about these issues. It’s an added incentive to upgrade if they haven’t done so already.
Sure, I’m all for that.
I think someone badly-intentioned who wants to find them will do so easily, while our users may not if we don’t bring it to them. I don’t think it matters that we show them since they’re public. CVEs do exactly that, yet we publish them. Since there’s no CVEs for these, it’s important to publicly list them in a post IMO.
I agree it’s not expensive nor harmful. So I don’t see a problem of doing it (and publishing the list). Ok with the 2 step plan: we can do a first post now to remind people to upgrade knowing that we might disclose a bunch of old security issues in two weeks when the vote will be closed, and a second post when we effectively disclose the issues with the list.
we can do a first post now to remind people to upgrade knowing that we might disclose a bunch of old security issues in two weeks when the vote will be closed
