Unable to install locally-built eclipse plugin, get "Error reading signed content"

Question

I inherited a largish Eclipse plugin codebase, which builds with Maven Tycho. The full build produces an update site for the plugin.

I've successfully tested the plugin by just running a test instance and specifying the plugins to load, but I'm now trying to install the plugin "normally" from the locally-built update site. In the update site entry, I specified the path to the zip file in the update-site target folder. It was able to present the list of features present in the update site (only the one). I checked that and continued. It got past the license approval and started to install, but then it failed with this:

An error occurred during the org.eclipse.equinox.internal.p2.engine.phases.CheckTrust phase. session context was:(profile=_home_opnfv_eclipse_java-neon_eclipse, phase=org.eclipse.equinox.internal.p2.engine.phases.CheckTrust, operand=, action=). Error reading signed content. error in opening zip file

From the .metadata/.log file, there is the following unsurprising stacktrace (excerpt):

!ENTRY org.eclipse.equinox.p2.engine 4 4 2016-02-10 18:22:49.495
!MESSAGE An error occurred during the org.eclipse.equinox.internal.p2.engine.phases.CheckTrust phase.
!SUBENTRY 1 org.eclipse.equinox.p2.engine 4 0 2016-02-10 18:22:49.495
!MESSAGE session context was:(profile=_home_opnfv_eclipse_java-neon_eclipse, phase=org.eclipse.equinox.internal.p2.engine.phases.CheckTrust, operand=, action=).
!SUBENTRY 1 org.eclipse.equinox.p2.engine 4 0 2016-02-10 18:22:49.495
!MESSAGE Error reading signed content.
!STACK 0
java.util.zip.ZipException: error in opening zip file
    at java.util.zip.ZipFile.open(Native Method)
    at java.util.zip.ZipFile.<init>(ZipFile.java:219)
    at java.util.zip.ZipFile.<init>(ZipFile.java:149)
    at java.util.zip.ZipFile.<init>(ZipFile.java:163)
    at org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:209)
    at org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.checkCertificates(CertificateChecker.java:73)

In searching for other occurrences of this, I've found various issues that seemed to be associated with this, but nothing concrete. I found a few people with the unsubstantiated advice to delete all the "artifacts.xml" files in the Eclipse distribution. As I didn't have any other suggestions, I tried that (saving them in a tar file first), and then restarted Eclipse, then reinstalled, but that had no effect.

I can't tell WHICH zip file this is complaining about. I imagine it's not the main update site zip. I looked at all the jar files present in "target/repository", and none of them are signed. It's not clear to me that they're supposed to be. As far as I know, the build process for this application should be producing a valid update site.

What other info can I provide that would illuminate this?

Update:

I tried removing one zip file from the equation by selecting "Local" instead of "Archive" when I created the update site entry in Eclipse, and instead of selecting "target/.zip", I selected "target/repository", which has the same content as the zip file. Unfortunately, this made no difference. Same error.

Update:

I have no idea whether this is significant, but I noticed that when Eclipse is attempting to install the plugin, it displays the seemingly innocuous "Install Details" page, which lists the plugins to be installed, but I happened to notice that below this plugin list is a "Size:" label, and the value on it is "0 bytes". Is this significant, and if so, what does that indicate?

Update:

After connecting a debugger to the target instance, I was able to discover that the corrupted jar is "$HOME/.p2/pool/plugins/org.eclipse.emf.mapping_2.9.0.v20160201-0859.jar". This file is not zero length, but "jar" and "unzip" report that the file is corrupted. I found four other "org.eclipse.emf.*" jars with a similar problem, and all other jars in the p2 repo are fine.

Now that I know which files are corrupted, what can I do about this? I tried moving the corrupted jar files to another location (and carefully logging the information) and then restarting Eclipse and reinstalling the plugin. It still fails with an error in the "CheckTrust" phase, but this time it reports the full path for the missing jar file.

How do I repair these files? Do I have to find valid copies of them somewhere on the net?

(I've filed a bug report to add the full path to the corrupted zip file in the original exception report.)

Wilow

From the look of the code in CertificateChecker this is just checking to see if the jar is signed, so the fact it is not signed is not the issue. – Rutland

Thanks for that. Any idea if there's more "verbosity" I can enable so I can at least tell which zip file it's failing to read? – Wilow

If it matters, I changed my test case so that it selects the "target/repository" folder using the "Local" button, instead of using the "Archive" button, to at least remove the containing "zip" file from the question. I updated the post to reflect this. – Wilow

Answer 1

What ended up happening here is that for some reason, five jar files in my "$HOME/.p2/pool" tree were somehow corrupted. It's possible this happened when my VM ran out of disk space a couple of weeks ago. I repaired the disk space problem, but it's possible that Eclipse failed to completely write something during that period.

The exception message that I received while trying to install a plugin unfortunately didn't mention WHAT archive file was corrupted. During this process, I filed the following bug report for the defective exception message: https://bugs.eclipse.org/bugs/show_bug.cgi?id=487954 . Someone enthusiastically checked in a fix for this the same day (apparently had been hit by this multiple times).

After I determined which archive files were corrupted, I had to somehow fix those files. This repository isn't like the local Maven repository, where you can just delete corrupted files and let the next Maven build restore them.

I posted this specific question on SO about this: How can I repair a damaged eclipse $HOME/.p2 repository? , and also on the Eclipse Platform forum: https://www.eclipse.org/forums/index.php/m/1723920/#msg_1723920 .

Eike Stepper made me aware of some of the capabilities of "Oomph", the core of the new Eclipse installer. There's a very easy to use "Bundle Pool Analysis" feature that automatically finds corrupted archives in this pool and gives you an action to automatically repair them. This is available from both the "Oomph" preferences in Eclipse, and also in the "Advanced Mode" in the new Eclipse installer.

I've been struggling with this series of problems for almost two weeks now, and it's finally all fixed.

Wilow

Answer 2

About the "0 size" issue: That usually happens when something is wrong with the "pack200" version of a bundle and the expanding the "*.jar.pack.gz" bundle fails. Not sure if you are creating the one that is a problem, or if you are getting that from another repository? About "increasing the verbosity" question: There is a wiki page at

https://wiki.eclipse.org/Equinox/p2/p2.mirrorsURL

that might help. The article is mostly about "mirrorsURL", but towards the end, it gives some options you can put in you .options file that increases the output of the process that p2 is going through. That might provide more information. Two debug options it mentions are

org.eclipse.equinox.p2.core/debug=true
org.eclipse.equinox.p2.core/artifacts/mirrors=true

From looking at the "tracing" page of 'run configurations' it appears some others might be relevant to your issue:

org.eclipse.equinox.p2.engine/engine/debug=true
org.eclipse.equinox.p2.engine/certificatechecker/unsigned=true
org.eclipse.equinox.p2.engine/certificatechecker/untrusted=true

HTH

Diakinesis

Outstanding. Only ten minutes ago I finally connected with my debugger and found the obscure jar file in my local .p2 repo that was corrupted. Before I "fix" that, I'll see if these flags would have given me more helpful info. – Wilow

At this point, I think I have all I need without adding these options. I was able to find the source for SignedBundleHook and CertificateChecker, and neither of them had any logging around the blocks in question. I imagine it's possible I would have seen a reference to the jar file name in a verbose logging statement much higher (lower) in the callstack before the error. – Wilow

Oh, and note that the corrupted jar was in my $HOME/.p2 repo. There were five "emf" jars that were not zero size, but were corrupted (jar tvf and unzip reported formatting errors). I'm now pursuing how to fix the files in my .p2 repo. – Wilow