Verifying a MD5/SHA1 hash would of course be a "bullet proof" solution, but a simpler check against the in-built JAR/ZIP-file CRC-32 checksum would probably be good enough in most situations. I'm pretty sure that a CRC-32 check is triggered by just attempting to open the file.
kl. 14:35:57 UTC+2 fredag 27. juli 2012 skrev nicolas de loof følgende: > > update center (http://updates.jenkins-ci.org/download/plugins/) don't > includes md5 / sha1 checksums afaik, but this would be a good addition for > your use case and many others to avoid broken installations due to errors > during plugin download. > > 2012/7/27 Fredrik Orderud <[email protected]> > >> (Forwarded posting >> https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-users/2v8csoO0cxE) >> >> In my corporate environment, we are working behind a firewall that >> returns "nice" HTML webpages with detailed error instructions instead of a >> plain "connection refused" error in situations of invalid PROXY settings. >> >> We have experienced several times that Jenkins servers with improper >> PROXY settings will download jpi-files for plugin updates containing just >> "error HTML webpage" content. Jenkins doesn't seem to detect this, and >> instead tries to install the corrupted plugin. What then happens is that >> the plugin upgrade fails, and the plugin gets _uninstalled_ altogether. Any >> job-configuration related to the accidentally uninstalled plugin then also >> seems to be removed, which is pretty serious. >> >> Would it be possible to add some sort of integrity-verification to >> downloaded jpi-files prior to install them, so that we avoid accidentally >> uninstalling plugins? >> >> >> Thanks in advance, >> Fredrik Orderud >> > >
