there’s another thing that I just realized, while discussing live with @caubin:
- for all the security problems in this category, AFAIU, in the current implementation, the admin of the wiki and the XWiki team will find out about the security problem at the same moment - when the CVE is published by the third party dependency. I don’t really know whether the value of this is as high as the alert (and confusion) it may create - the admin of the wiki will need to understand this, that a security issue cannot be fixed immediately, that a new version takes time to release, etc. Also, they may not understand what’s the point of showing it to them in their wiki.
Users may not be used to such transparency (as the one we’re building with the informative dimension of this feature), and if we decide to keep it, we’ll need to be very clear about it means, in terms that are easy to understand for anyone, regardless of their technical level, that would increase the user’s confidence rather than make them more worried. We need to manage to convey the information that “there will always be issues or risks, all we’re doing here is make sure to catch these issues early, which is better than pretend they don’t exist”). The problem here is that it takes an experienced professional to know that a software will always have bugs, even if they’re not known yet; the only time when there are 0 bugs is when there hasn’t been enough testing… I’m not convinced that most users of software have favorable mental habits on this topic (so we’d be part of building these habits), and even if they do, there may be biases and emotions involved when talking about “security problems”…
The more I think about it, the more I think that this feature should be a channel for actions - as other software do when they tell about an issue only when they also have a solution for it (e.g. gitlab) - rather than an informative thing.
Thanks,
Anca