Community
Participate
Working Groups
Created attachment 260236 [details] Example target file that fails Background: The CDT project is using some bundles from orbit recipes (org.freemarker_2.3.22 and org.antlr.runtime_4.5.1). For now we are using https://hudson.eclipse.org/orbit/job/orbit-recipes/lastSuccessfulBuild/artifact/releng/repository/target/repository/ as our repo (presumably until the "new" Orbit is ready that includes the recipes provided bundles). The problem below came out of trying to adopt Oomph instead of manual setup of CDT Dev environment, see https://dev.eclipse.org/mhonarc/lists/cdt-dev/msg30284.html for the discussions that lead to this point. The problem: org.bouncycastle.bcprov-jdk15on fails to download when they are included in the target platform from the location above. A simple target platform that only contains org.bouncycastle.bcprov-jdk15on such as the attached target file fails to complete. The progress simply hangs forever. No error log entries [1] or any apparent problem. Other bundles (such as the org.freemarker one) work just fine. I did a full mirror of the p2 repo [2] and used that mirror as the location. The problem was the same. This indicates that the EclipseConNA confrence WiFi was not the problem as initially suspected. I expect that in addition to an Orbit bug there is a p2 bug here too, i.e. p2 should not be hanging forever. [1] Not strictly true, if I quit Eclipse I can have this in the error log: !ENTRY org.eclipse.core.jobs 2 2 2016-03-10 21:29:50.333 !MESSAGE Job found still running after platform shutdown. Jobs should be canceled by the plugin that scheduled them during shutdown: org.eclipse.pde.internal.ui.editor.targetdefinition.TargetEditor$TargetChangedListener$1 [2] these are the command lines I used: /scratch/eclipse/eclipse-mars/eclipse -application org.eclipse.equinox.p2.artifact.repository.mirrorApplication -source https://hudson.eclipse.org/orbit/job/orbit-recipes/lastSuccessfulBuild/artifact/releng/repository/target/repository -destination file:/tmp/mirror /scratch/eclipse/eclipse-mars/eclipse -application org.eclipse.equinox.p2.metadata.repository.mirrorApplication -source https://hudson.eclipse.org/orbit/job/orbit-recipes/lastSuccessfulBuild/artifact/releng/repository/target/repository -destination file:/tmp/mirror
Some sort of signing problem maybe?
I doubt it is related to signing. I think that problem would be a different error message -- mostly guessing. (But, it does seem to be "signed twice", with SHA1 sums and SHA256 hashes in the MANIFEST.MF. I "replicated" the issue by downloading the zip of artifacts from Hudson, unzipped that to local file system, and then trying to use that local repository to "install new software". I was going to try to "install" the bundle in question, but as it read the local repo, it got to displaying "downloading org.bouncycastle.bcprov-jdk15on" and then seemed to just hang there.
The code appears to hang in org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor in the while loop of populateMDREsults(..) after it hits : if (!msgDigestAlgorithm.equalsIgnoreCase(signerInfo.getMessageDigestAlgorithm())) continue; // TODO log error? Basically, this goes through the Manifest file looking for the next 'Name:' entry from the current position, and finds any digests it may have. If it encounters an entry that does not have a digest algorithm matching the signature file then the loop can't make any further progress and will just hang. For the manifest in org.bouncycastle.bcprov-jdk15on_1.52.0.v20160229-0929.jar, there are some entries that only have a SHA1 digest whereas the signature file appears to be SHA256 : org/bouncycastle/jcajce/provider/symmetric/IDEA$AlgParamGen.clas org/bouncycastle/jcajce/provider/symmetric/IDEA$PBEWithSHAAndIDE org/bouncycastle/jcajce/provider/symmetric/IDEA$Mac.class org/bouncycastle/jcajce/provider/symmetric/IDEA$Mappings.class org/bouncycastle/jcajce/provider/symmetric/IDEA$CBC.class org/bouncycastle/jcajce/provider/symmetric/IDEA$AlgParams.class org/bouncycastle/jcajce/provider/symmetric/IDEA.class org/bouncycastle/jcajce/provider/symmetric/IDEA$PBEWithSHAAndIDE org/bouncycastle/crypto/engines/IDEAEngine.class org/bouncycastle/jcajce/provider/symmetric/IDEA$CFB8Mac.class org/bouncycastle/jcajce/provider/symmetric/IDEA$KeyGen.class org/bouncycastle/asn1/misc/IDEACBCPar.class org/bouncycastle/jcajce/provider/symmetric/IDEA$ECB.class org/bouncycastle/crypto/modes/OCBBlockCipher.class Looking at the orbit-recipes pom for the bundle ( http://git.eclipse.org/c/orbit/orbit-recipes.git/tree/bouncycastle/org.bouncycastle.bcprov-jdk15on_1.52.0/pom.xml#n16 ), these are all the classes that should be excluded (required by legal). If these classes shouldn't be making it into the jar at all, then this will probably all go away when that excludes gets corrected.
Adding Tom to CC, since org.eclipse.osgi.internal.signedcontent was mentioned. Tom, it appears Roland has done some good debugging here, and while a rare case, you may want to avoid the possibility of an "infinite loop". BTW, I can no longer reproduce the error -- using either https://hudson.eclipse.org/orbit/job/orbit-recipes/lastSuccessfulBuild/artifact/releng/repository/target/repository/ Or, my "local copy" of file:/Users/davidw/Downloads/orbitRepo/repository/ The only change was I did "fix up" my local dev environment to have all source loaded ... so ... *maybe* this has been fixed in master? Oh, and rereading comment 0, I think I removed some "Oomph" files in ~/.eclipse, so I wonder if this is somehow Oomph related? (And, if it is, may just be the version of Equinox they are using?)
(In reply to David Williams from comment #4) > BTW, I can no longer reproduce the error With Neon M5 I can still reproduce the error. 1. Remove ~/.eclipse 2. downloaded and unzipped eclipse-platform-4.6M5-linux-gtk-x86_64.tar.gz 3. added in PDE (and JDT) 4. Checked that no oomph 5. Used a new workspace 6. Used attached target file and a similar one that points to my local mirror In this setup it still hangs doing "Resolving Target Definition". The only difference is that in Mars it hangs at 10% and in Neon M5 at 26%.
(I realized on re-reading comment 5 I didn't make this clear enough) (In reply to David Williams from comment #4) > [...] so I wonder if this is somehow Oomph related? [...] I reproduced the problem (see Comment 5) with no Oomph anywhere in my setup. So I don't think this is Oomph related.
(In reply to Jonah Graham from comment #5) > (In reply to David Williams from comment #4) > > BTW, I can no longer reproduce the error > > With Neon M5 I can still reproduce the error. > 1. Remove ~/.eclipse > 2. downloaded and unzipped eclipse-platform-4.6M5-linux-gtk-x86_64.tar.gz > 3. added in PDE (and JDT) > 4. Checked that no oomph > 5. Used a new workspace > 6. Used attached target file and a similar one that points to my local mirror > > In this setup it still hangs doing "Resolving Target Definition". The only > difference is that in Mars it hangs at 10% and in Neon M5 at 26%. I guess you know the next logic "experiment" is to try to reproduce using http://download.eclipse.org/eclipse/downloads/drops4/I20160308-0800 There were a log of changes between M5 and I20160308-0800, but will admit that git diff I20160128-2000..I20160308-0800 | grep SignatureBlockProcessor shows no "hits". But, again, the "fundamental" problem is the incorrect jar in Orbit, and don't recall right off who is in charge of that jar .. and, too tired to look tonight :)
I tried with eclipse-platform-I20160308-0800-linux-gtk-x86_64.tar.gz and was still running into the same issue. I took a closer look at orbit-recipes and the jar from maven comes pre-signed (SHA1). Our build process removes the IDEA*, OCBBlockCipher* classes as mandated by legal but their digest entries remain in the manifest. Then when the jar signer runs, it signs everything with a SHA256 except those removed classes, which then triggers the SignatureBlockProcessor to hang on installation. Relevant commit : http://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=b7789492090bd849667ca3e79da8bb3e92242068 I guess the ebr-maven-plugin should have some way of ensuring an excluded class file is removed from the manifest.
(In reply to David Williams from comment #4) > Adding Tom to CC, since org.eclipse.osgi.internal.signedcontent was > mentioned. > > Tom, it appears Roland has done some good debugging here, and while a rare > case, you may want to avoid the possibility of an "infinite loop". Yeah, this looks like a bug in equinox. I wont be able to look at it for M6 this week. Should we reassign to Equinox->Framework for M7 or is there something you still need to do here for orbit. If so can we get a separate bug opened for Equinox?
(In reply to Thomas Watson from comment #9) > (In reply to David Williams from comment #4) > > Adding Tom to CC, since org.eclipse.osgi.internal.signedcontent was > > mentioned. > > > > Tom, it appears Roland has done some good debugging here, and while a rare > > case, you may want to avoid the possibility of an "infinite loop". > > Yeah, this looks like a bug in equinox. I wont be able to look at it for M6 > this week. Should we reassign to Equinox->Framework for M7 or is there > something you still need to do here for orbit. If so can we get a separate > bug opened for Equinox? Yes, the bundle in Orbit needs to be fixed, so open Equinox bug 489686 for improved handling of "incorrect bundles".
I've learned that only pack.gz files are available from that repository. And appears it is during the "create a jar" that the hang occurs. There really should be jars as well as pack.gz files available from that site. Anyone know how to "turn that on"?
Gunnar, adding you for an answer to comment 11. It's a "rule" that repositories should have jars as well as their pack.gz counterparts. Can you "turn that on"?
Looking in https://hudson.eclipse.org/orbit/job/orbit-recipes/lastSuccessfulBuild/artifact/releng/repository/target/repository/plugins/ I can clearly see both .jar and .jar.pack.gz artifacts so there would definitely appear to be both. Am I missing something ? I would think that the part causing the hang executes in both cases. So whether you download a jar, or a .jar.pack.gz, the jar must still have its contents verified, which is where the hang occurs.
Yes, we had some trouble with that bundle and signing. I wonder if it's still incorrect.
(In reply to Roland Grunberg from comment #13) > Looking in > https://hudson.eclipse.org/orbit/job/orbit-recipes/lastSuccessfulBuild/ > artifact/releng/repository/target/repository/plugins/ I can clearly see both > .jar and .jar.pack.gz artifacts so there would definitely appear to be both. > Am I missing something ? No, sorry, must have been a quirk in the way I was "getting" the whole repository. Sorry for the false alarm. Thanks for correcting me.
(In reply to Gunnar Wagenknecht from comment #14) > Yes, we had some trouble with that bundle and signing. I wonder if it's > still incorrect. They both (the jar and the pack200 jar) seem correct to me, using jarsigner -verify (and unpack200).
I'm assuming Mattias "owns" fixing the MANIFEST.MF to remove entries? I am a bit surprised that Java still "verifies" the jar as correct when some classes have been removed? Am I understanding this right?
(In reply to David Williams from comment #17) > I'm assuming Mattias "owns" fixing the MANIFEST.MF to remove entries? He contributed the recipe so I hope he is able to help here. > I am a bit surprised that Java still "verifies" the jar as correct when some > classes have been removed? Me too. I do remember that Matthias did some investigation to remove the legacy signature and replace it with the EF signature. Thus, I'm wondering where those are coming from.
My stripping of the JCE signature from the original bouncycastle libraries is obviously incomplete, the build removes the signature files META-INF/*.SF, META-INF/*.DSA, META-INF/*.RSA but does not remove the SHA-1 signatures per file from META-INF/MANIFEST.MF We have to remove these original signatures since we are obliged to remove some classes which legal told us we can't use due to legal issues. Removing any classes from the signed content of a bundle breaks the signature so we have remove them and resign. In a later build step the Eclipse signing process adds the SHA-256 signatures when signing the bundles with the Eclipse certificate. In the end these libraries need to be signed with an Oracle JCE certificate we asked the Eclipse foundation to request from Oracle in bug 467064. Signing the libraries with this certificate requires the signing service to be enhanced (bug 478088) in order to enable signing with the JCE certificate.
Thanks Matthias! So it sounds like we should also exclude the original MANIFEST.MF and completely rely on building our own then?
New Gerrit change created: https://git.eclipse.org/r/68534
Gerrit change https://git.eclipse.org/r/68534 was merged to [master]. Commit: http://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=0b8552a9597cba6825b90795c63c26566e008c14
it seems the Eclipse signing service doesn't honor <resigningStrategy>OVERWRITE</resigningStrategy> which the eclipse-jarsigner-plugin claims to support https://www.eclipse.org/cbi/maven-plugins/documentation/1.1.3/eclipse-jarsigner-plugin/sign-mojo.html#resigningStrategy
(In reply to Matthias Sohn from comment #23) > it seems the Eclipse signing service doesn't honor > <resigningStrategy>OVERWRITE</resigningStrategy> > which the eclipse-jarsigner-plugin claims to support > https://www.eclipse.org/cbi/maven-plugins/documentation/1.1.3/eclipse- > jarsigner-plugin/sign-mojo.html#resigningStrategy See https://dev.eclipse.org/mhonarc/lists/cbi-dev/msg01664.html
Is this problem resolved with org.bouncycastle.bcprov 1.59.0 available here? http://download.eclipse.org/tools/orbit/downloads/drops/R20180606145124/
(In reply to Max Hohenegger from comment #25) > Is this problem resolved with org.bouncycastle.bcprov 1.59.0 available here? > http://download.eclipse.org/tools/orbit/downloads/drops/R20180606145124/ I haven't confirmed anything but this should have been fixed in Neon M7, with http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=1b7bd98d0c6b8334fa838e7d1c875b24c58c1384 . If using an older version, I think newer versions of the bouncycastle should also prevent the error from occuring but I'm not sure on this. If you're still running into this issue though, perhaps stating the version of Eclipse and repository for bouncycastle used to generate the target may help.
Created attachment 275355 [details] dialog opened during installation of bouncycastle provider from photon orbit
(In reply to Roland Grunberg from comment #26) > If you're still running into this issue though, perhaps stating the version > of Eclipse and repository for bouncycastle used to generate the target may > help. p2 does not hang anymore with the Photon Orbit, but I get the attached dialog to confirm. In an RCP app update that is not something users will accept. Is that a known side effect of the fix or an unrelated problem?
*will not accept
It looks like the running JRE does not trust the JCE code signing certificate (bug 467064). Can you report details of the JRE/JDK?
I just reproduced it with a jdk1.8.0_131: - Start Photon - Help->Install New Software... - Enter http://download.eclipse.org/tools/orbit/downloads/drops/R20180606145124/repository/ into "Work with:" - Select Bouncycastle provider (any version) - Next - Finish => Dialog appears I noticed that the META-INF folder contains two pairs of *.SF/*.RSA files. This is just a wild guess, but shouldn't it be three - one for each certificate in the chain?
Created attachment 275374 [details] dialog opened during installation of original bouncycastle provider from alternative p2 repo Please note that the same issue exists with the original Bouncycastle provider 1.52.0. Only the certificates are different.
I was also able to reproduce this with a JDK 10.0.2 on a different machine. For all I know, the trust store is still the original. Should I raise a new ticket for this or should Bug 467064 be reopened?
Can you open a new bug? This is something we need to investigate.
That dialog from comment #32 is now triggered during IDE updates due to EGit's use of the Bouncycastle provider. I've opened Equinox bug 544874.
