Listing security issues of core extensions on the wiki

[vmassol]

ok so it’s a terminology issue I guess. For me core extensions are XWiki core extensions (since there’s no notion of extensions nor core extensions in servlet container in general). What we see in the CL coming from servlet containers are not extensions, they are just JARs.

How will you differentiate the real core extensions (ie from XWiki), from the fake core extensions (ie not from XWiki)? That was my question of the other day on matrix and why I said I didn’t understand what magic you were doing to differentiate them but I was happy that you had a way to separate them.

[tmortagne]

@vmassol

they are just JARs

The WAR is fool of things which are “just JAR” but it does not matter for Extension Manager since the point is to know what we already have so that we don’t install it again as dependency, so a JAR is an extension, it’s not an extension made by us, but it’s still an extension.

@vmassol

How will you differentiate the real core extensions (ie from XWiki), from the fake core extensions (ie not from XWiki)? That was my question of the other day on matrix and why I said I didn’t understand what magic you were doing to differentiate them but I was happy that you had a way to separate them.

As I said last time, each CoreExtension indicates the location (URL) of the JAR file, so it’s easy to know if it’s part of the WAR or not.

[vmassol]

@tmortagne

servlet section: only core extension, which file is not located in the WAR

ok, I now understand that this means listing vulnerabilities for jars that are not xwiki stuff but coming from the servlet container. Good! We’re on the same page (was worried that we were not understanding each other and that you were suggesting to mix stuff). Thanks, and sorry for the noise everyone.

[mleduc]

@tmortagne

Actually, I don’t think so, as for me the filtering is:

• servlet section: only core extension, which file is not located in the WAR
• false positive section: extensions (core/installed) which contains only false positive vulnerabilities
• everything else

lgtm.

Just not sure of one point. How would you represent an extension that have 4 vulnerabilities, including 2 false-positive ones?

Option 1: What I initially proposed, i.e., have the extension in two LDs, with only the relevant CVEs in each LDs
Option 2: If only part of the vulnerabilities of an extension are ignored, list it in the “main” LD, with a content like the following (can be refined but I find it hard to have something nice as we don’t have much horizontal space):

Option 3: Same as option 2, but with a way to fold the ignored vulnerabilities by default, and a button to unfold them.
Option 4: A mix of option 1 and option 2, the extensions appear on the two sections. On the main section, a note indicates that some ignored vulnerabilities exist (then, the user can switch to the other tab for more details)

[tmortagne]

@mleduc

Option 3: Same as option 2, but with a way to fold the ignored vulnerabilities by default, and a button to unfold them.

I think that’s the one I prefer, but 2 is fine too, but I would suggest to also make the “Ignored vulnerabilities” (not sure it’s the right wording since they are not ignored) have a different style (like smaller and ligher for example).

[mleduc]

@tmortagne

not sure it’s the right wording since they are not ignored

+1

Also, something is missing from my initial proposal. I think we don’t want to only list false-positive, but also present some additional text explaining why this is the case.
As explanations can be long, I think we should have a way to access the detail on a separate page (possibly displayed as a modal).
I’ll post something once I have a more concrete result but in essence, the information to display is:

• the project (e.g., xwiki standard, contrib extension X…)
• the CVE
• a textual explanation

[mleduc]

A very rough view of what it could look like can be seen in the following video (too large to be embedded).

[tmortagne]

@mleduc

A very rough view of what it could look like can be seen in the following video (too large to be embedded).

Note that the advice in the video can never work for a core extension