Status: Open (View Workflow)
Windows 7 x64.
Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode).
From mailing-list entry "Verify downloaded jpi-files":
Jenkins does not seem to verify the integrity of downloaded plugins right after the download has completed. Rather, the verification is only done when attempting to install/upgrade the plugin.
This concequence of this is that corrupted plugin updates will trigger a plugin uninstall instead of upgrade. Any job-configuration related to the accidentally uninstalled plugin is then also deleted, which is pretty serious.
Steps to reproduce:
1: Create a job with a subversion working-copy workspace.
2: Configure plugin manager with invalid PROXY settings, so that non-intranet HTTP-requests returns a HTML error webpage (instead of connection refused).
3: Upgrade the subversion plugin.
4: Jenkins will download a corrupted subversion.jpi file containing HTML content without any error message.
5: Restart Jenkins.
6: Loading of subversion.jpi will fail (error log attached).
7: The subversion plugin will be uninstalled.
8. Subversion-related configuration in all jobs will be deleted!
- is duplicated by
JENKINS-23596 jenkins plugin vanished after update
- is related to
JENKINS-21485 AdministrativeMonitor for plugins that have failed
Also observed when the download starts off with valid file, but it gets truncated.
Trying java.util.jar.JarFile.<init> might suffice to validate it.
Could be done from an implementation of hudson.model.UpdateCenter.UpdateCenterConfiguration's postValidate(DownloadJob job, File src)
90% of this has been resolved in Jenkins 1.625.3 / 1.641 with the checksum verification when downloading from an update site. Two cases remain:
1. Manual file upload can upload broken files
2. Broken update sites serve broken files and checksums match
I think we can mostly dismiss the second case, but the first one seems interesting enough for this issue to remain open.