We run automated vulnerability scans of our Windows hosts that collect software inventory and inspect program version information from what I suspect is the registry. We also keep Jenkins up to date using the Upgrade Automatically feature in the Web UI. However, even though the Jenkins Web UI shows that we are using version 2.387.2, Add/Remove programs shows that we are using v2.222.4 which gets reported to our vulnerability scanner (and thus creates critical security findings) which then creates headaches for me because I have to explain to the InfoSec auditors that we really aren’t on that old version.
Is there a way to get the registry or Add/Remove programs to display the currently installed version of Jenkins?
No, this is a registry value that is only updated during install via the MSI. It wouldn’t be safe for Jenkins itself to update the registry value during an in place update, as it would require elevation to do so.
I am experiencing this with the .msi installer for both version 2.426 and 2.427. I stopped the Jenkins service, ran the upgrade with the .msi installer and although Jenkins is upgraded, the version in Windows > Programs and Features is still the older 2.255.4270. This is showing up on a vulnerability scan list so I need to get this version updated soon to get IT off my back.
This response is insufficient. Security scanners will flag this as a known vulnerability. If Jenkins won’t update the registry properly (you have to be elevated to install the software, service, etc?) - can you please at least provide guidance on how to update the registry such that it could be kept in synch with the Jenkins versions?
If some details could be provided on how the version value in the registry is derived (and perhaps how the corresponding version of the stored is determined) - I’d be happy to provide some possible (probably PowerShell) solutions. I’m guessing the scanner is looking at ‘Version’.
The version is converted from the normal Jenkins versioning (e.g., 2.440 or 2.440.2) here in the installer project:
Do you have 2.440 installed on your system, or 2.389? Decoding the “Version” field in your screenshot gets:
2 255 3890
The 2 is the major version, the 255 indicates that the minor version and build are encoded into the last number. The lowest digit (0) means that it is not an LTS install, then we divide by 10 and the minor version in there is 389. So, it doesn’t match with what is in the “ProductName” field.
You can also look at this are to see how to extract the version of Jenkins from the WAR file itself:
I would recommend updating both the ProductName and Version values in the registry.
If you want to lookup the location of the Jenkins install, you can look here:
Those keys should be usable to find the local jenkins.war file to get the version information from it.
I’m happy to help if you run into issues. Do you think a powershell script would be fine for people instead of an application? We could include it in the MSI and put it into the installation directory (not Jenkins root) and people could run it when they upgrade the war file. I think we could add something to the note when upgrading in the Jenkins UI to tell people about it as well.
I think any kind of simple, ‘run this when you upgrade’ would at least provide people a path forward. Users who work in security-heavy locations have few alternatives right now.
I wrote a Powershell script. I’ll submit a PR to get it included in the installer. You can download and take a look if you would like.
It also updates the area in the registry that the Apps area in System settings gets its data from as well so that when you look there it will show the version of the war.
It’s currently AuthenticodeSigned with my own self generated key, so if you wanted to run it, you would want to remove that. It will be signed with the Jenkins project key in the installer.
