Community
Participate
Working Groups
Or, I could have titled this "what is wrong with org.pushingpixels.trident_1.2.0.xxxxxxxxx" This first came to my attention, because I ran the b3 aggregator (from home network, not build.eclipse.org) with mirrors enabled, and, some p2 options "turned on", so I could see what was coming from mirrors, and how often, etc. [This "how to" is described in https://wiki.eclipse.org/Equinox/p2/p2.mirrorsURL] The actually "aggregation job" failed, because, it said "could not mirror all artifacts". Looking for that, it was org.pushingpixels.trident,1.2.0.v20110609-1700 from repository http://download.eclipse.org/xwt/release-1.1.0 So, ok, XWT's fault, right? Well, maybe, at least partially, but the reason was MD5 hash is not as expected. Expected: 4420d4b4baa516151255059a13ae3805 and found 882d814bd30e0078389b1e654ad15058 Hmm, interesting ... I assumed this was a case where "the same version/qualifier" of an artifact had "different content". So, started looking for that, on our own "download.eclipse.org" servers. The results were not pleasing, at all. First, naturally, looked in Orbit: $ find . -name "org.pushingpixels.trident_1.2.0*.jar" -exec md5sum '{}' \; | sort 6737387e90dc3fb44ddcb0f25f094ff7 ./drops/I20150127213331/repository/plugins/org.pushingpixels.trident_1.2.0.v201305152020.jar 6737387e90dc3fb44ddcb0f25f094ff7 ./drops/I20150202203538/repository/plugins/org.pushingpixels.trident_1.2.0.v201305152020.jar 6737387e90dc3fb44ddcb0f25f094ff7 ./drops/R20130517111416/repository/plugins/org.pushingpixels.trident_1.2.0.v201305152020.jar 6737387e90dc3fb44ddcb0f25f094ff7 ./drops/R20130827064939/repository/plugins/org.pushingpixels.trident_1.2.0.v201305152020.jar 6737387e90dc3fb44ddcb0f25f094ff7 ./drops/R20140114142710/repository/plugins/org.pushingpixels.trident_1.2.0.v201305152020.jar 6737387e90dc3fb44ddcb0f25f094ff7 ./drops/R20140525021250/repository/plugins/org.pushingpixels.trident_1.2.0.v201305152020.jar 6737387e90dc3fb44ddcb0f25f094ff7 ./drops/R20150124073747/repository/plugins/org.pushingpixels.trident_1.2.0.v201305152020.jar 6737387e90dc3fb44ddcb0f25f094ff7 ./drops/S20140917154621/repository/plugins/org.pushingpixels.trident_1.2.0.v201305152020.jar 6737387e90dc3fb44ddcb0f25f094ff7 ./drops/S20141023165154/repository/plugins/org.pushingpixels.trident_1.2.0.v201305152020.jar 6737387e90dc3fb44ddcb0f25f094ff7 ./drops/S20141129202728/repository/plugins/org.pushingpixels.trident_1.2.0.v201305152020.jar 6737387e90dc3fb44ddcb0f25f094ff7 ./drops/S20150202203538/repository/plugins/org.pushingpixels.trident_1.2.0.v201305152020.jar Well, all consistent there (but, note, the qualifier is from 2013, whereas original "error case" had a qualifier from 2011. So ... I looked further. Luna: $ find . -name "org.pushingpixels.trident_1.2.0*.jar" -exec md5sum '{}' \; | sort 120f1894cea2253add9e85425cca8f2d ./201406250900/plugins/org.pushingpixels.trident_1.2.0.v20110609-1700.jar 55a302e38f44b3094b0d6224cc6cbbf8 ./201406250900/plugins/org.pushingpixels.trident_1.2.0.v201305152020.jar 55a302e38f44b3094b0d6224cc6cbbf8 ./201409261001/plugins/org.pushingpixels.trident_1.2.0.v201305152020.jar 55a302e38f44b3094b0d6224cc6cbbf8 ./201501121000/plugins/org.pushingpixels.trident_1.2.0.v201305152020.jar 55a302e38f44b3094b0d6224cc6cbbf8 ./201502271000/plugins/org.pushingpixels.trident_1.2.0.v201305152020.jar 882d814bd30e0078389b1e654ad15058 ./201409261001/plugins/org.pushingpixels.trident_1.2.0.v20110609-1700.jar 882d814bd30e0078389b1e654ad15058 ./201501121000/plugins/org.pushingpixels.trident_1.2.0.v20110609-1700.jar 882d814bd30e0078389b1e654ad15058 ./201502271000/plugins/org.pushingpixels.trident_1.2.0.v20110609-1700.jar Not consistent, doesn't match "Orbit". At least some match the "found" value in error message. Mars (so far): $ find . -name "org.pushingpixels.trident_1.2.0*.jar" -exec md5sum '{}' \; | sort 3c9c7383c6d2b781977474a2402bcf5e ./201412191000/plugins/org.pushingpixels.trident_1.2.0.v201305152020.jar 3c9c7383c6d2b781977474a2402bcf5e ./201502061000/plugins/org.pushingpixels.trident_1.2.0.v201305152020.jar 4420d4b4baa516151255059a13ae3805 ./201412191000/plugins/org.pushingpixels.trident_1.2.0.v20110609-1700.jar 4420d4b4baa516151255059a13ae3805 ./201502061000/plugins/org.pushingpixels.trident_1.2.0.v20110609-1700.jar 55a302e38f44b3094b0d6224cc6cbbf8 ./201408221000/plugins/org.pushingpixels.trident_1.2.0.v201305152020.jar 55a302e38f44b3094b0d6224cc6cbbf8 ./201410031000/plugins/org.pushingpixels.trident_1.2.0.v201305152020.jar 882d814bd30e0078389b1e654ad15058 ./201408221000/plugins/org.pushingpixels.trident_1.2.0.v20110609-1700.jar 882d814bd30e0078389b1e654ad15058 ./201410031000/plugins/org.pushingpixels.trident_1.2.0.v20110609-1700.jar 882d814bd30e0078389b1e654ad15058 ./201411141000/plugins/org.pushingpixels.trident_1.2.0.v20110609-1700.jar 928b774782a9fcf4ddfde7acc0f6ae86 ./201411141000/plugins/org.pushingpixels.trident_1.2.0.v201305152020.jar Not consistent, doesn't match "Orbit". At least some match the "found" value in error message AND some match "expected" value in error message. These are the two groups of v20110609-1700, in list. So, this is ?probably? a case where "same version/qualifier" does not have "same content". And, finally "staging": $ find . -name "org.pushingpixels.trident_1.2.0*.jar" -exec md5sum '{}' \; | sort 3c9c7383c6d2b781977474a2402bcf5e ./plugins/org.pushingpixels.trident_1.2.0.v201305152020.jar 4420d4b4baa516151255059a13ae3805 ./plugins/org.pushingpixels.trident_1.2.0.v20110609-1700.jar Not consistent, doesn't match "Orbit". At least one matches "expected" value in error message. Now, as far as I know, the only difference is something trivial, such as exact date signed, or something? But raises a number of questions: Why isn't the Orbit version being used? Why does the Orbit version (that is, version 1.2.0.v201305152020) vary so widely in other repos? (If I had to guess, I'd guess people are "re-signing" it? I'm not sure how to combat this problem? Do we "fail the build" if the md5sum differs from what is "already in another "released" repo"? Not to mention, how do we correct the "problem that exists in the wild"? Off hand, Moving forward, I'd suggest everyone specify a "required" version that includes the qualifier. and, at least start with the 2013 version, make sure you don't re-sign it, and that would at least help "in the future". But, not sure we can fix "what exists". (Unless someone comes up with a Nobel Prize winning idea? :)
I think this is "off topic" and just a matter of how logging works, but one reason this really stood out, is that in the log, there were 203 "requests" for that pushing pixels bundle, and I think so many because (I'm guessing) there were a number of threads trying to get it at once (or, each getting parts of it?). There were 7 mirrors playing part in the requests, number of "requests" to each are tabulated below: 77 http://mirrors.xmission.com 54 http://mirror.cc.columbia.edu 35 http://mirrors.ibiblio.org 12 http://ftp.osuosl.org 11 http://www.gtlib.gatech.edu 6 http://mirror.cc.vt.edu 6 ftp://mirror.cc.columbia.edu
org.pushingpixels is maintained by myself in Orbit and its also part of Riena and its p2 repo. So our PDEBuild packs all the Riena components and includes org.pushingpixels.trident_1.2.0.v201305152020.jar (and the source jar). I upload that to build.eclipse.org and let it sign the whole repo. That probably sign the already signed pushingpixels jar again. I could manually exclude pushingpixels from this signing step but I wonder if there a simple flag for the sign job to say "dont sign if already signed" ? We also have some apache.commons jars in our p2 repo and they never seemed a problem. Or is it at the end not a problem to sign a bundle a second time (and that way having multiple MD5 hashes) ? I agree that including pushingpixels 2013 AND 2011 is wrong. But I am sure we deliver the 2013 version.
(In reply to Christian Campo from comment #2) > Or is it at the end not a problem to sign a bundle a second time (and that > way having multiple MD5 hashes) ? I used to think "not a problem" (since technically, they are still "validly signed jars" as far as Java is concerned) but ... I think having multiple MD5 hashes may be. I'll have to think that through a little more ... but not sure how else to explain the problem I was seeing ... but if it is a problem, I think it is related to composite repositories, having having the same version/qualifier in multiple composites, but (slightly) different contents for the hash sum is different. I will say, though, that I let my test run 6 or so more times over several days, and never did see again. So, maybe it was something odd about that one bundle or some "subset" of mirrors? But, I would avoid re-signing things, if already signed. Not sure if that's realistic, just take it as a suggestion, for now.
I've been at this so long, I have forgotten what I have forgotten. But, recently happened across the "validate" option on making a composite, that appears to be designed for just this case. See https://wiki.eclipse.org/Equinox/p2/Ant_Tasks#Validate Validate To ensure that the composite repository has consistent contents an artifact comparator can be used <p2.composite.repository validate="org.eclipse.equinox.artifact.md5.comparator"> <repository location="file:/myDestination" name="A new repository" append="false" /> <add> <repository location="http://aSource/" kind="M" /> <repository location="http://aSource2/" kind="A" /> </add> </p2.composite.repository> Note the md5 comparator. So, what's happened in this pushing-pixels case is that each child repo has "a correct version" but the ones in other child repos have a different md5 checksum. Most likely (in some cases) at least due to the fact that some people "re-sign" bundles they get from Orbit (so, the md5 checksum is different, and in the end, p2 might "get" the one is expecting, or it might "get" one from a different child, that has an unexpected checksum. I currently do no know how wide spread this problem is ... but, guess who will be finding out soon? :) I'm assuming in most existing cases, the remedy is -- using p2 APIs -- remove the older one, and replace it with the newer one. Ideally though, we'd detect these before release, and in some cases might be that the "newer one" is being produced incorrectly. Changing an existing repo does violate the "repositories are immutable" principle, but, a) not sure how to solve, b) ideally we'll learn to detect before release, and take more appropriate action.
We are used to include some of Orbit bundles into our p2 repository. With the new signing it seems to be impossible to use this orbit jars: INFO: [start org.eclipse.xpand.build:eclipse.feature$2.1.0.qualifier#site.signed] [ant] Queueing site_1736231164.zip for signing [ant] WARNING: /shared/download-staging.priv/modeling/m2t/xpand/signing/out20150413125837 is not a valid directory. Creating. [ant] File /shared/download-staging.priv/modeling/m2t/xpand/signing/site_1736231164.zip added to queue. [ant] You will receive notification when the file is signed, if you used the mail parameter. [ant] [ant] You can check signing status by tailing /home/data/httpd/download-staging.priv/arch/signer.log [ant] Waiting for signing to complete. This may take more then 60 minutes [ant] Obtaining signed file from staging area INFO: [end org.eclipse.xpand.build:eclipse.feature$2.1.0.qualifier#site.signed] INFO: [start org.eclipse.xpand.build:eclipse.feature$2.1.0.qualifier#site.packed] java.lang.SecurityException: invalid SHA1 signature file digest for org/antlr/runtime/tree/TreeRewriter$3.class Caused by: Terminating xvnc. Is there a solution for buckminster based builds?
(In reply to Dennis Huebner from comment #5) > We are used to include some of Orbit bundles into our p2 repository. > With the new signing it seems to be impossible to use this orbit jars: > > INFO: [start > org.eclipse.xpand.build:eclipse.feature$2.1.0.qualifier#site.signed] > [ant] Queueing site_1736231164.zip for signing > [ant] WARNING: > /shared/download-staging.priv/modeling/m2t/xpand/signing/out20150413125837 > is not a valid directory. Creating. > [ant] File > /shared/download-staging.priv/modeling/m2t/xpand/signing/site_1736231164.zip > added to queue. > [ant] You will receive notification when the file is signed, if you used the > mail parameter. > [ant] > [ant] You can check signing status by tailing > /home/data/httpd/download-staging.priv/arch/signer.log > [ant] Waiting for signing to complete. This may take more then 60 minutes > [ant] Obtaining signed file from staging area > INFO: [end > org.eclipse.xpand.build:eclipse.feature$2.1.0.qualifier#site.signed] > INFO: [start > org.eclipse.xpand.build:eclipse.feature$2.1.0.qualifier#site.packed] > java.lang.SecurityException: invalid SHA1 signature file digest for > org/antlr/runtime/tree/TreeRewriter$3.class > Caused by: T. erminating xvnc. . > > Is there a solution for buckminster based builds? Not sure this problem is related to this bug. You should probably open one in Buckminster, or Orbit. Maybe Orbit -- but you'd have to be very specific on where you get the bundle from, since I've tested several of the repos there, and they do not have a problem. Are you getting Orbit bundles from XText? I know that someone once set up their own source of Orbit bundles, so they could use composites. Do you use that? If so, perhaps they didn't do it correctly, and you will need to use a direct URL from Orbit? Plus, it would not be correct to reprocess the Orbit bundles. Not sure if that's what you are doing?
> You should probably open one in Buckminster, or Orbit. I'm not sure they will feel responsible for that. Something that worked for years is suddenly broken. > Plus, it would not be correct to reprocess the Orbit bundles. Not sure if that's what > you are doing? What we do, is just include some of orbit bundles into our p2 repository. This repository is send to the signing service on build.eclipse.org and it worked very well earlier. In your mail to cross project you wrote, that buckminster and tycho builds are not affected by switching to a new signing process. Should probably mean, that the problem is on our side? If so, please give me a hint how to fix this. I've already disabled pack200 for the whole build, which also didn't work since today, now we have this signing problems, where I can't workaround.
(In reply to Dennis Huebner from comment #7) > What we do, is just include some of orbit bundles into our p2 repository. > This repository is send to the signing service on build.eclipse.org and it > worked very well earlier. > In your mail to cross project you wrote, that buckminster and tycho builds > are not affected by switching to a new signing process. Should probably > mean, that the problem is on our side? If so, please give me a hint how to > fix this. > > I've already disabled pack200 for the whole build, which also didn't work > since today, now we have this signing problems, where I can't workaround. When you send to the signing service, do you specify -nopack? (You should, Buckminster has already done that for you, all you need is it signed .. but, if not, you could try that first). But, the better solution, if you area already doing that or not, is simply leave out the orbit bundles when you send a zip file to signing service, and merge them back in when you get your signed bundles back. Either way, I believe, you must call "process artifacts" one last time (with pack="false") to correct the md5 checksums). Make sense?
(In reply to David Williams from comment #8) Joining in as requested by Bug 463510#c37 OCL has exactly the same problem. The bundling of LPG from Orbit now fails with a SHA signature. You suggest changing the commands to Buckminster to omit Orbit bundles. I have no idea how to do that. I'm afraid OCL will have to stay unsigned until the signing service acquires Luna compatibility. Revert to 6 or provide a -version 6.
(In reply to Ed Willink from comment #9) > (In reply to David Williams from comment #8) > Joining in as requested by Bug 463510#c37 > > OCL has exactly the same problem. The bundling of LPG from Orbit now fails > with a SHA signature. > > You suggest changing the commands to Buckminster to omit Orbit bundles. > > I have no idea how to do that. > > I'm afraid OCL will have to stay unsigned until the signing service acquires > Luna compatibility. Revert to 6 or provide a -version 6. Maybe you could ask on Buckminster user's list and someone else knows how to do it? (Seriously, even if there was a "version 6" option, you should not be resigning or even re-packing Orbit bundles ... you need to use them "as is").
(In reply to David Williams from comment #10) > > Maybe you could ask on Buckminster user's list and someone else knows how to > do it? > > (Seriously, even if there was a "version 6" option, you should not be > resigning or even re-packing Orbit bundles ... you need to use them "as is"). If you have ability to add anything to your zip file, what I've done on other projects is to add a line to a file named "pack.properties" (that goes "at the top" of your zip file directories), with a line such as pack.excludes=@excludejars@ and then, before adding it, "replace" the @excludejars@ with a comma separated list of jars that the jar processor should not process. The only hard part is getting the "jar name" to appear exactly like it does in the zip file .. for example, does if have a leading slash or not. Just trying to be helpful, and ran across this, that reminded me it might be useful to you. Documented in https://wiki.eclipse.org/JarProcessor_Options
(In reply to David Williams from comment #11) > If you have ability to add anything to your zip file It all seems to be full automated by Buckminster. The only options I see are site.signing, site.pack200. I cannot even find the ZIP file. I certainly do not create/use it. It just worked. Question asked on Buckminster group, but my last question remains unanswered 6 months later.
(In reply to David Williams from comment #0) > MD5 hash is not as expected. Expected: 4420d4b4baa516151255059a13ae3805 > and found 882d814bd30e0078389b1e654ad15058 Bug 464594 (MD5 hash is not as expected for org.antlr.runtime,3.2.0.v201101311130) may a duplicate.
I do not think 'validate' works. At least doesn't do anything I can see. I made a "local copy" of the 4 luna repositories, since that's where I saw the "pushing pixels' problem. That is, a copy of the 4 child repos: 201502271000 201406250900 201409261001 201501121000 I think called "addToComposite", one at a time, with an ant script similar to: <p2.composite.repository validate="org.eclipse.equinox.artifact.md5.comparator"> <repository location="file://${repodir}" name="The Eclipse Project repository" /> <add> <repository location="${complocation}" /> </add> </p2.composite.repository> I was expecting to get "warnings" or "errors" listed to console, but there were none. But, there obvious cases of artifacts with same version/qualifier, but different checksums. I wrote another script to go though each of the 4 child repos, list the jar file name, its md5sum, and the child directory name. Below are some of the obvious cases I spotted by simply browsing a sorted listing of the file. org.pushingpixels.trident_1.2.0.v20110609-1700.jar 120f1894cea2253add9e85425cca8f2d 201406250900 org.pushingpixels.trident_1.2.0.v20110609-1700.jar 882d814bd30e0078389b1e654ad15058 201409261001 org.uddi4j_2.0.5.v200805270300.jar 6e70f0c0ddd7b69f4eff6b55c77dce5a 201406250900 org.uddi4j_2.0.5.v200805270300.jar b2ca672ad1d695e8182d251bb9263e16 201409261001 org.uddi4j_2.0.5.v200805270300.jar b2ca672ad1d695e8182d251bb9263e16 201501121000 org.uddi4j_2.0.5.v200805270300.jar b2ca672ad1d695e8182d251bb9263e16 201502271000 org.json_1.0.0.v201011060100.jar 6e46d9eea94b9f5fcb0b3b98c21a78a2 201502271000 org.json_1.0.0.v201011060100.jar d19d03d0a5b96d6654a5e08fc08d53c3 201406250900 org.json_1.0.0.v201011060100.jar dec8c6b2c596a728fcdf744eebe8069f 201409261001 org.json_1.0.0.v201011060100.jar dec8c6b2c596a728fcdf744eebe8069f 201501121000 Guess I'll open a p2 bug. (And change title)
(In reply to David Williams from comment #14) > Guess I'll open a p2 bug. bug 466077
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This issue has been migrated to https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/191.
