making resolution optional for a couple more packages

[wwannemacher]

I ran into some problems using xstream 1.4.11.1 in an OSGi container (running inside of an OpenJDK 8 JVM). I didn't do extensive research, but it seems that some of the packages are very unlikely to be available. I think that your OSGi plugin may have detected a couple of Class.forName calls and figured that the packages needed to be available.

Anyhow, I don't know how quickly you guys run releases, but we'd like to upgrade to 1.4.11 or later, but this issue blocked us. Thanks!

[coveralls]

Coverage remained the same at 78.394% when pulling df14eef on wwannemacher:osgi-fix into ab626fb on x-stream:v-1.4.x.

[wwannemacher]

here is an example of why we were looking to upgrade to 1.4.11 or above:
sonatype-nexus-community/nexus-repository-conda#16

[joehni]

This has been resolved as part of #152. However, please answer me following questions:

• Why do you care about a vulnerability for a test dependency that is not available at runtime?
• Version 1.4.10 is only vulnerable for known types of the Java runtime, if the security framework available with 1.4.7 is still not initialized - did you check that for powermock? Otherwise your classpath might contain other types that might be used for the same vulnerability for all Version 1.4.x of XStream.
• Powermock might initialize the security framework and explicitly allow all types i.e. it does not matter, which version of XStream you are using - it will be vulnerable. Did you check that?

So much for these kind of vulnerability reports. They give a hint, but may also produce a wrong sense of safety.

[wwannemacher]

I did not see that the issue was already resolved, I had begun working on it before that change landed. So, I'll close this PR. However, since you asked, I will answer your questions:

• Why do you care about a vulnerability for a test dependency that is not available at runtime?

In my comment, I mentioned that the link was "an example" the actual problem is here: https://github.com/sonatype/nexus-public/blob/master/buildsupport/rest/pom.xml#L76

I figured it was a more convoluted situation, but nexus is built on an OSGi container, which is why we ran into the problem.

• Version 1.4.10 is only vulnerable for known types of the Java runtime, if the security framework available with 1.4.7 is still not initialized - did you check that for powermock? Otherwise your classpath might contain other types that might be used for the same vulnerability for all Version 1.4.x of XStream.

Again, I was using an example, so the research I did was against nexus. In our case, xstream is a transitive dependency. In my case, I was aware that there is a workaround in 1.4.10, but I also noticed that versions 1.4.11 and up did not appear to be susceptible. So, I'm left to try to figure out - dig into someone else's code (since it is a transitive dependency, and also not a test dependency in nexus), or update to a later version. I figured that the update would be easier. However, i ran into the OSGi issues and then thought that it might be easy to just fix those, thus this PR.

• Powermock might initialize the security framework and explicitly allow all types i.e. it does not matter, which version of XStream you are using - it will be vulnerable. Did you check that?

I'm really getting the sense that you're angry that I even brought up the issue... I was unaware that you had worked on the problem and had hoped that a PR would be helpful. I appreciate that the issue was already fixed.

In my case, I had presented an example of what folks may see if they are using 1.4.10 and below. I now realize that it was a bad example because the xstream dependency in that case was scope=test.

So much for these kind of vulnerability reports. They give a hint, but may also produce a wrong sense of safety.

This feels like a bit of an attack. The company that created the linked report is the company that I work for. Although I used that one as an example, the original report against nexus (which we run internally, so I did not share it), included a link to here: #108. Therefore, even your analysis was included in the report. However, as I mentioned above, this is a transitive dependency to me, so I'm left with the choice between researching whether the security framework was properly initialized and just bumping the version number. I chose what I thought would be the simpler route.

[joehni]

Sorry, if I did sound angry, that was not the case. I just wanted to emphasis, that even when using 1.4.11 or later you might be affected, if the Security Framework is used to configure away all restrictions. Therefore: Such reports are a hint, but might not necessarily be able to tell the truth.

At least you'll get a warning on the console, if the security framework has not been initialized.

Regarding OSGi - I am no expert. I was just wondering what to to with the rest of the required imports - the ones that are an internal part of the Java runtime (sun.misc.*) or even depend on the Java vendor or those that are missing in Java 11. Therefore I've set all of them to optional now, but I have no clue, if it is the right thing to do.