Sonarqube 10.7 nowadays ships with 6 different JRE archives and the
$SONARQUBE_HOME/lib/extensions/sonar-javascript-plugin-10.16.0.27621-multi.jar is approaching the 100mb mark.
Our build servers have all the runtimes they need on path for a reason, why do we now have to struggle with additional settings !?
Imagine every tool / plugin provided its own runtimes, what a mess
The abililty to skip the provisioning ain’t consistent at all.
For the JRE it’s either the scanner property sonar.scanner.skipJreProvisioning or the environment variable SONAR_SCANNER_SKIP_JRE_PROVISIONING, but for node.js there’s only the scanner property sonar.scanner.skipNodeProvisioning but no environment variable.
This means all of our npm builds need to edit their build pipelines to be sure that our required node.js version is used.
What about critical CVEs in the provisioned runtimes, i.e. in April 2024 we had to update all of our node.js runtimes from 2.15.0 to 2.15.1 because of CVE-2024-27983,
see Node.js — Wednesday, April 3, 2024 Security Releases
If you want to insist on the provisioning after all, this should be a global setting in Sonarqube server, i.e. sonar.provisioning = true / false with default false.
Your idea of a global sonar.provisioning = false is indeed interesting.
Also, I think you make a good case for having consistent environment variables to make things easier for administrators to handle. I created a ticket for hardening before the next SonarQube release.
Regarding CVEs, as part of our regular hardening, we also upgrade the embedded version of Node.js to keep up with any vulnerabilities, as with any other components we ship.
To greatly reduce the .jar file size, we plan to provision only the required processor architecture. However, this requires updating the scanner. We started making this available in CLI, npm, and .NET scanners, and work is ongoing for Maven and Gradle.
Given that we support caching the plugin .jar files, and they are only downloaded when the language is detected, and besides the fact that you do not want to benefit from the embedded runtime, could you share how the size is causing problems for you?
Thanks for the ticket
I’m not sure if you will / want to release a new Sonarqube version for every CVE in an embedded runtime !?
Working for an insurance company we’re forced to update at once when there are critical CVEs.
WRT to the file size, it’s just nonsense for Enterprise customers, as our our build servers are staffed with all it needs.
The file size of sonar-javascript-plugin-10.16.0.27621-is bloated
WRT to caching, we’re using Jenkins nodes that are destroyed after use.
I know we could use some shared cache, but’s that’s just complicating things.
If the idea of provisioning is really implemented consistently, the dll for MSSQL integrated authentication would also have to be made available.
btw that’s almost a problem with every new Sonarqube version
The question is where to start and where to end with provisioning.
I would like to know where the idea of provisioning came from and I cannot imagine that this was a customer requirement.
With regard to “green it”, everyone should try to save some bandwitdh.
