My guess is that whatever produces the updates.jenkins-ci.org content was changed to assume that the digest would be computed from JSON canonicalized by the new JSON library, whereas older versions of Jenkins have slightly different content.

Emergency workaround:

1. Shut down Jenkins.
2. Download http://jenkins-updates.cloudbees.com/update-center.json?version=1.480.3 and save it somewhere.
3. Edit the file, stripping off the first and last lines: updateCenter.post( and );
4. Save as $JENKINS_HOME/updates/default.json.
5. Restart Jenkins.
6. /pluginManager/available should now list the right plugins. Ignore those marked Jenkins Enterprise by CloudBees Plugin since they would require a Jenkins Enterprise license to run.
7. Repeat 1–5 to check for new updates.

I would have thought 1–5 could be done simply by saving a new URL in /pluginManager/advanced but it seems this does not work; even if you click Check now Jenkins does not even try to download the specified update center content. Not sure why not.

Found out why setting this URL in the GUI does not work: the JSON reports "id":"jenkins-enterprise" rather than "id":"default". This is better reported as of 1.482 (285a508); in 1.480.3 you just get a cryptic Uncaught TypeError: Cannot read property 'postBack' of undefined.

Thanks. I copied the default.json from one of my other jenkins servers and now I am getting a lists of plugins again. Thanks for the workaround. Hoping for a better long term resolution to follow.

I wonder if https://github.com/jenkinsci/backend-update-center2/commit/88deadded6fd8bca4f524f0fba5d5d94e0464cb6 is related? But that was two months ago, and complaints about the update center just started appearing.

Using /script in 1.506:

text = new java.io.File('…/updates/default.json').text;
json = net.sf.json.JSONObject.fromObject(text);
sig = json.remove('signature');
sha1 = java.security.MessageDigest.getInstance("SHA1");
baos = new ByteArrayOutputStream();
w = new OutputStreamWriter(baos, "UTF-8");
json.writeCanonical(w);
w.close();
sha1.update(baos.toByteArray())
computedDigest = hudson.remoting.Base64.encode(sha1.digest());
providedDigest = sig.optString("correct_digest");
println('computed: ' + computedDigest);
println('provided: ' + providedDigest);

→

computed: A76w9trilqKAm1tpJ+SXC/VOu48=
provided: A76w9trilqKAm1tpJ+SXC/VOu48=

And in 1.505:

computed: WxtpFxOUSOkkuCHxUidvdFExQWA=
provided: A76w9trilqKAm1tpJ+SXC/VOu48=

So this does indeed look like a json-lib incompatibility.

There is a json-lib incompatibility, but it would not matter except for https://wiki.jenkins-ci.org/display/JENKINS/JobRequeue-Plugin which has weird formatting that tickles a bug in the older version of json-lib. That was released on Apr 17, causing the UC to break.

https://wiki.jenkins-ci.org/display/JENKINS/drmemory+plugin is weird too but does not seem to be triggering the bug.

Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/org/jvnet/hudson/update_center/Plugin.java
http://jenkins-ci.org/commit/backend-update-center2/ea405aaa6d1aef116ce3966695a1c431eb1d161c
Log:
[FIXED JENKINS-17677] Avoiding excerpts likely to tickle a bug in the old json-lib.

My changes seem to have worked in that if you set the update center URL to https://ci.jenkins-ci.org/job/infra_update_center/ws/www2/update-center.json everything works. This does not seem to have propagated to mirrors yet; I am not sure when that happens.

I guess the system is “smart” and offers you the stable update center if you are running an LTS; since these are built only every four hours, my fix has not appeared yet:

$ for version in 1.480 1.480.3; do if curl -sL "http://updates.jenkins-ci.org/update-center.json?version=$version" | fgrep -q '"{'; then echo $version bad; else echo $version OK; fi; done
1.480 OK
1.480.3 bad

Now it is there.