Hi! I’m aware of this topic and about August 2024 roadmap. It seems that Security Vulnerabilities application is under active development. I’m just posting to add a description of a behavior I’m not able to explain to the information systems security officers here.
The red bell on the navigation bar says that the scan has identified two (2) extensions with known vulnerabilities, but the list includes only one (1):
Also, two (2) is not the number of environment vulnerabilities. Three (3) are in the list:
Why does the red bell say two (2), please?
Both images above were screenshotted yesterday. Today, after a new indexing cycle, we get the same results.
I need to cope with Security Vulnerabilities application if I want to promote the XWiki use at my current institution. The team is far from being opened to accept alternatives to the tools we are currently using, and we have had huge security issues that paralyzed the center for weeks, even months. It is completely out of my scope to analyze the reasons of that situation, but I can propose solutions for cases of use. XWiki is great from many points of view. But it is for me even more valuable its team and the way you and the community address issues and new developments.
2 is actually the number of vulnerabilities which don’t have an explanation to suggest XWiki is not actually impacted (so kind of unknown known vulnerabilities, “known” in this context just referring to the fact that they are public in the database of CVEs, but we sometimes don’t know about them ourselves yet).
I agree with you that the separation is really not clear in the UI (the only difference, I think, is that the “analyzed” ones have a little document icon next to the CVE), and that’s one of the reasons why we decided to spend more time on this UI before enabling it by default.
By the way, I’m surprised by this snappy report. Is this extension coming as a dependency of some extension you installed (you can check that in the Extension Manager by checking the dependency tab in the detail of the snappy installed extension) ? That would be something to fix in that extension.
Cool! It is much clearer to me now. I will survive with this explanation. Thanks!
Things are clearer to me know after expending some time reading other topics and papers and your first paragraph above. I will keep a close eye on new developments
Following your explanation, I get deeper on the vulnerabilities’ correction process and update snappy to release 0.5. The red bell shows now only one (1) environment vulnerability (org.webjars:bootstrap/3.4.1). snappy is no longer in the list.
It would be great if you could go up the hierarchy of dependencies to find the top level extension which triggered this dependency to this vulnerable snappy (so click on Plexus Archiver Component, which is itself something that was installed as dependency, check its backward dependencies, etc. and yes this search is also something we want to add in this UI before enabling it by default).
“must”, not. It’s generally even a bit risky to upgrade a dependency unless you know for sure it’s retro compatible (it might break the top level extension, which was not really tested with it).
Anyway, I’m going to check how to update those dependencies in LaTeX Exporter itself so that a user who install it does not end up with a vulnerable dependency. I’m actually a bit surprised it needs Plexus Archiver at runtime at all.
LaTeX Exporter 1.25.1 is now available, I only upgraded snappy to be safe. Plexus Archiver might have caused problems on older version of XWiki for now.
Your local index of available extensions might not be up-to-date (it’s supposed to refresh every 1 or 2h, I don’t remember), you can force refreshing it below the list.
More than three hours after you make 1.25.1 available, it seems that the local index of available extensions has not updated yet. I will keep checking now and them. Let me know if any other check can or must be done. Thanks!
It’s strange, sounds like a bug but would need to find the way to reproduce it. Would be great if you could create a BUG issue on Loading... with everything you remember about what happen related to Latex Exporter (index when 1.25.1 did not exist, install 1.25, 1.25.1 was released, installed other things in between, etc.).
In the meantime, you can probably “fix” this that deleting the index and let XWiki recreate it from scratch. For that, you will need to:
stop XWiki
delete the <permdir>/cache/solr/extension_index_9 (or <permdir>/cache/solr/extension_index for older versions of XWiki)
Thanks. Before deleting anything, here what I found under <permdir>/cache/solr/:
root@IGFAE-MU-07-MacPro:/var/lib/xwiki/data/cache/solr# ls -l
total 16
drwxr-x--- 5 tomcat tomcat 4096 oct 5 2023 extension_index
drwxr-x--- 5 tomcat tomcat 4096 mar 26 09:22 extension_index_9
drwxr-x--- 5 tomcat tomcat 4096 oct 5 2023 search
drwxr-x--- 5 tomcat tomcat 4096 mar 26 09:22 search_9
I have to delete both folders, haven’t I? It seems that some changes were introduced between 5 October 2023 and 25 March this year. Could the presence of both folders affect the function of the index?
I will do my best to create the BUG issue, although I don’t remember what happened between the original install and the situation described in this topic.
