My understanding of the problem is that right now admins don’t have a simple way to know that an important vulnerability in their instance has been found and fixed in a recent release, before the vulnerability has been actually publicly disclosed.
This proposal is about solving this problem by creating a new dedicated mailing list for receiving announcements, and by defining a new step when releasing a version of XWiki to send information in that mailing list.
Right now release notes contain a very small piece of information regarding if it contains security fixes: only the impact of the worst vulnerability fixed in the release (see also discussions on that choice here: Indicate if there are security issues in the Release Notes)
Here I propose that we indicate a bit more info: at least, administrators need to know which version of XWiki is affected.
So the mail should indicate:
which version of XWiki has just been released with a link to RN
how many vulnerabilities has been fixed with the affected versions
the CVSS vectors
I’m hesitating to propose to also indicate the CVE number since we can request it before the CVE is published: it would allow easily admins to match the received announcement whenever the actual CVE is disclosed.
I don’t have much ideas for the ML name, maybe security-announcement@xwiki.org?
Also I’m hesitating between proposing to create a close ML or an open one: I don’t think it’s a problem to have it open.
Finally if we provide all those info in this ML maybe we’d like to revise what we put in our RN to put same info, that’s probably to be discussed.
-0 from me, I believe we need that info inside of XWiki using the notifications mechanism. Admins can then subscribe to that “app” to receive them by emails if they want.
The reason I’m -0 is that I believe we need that info inside XS (along with the notif for upgrades available + the security vulnerability app) and I don’t like to duplicate efforts and to also do it through another channel.
I also don’t think users who don’t have an xwiki instance installed will need that info so I feel it’s fine to have it inside of XS (with the ability to be notified outside of XWiki, by email).
+1 for the mailing list. Notifications inside XWiki won’t work for offline installations, and their admins should still have a way to be notified about important updates.
Good point re offline. I’m still convinced that 1) we’ll need that info inside of XWiki to push admins to upgrade and 2) that it shouldn’t make the RM job harder (ie it needs to be automated).
Yes. And the reason for this is that we didn’t want to disclose more than that, not because it’s in the release notes.
Are you saying that it’s not a read-only ML? If not, what would it be used for (knowing that we already have security@xwiki.org). Or do you mean a read only list but archived and visible?
Yeah, ideally we would put all the info in the RN (possibly in a special xpropery) which should be the master place containing all info about a release, and have some automated process to send the mail to the security-announcement ML.
I also missed that point and it’s another argument for the ML indeed.
I agree with that on the long run, but we know it will take time to do the design, develop, release, wait for people to upgrade etc. That’s why I proposed the ML: it’s easy to have it right now and it doesn’t feel it had too much work. But yes, we should work in parallel for having that in XS.
Yep, on my side I didn’t see that it was maybe needed by admins.
I meant that.
Again it’s maintenance to have that: I prefer we invest time working on automation inside XS itself, than working on automation to send email from RN. If it’s easy enough to gather the info in the RN, then copy/pasting in an email is adding only 1 more minute for the release.
I think it’s still worth it, we need to progress on reducing the release time, not increasing it.
Idea:
we have a mail sender api, it takes 5-6 lines of scripting (I can help).
(bonus) it will be sent with the FROM being consistent (and not the from of each RM)
We don’t need to make it fully automatic, but a button to trigger the execution of the mail sending script from the RN page for example (inside the security section for ex) would do it. The RM will just need to click it.
