Bugzilla – Full Text Bug Listing
| Summary: | We should use Java 8 in the infrastructure signing service. (Is currently Java 6). | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Community | Reporter: | David Williams <david_williams> | ||||
| Component: | Cross-Project | Assignee: | Eclipse Webmaster <webmaster> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | critical | ||||||
| Priority: | P3 | CC: | adolfosbh, arunkumar.thondapu, denis.roy, dennis.huebner, ed, konstantin, mikael.barbero, mknauer, pascal, stephan.herrmann, stepper, thomas, webmaster, wim.jongman | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 464449 | ||||||
| Bug Blocks: | 463010, 463616, 464100, 464433, 465068 | ||||||
| Attachments: |
|
||||||
|
Description
David Williams
(In reply to David Williams from comment #0) > As most of you know, we currently try to pack200 all our jars, in all p2 > repositories, because when the jar contains Java code (.class files) the > savings (in bandwidth) can be significant (30% to 60% savings, according to > bug 142294). If p2 could speak "http" more natively, it could support on-the-fly compression without our need to maintain both packed and unpacked jars or condition anything. Simplicity is King. See: bug 381598 and its dependencies. http://en.wikipedia.org/wiki/HTTP_compression (In reply to Denis Roy from comment #1) > > If p2 could speak "http" more natively, it could support on-the-fly > compression without our need to maintain both packed and unpacked jars or > condition anything. Simplicity is King. > > See: bug 381598 and its dependencies. > > http://en.wikipedia.org/wiki/HTTP_compression I asked about that once, and recall being told that, at the time, there was concern that it would require "all mirrors" to be configured correctly, and it was thought, at the time, that would be unlikely. Not sure if that's still true, or if it has now become commonplace. Now, back to this bug, :) I'm fairly sure that most who use PDE builds us the "central service" to do the "pre-conditioning" and signing. Those builds, at some later time, do the "pack". This is feasible since a) PDE build "packs" more than it should (packs things that do not even contain Java) and because it relies on 'jarprocessor' with is aware of the "eclipse.inf" file, which contains things like "Effort level" parameter (and potentially others). Given that, I think those that to those that do PDE builds, it would be recommended to also use Java 7 to do the "pack". (Technically, any VM could still be used for the actual build, and Java 7 pack200 still be used ... but, simpler to use same VM for everything, for most people. I'll try to prompt buckminster and Tycho to weigh in -- I think they may do their own "pre-conditioning" (and pack) and use the central service only for the jar signing (specifying -nopack to the sign command) so the VM level would matter less to them. We'll see. Assigning to myself, just to avoid such wide notification. Please add yourself to CC if you care to follow this bug. David you are capturing the current situation pretty well. I don't really have a clear cut recommendation on the version of Java to use to pack / unpack but I would recommend that we seek to get the version of Java used the most by our user base. For example, JBoss used to collect stats on which VMs their users were running Eclipse on, so it may be a good indicator as to which version to move to. Now, on the specific problem of Orbit, I think it may worth checking what happens when the Java 5 packed jars are unpacked with Java 7 or 8. (In reply to Denis Roy from comment #1) > (In reply to David Williams from comment #0) > > As most of you know, we currently try to pack200 all our jars, in all p2 > > repositories, because when the jar contains Java code (.class files) the > > savings (in bandwidth) can be significant (30% to 60% savings, according to > > bug 142294). > > If p2 could speak "http" more natively, it could support on-the-fly > compression without our need to maintain both packed and unpacked jars or > condition anything. Simplicity is King. > > See: bug 381598 and its dependencies. > > http://en.wikipedia.org/wiki/HTTP_compression AFAICT p2 requests everything using the appropriate gzip headers. You should be able to see this especially on requests for content.xml. Maybe something wrong happened and it is no longer the case. Could you confirm? Is there anything better that can be done when it comes to compression? Also note that pack200 can save more than 50% on the original size, now if you think that http can do better or we have the bandwidth to afford a compression drop from 50% down to 25%, then I'm sure David and all other interested parties will be happy to completely turn off pack200 since it will be much simpler. Wdyt? (In reply to Denis Roy from comment #1) > If p2 could speak "http" more natively, it could support on-the-fly > compression without our need to maintain both packed and unpacked jars or > condition anything. Simplicity is King. > > See: bug 381598 and its dependencies. > > http://en.wikipedia.org/wiki/HTTP_compression Denis, the jar file is compressed in it's own right (it's a zip). The pack200 adds Java bytecode specific compression by analyzing the class files and applying compressions based on knowledge on the class file structure that would be impossible for a generic compression algorithm. It's time consuming and highly domain specific. Are you saying that such compression is available as on-the-fly compression? (In reply to Thomas Hallgren from comment #7) > (In reply to Denis Roy from comment #1) > Denis, the jar file is compressed in it's own right (it's a zip). The > pack200 adds Java bytecode specific compression by analyzing the class files > and applying compressions based on knowledge on the class file structure > that would be impossible for a generic compression algorithm. It's time > consuming and highly domain specific. Are you saying that such compression > is available as on-the-fly compression? The issue of compression is off topic of this bug, so hope this is the last comment about it :) Please open a few bug, if anyone things there is merit to pursuing it. I will give a "reference" to the issue, which is pretty old, but as far as I know, it the most current, and as far as I know, still applies. http://docs.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-guide/pack200.html And will highlight two sentences: "Compressing files on the fly will degrade server performance, especially with Pack200, and therefore not recommended." "It is required that all JAR files, packed and unpacked, be tested for correctness ..." I think our current system, of "packing first" instead of "on the fly", thus saves "processing time" on servers, PLUS, most important, allows this "testing" to occur in the "aggregation process" because we deliberately "copy the pack.gz file, and then try to unpack it" and it is there, that projects are seeing frustrating errors. If we did it "dynamically" we would not see those errors until we actually tried to "test everything" by "installing everything" -- and, I think we all know, we would not really do an adequate job of that. = = = = = = Plus, keep in mind, it is my view that what "pack200" does is to make small, usually insignificant changes to the "bytes codes" simple so that compression algorithms such as gzip can do a "better job" of compressing them. (Such as re-arranges some things so it is still a valid class file, but has "longer runs" of "spaces" and other data that is duplicated in each class. No more, no less (well, it could do more, but we don't use those options since they do "lose" more information). = = = = = = Plus, keep in mind, p2 currently has "fall back" ability ... if the pack.gz file is not available, or, fails for some reason, it will try again for the "jar" itself. I suppose p2 could be re-written to "fall back" in it's use of "request headers" but, it's more than p2 simply asking for "compressed" version of things. (as far as I know). = = = = = = = Re Pascal's comment 6 "...p2 requests everything using the appropriate gzip headers..." I hope that is not the case ... or, depends on what "appropriate" means ... since "compressing pack.gz files" or even "compressing already compressed jar files" is probably a waste of time. = = = = = = Thanks, > pack200 adds Java bytecode specific compression by analyzing the class files
> and applying compressions based on knowledge on the class file structure
> that would be impossible for a generic compression algorithm.
Gotcha. I was speaking out of ignorance of what pack200 actually does. Ignoring me is the best course of action here.
I did get a response to my queries on buckminster-dev and tycho-dev. For Tycho-dev: https://dev.eclipse.org/mhonarc/lists/tycho-dev/msg01259.html <quote> >If I recall, Tycho does it's own "repack" and "pack" (I assume using the "system" VM) and if so, would probably not matter to you. >But, thought I'd ask for confirmation. Tycho uses pack200 of the VM which is running the build. IIRC Java 7 is recommended due to pack200 bugs (memory leaks) in JDK 6. </quote> This means that "it doesn't really matter" to Tycho builds (since they don't use pack or jarprocessor in central service), and, from Jan's extra info, sounds like Java 7 is better anyway! For Buckminster, their "archive list" isn't currently be updated (bug 463607) but I'll quote response here, from Thomas Hallgren: <quote> It's correct that Buckminster does it's own pack and repack instead of using an external executable but we still execute the same underlying code. I.e. running Buckminster with Java 6 or Java 7 will make a difference. Buckminster's pack logic isn't mandatory though. It must be enabled by passing the property site.pack200=true to the build. Buckminster will recognize the eclipse.inf and the jarprocessor.exclude.pack directive. See the following link for a full list of options that the jarprocessor will recognize: http://git.eclipse.org/c/buckminster/buckminster.git/tree/org.eclipse.buckminster.jarprocessor/src/org/eclipse/buckminster/jarprocessor/JarInfo.java </quote> So, sounds to me like the "central service" version won't really matter to those that use Buckminster. Though, I'd recommend those that do use Buckminster move their builds to "Java 7". So, I think we've done better than "end of week". From what I've heard, it seems clear that the "central service" should be updated to use Java 7. This will primarily effect those that do traditional PDE builds. Denis, since you'll be in that code anyway, making changes, you *might* want to make it a variable that users could pass in "absolute path of Java to use" or ... perhaps "Java number to use" (such as 5, 6, 7, 8) and you would always use "/shared/common/" "latest" (that's kind of complicated, since the link to Java 8 was made to contain the architecture, for some reason) /shared/common/jdk1.7.0-latest /shared/common/jdk1.8.0_x64-latest BUT, my point is, we are recommending Java 7 now, but "before you know it" it will likely be time to "move to Java 8" and if you had it as an (optional) parameter to the script, you'd have to make no more changes -- at least for a while. But, will leave that up to you. My purpose in this bug is just to "get up to" Java 7. Changing title to avoid question, it's now affirmative. Webmasters, may I ask that this be done soon? (And, if not soon, can you say when it can be scheduled?) Thanks, I've updated the signing script and a few other support scripts to use Java 8, and a really quick test seems to produce a signed jar file that verfies when I use 'jarsigner -verify'. Can I get some extra confirmation I haven't broken things? -M. (In reply to Eclipse Webmaster from comment #14) > I've updated the signing script and a few other support scripts to use Java > 8, and a really quick test seems to produce a signed jar file that verfies > when I use 'jarsigner -verify'. > > Can I get some extra confirmation I haven't broken things? > > -M. I'll give this a test soon ... but, to clarify, you did move to Java 8? Or was that a typo? The request was for Java 7 ... but, I know of no reason not to use Java 8 at the moment, I was just thinking of taking it one level at a time. But, if you really did change to 8, ok by me. It is worth trying. Another topic: any change you have a record of when it changed from Java 5 to Java 6? I'm thinking of Orbit bundles, some of which were created 5 years ago (or, more?) when Java 5 would have been in use ... and ... in hindsight, we should keep track of which Java is being used when. (and/or make somehow make exact Java version part of the user accessible log ... such as in the return "mail" they get, if it's requested. But, what ever you have there, am getting ready to test. Thanks. We're still struggling to get the M6 build correct using Java 7. Surely it is much too soon to throw the extra confusion of Java 8 into the mix? (In reply to Ed Willink from comment #16) > We're still struggling to get the M6 build correct using Java 7. > > Surely it is much too soon to throw the extra confusion of Java 8 into the > mix? I don't think this should effect Buckminster builds, Ed. Nor Tycho builds. This effects only those that use the "jarprocessor" (from Eclipse) do to the the "repack". Both Buckminster and Tycho do not use this part of the infrastructure, except to literally do the "signing", and I'd doubt that'd break anyone. The key is that what ever build you do, or use, that the same VM be used for the "repack" part, as the "pack" part. (Well, that, and that no one should "resign" something that is already signed). So, I believe you can continue to use Buckminster with Java 7. Probably, but mixing and matching Java versions can only increase the risks. We still have no explanation as to why Java 7 packing of Java 5 sometimes fails. The various certificate and platform Java changes have cost me over a man-week. I would really appreciate not having additional gratuitous hazards to contend with as well. (In reply to David Williams from comment #15) > But, if you really did change to 8, ok by me. It is worth trying. I did pick Java 8 because as you pointed out in comment #12 we'd soon get a request for that update(unless we made it a parameter), so I chose to go for the latest version. (In reply to Ed Willink from comment #16) > Surely it is much too soon to throw the extra confusion of Java 8 into the > mix? If my change to Java 8 is breaking things I'm more than happy to shift it to Java7 or even back to the original Java 6. -M. (In reply to Ed Willink from comment #18) > Probably, but mixing and matching Java versions can only increase the risks. > > We still have no explanation as to why Java 7 packing of Java 5 sometimes > fails. > > The various certificate and platform Java changes have cost me over a > man-week. > > I would really appreciate not having additional gratuitous hazards to > contend with as well. Thanks for you comments, and the concern. But, it is not a gratuitous change. We have to "keep up" with Java versions that are in wide-spread use, and that are "in service" and Java 7 doesn't have that much time left, so if we didn't do it now, it' would be during SR1, and would be a harder time to change, IMHO. We can continue to discuss your specific issues in bug 463131 but unless you actually find a problem that this change causes you, I'd prefer to move ahead rather than avoid moving out of fear. Once I finish my testing, I'll announce on cross-project and see if anyone else knows of (or finds) concrete problems with this change. Thanks again, Matt, have time to experiment? My results with using Java 8, there were 28 out of 1641 samples (1.7%), that were "contaminated". That was a little higher than I was hoping for. One the one hand, I could just say to "not pack" those 28 bundles, but, I am curious if using Java 7 would be a lot less. Moving from Java 5 to Java 6 (a few weeks ago, for me) resulted in about 6 or 7 "contaminated" bundles, from that same sample. I was hoping for similarly small number. So, if Java 7 results in the same amount of contamination as Java 8, we'd know to stick with Java 8. If Java 7 does "contaminate" just 6 or 7, then would be better to stay on Java 7 for a while, IMHO. So, I'm asking if you'd have time, today, to switch to Java 7, let me run my couple-of-hours test, and depending on the results, possibly switch back? *"Contamination" is used above is a relative term ... it doesn't necessarily mean there's something wrong with Java 8 (or 7, or 6) it could be that the original byte codes "were not quite right" when these jars were compiled many many years ago. (This is my "Orbit sample" :) I've swapped in Java 7, worst case I can switch back to Java 8 monday morning. -M. (In reply to Eclipse Webmaster from comment #22) > I've swapped in Java 7, worst case I can switch back to Java 8 monday > morning. > > -M. Thank you. Tests started about 4:20 Eastern. Will post results about 6:30. (In reply to Eclipse Webmaster from comment #22) > I've swapped in Java 7, worst case I can switch back to Java 8 monday > morning. > > -M. Ugh, oh. I just noticed this in the "signing log". /home/data/users/genie/signing/sign_queue_process.sh: line 83: /opt/public/common/jdk1.70-latest//bin/java: No such file or directory One too many slashes? And, need another 'dot', in jdk1.7.0-latest (In reply to David Williams from comment #24) > (In reply to Eclipse Webmaster from comment #22) > > I've swapped in Java 7, worst case I can switch back to Java 8 monday > > morning. > > > > -M. > > Ugh, oh. I just noticed this in the "signing log". > > /home/data/users/genie/signing/sign_queue_process.sh: line 83: > /opt/public/common/jdk1.70-latest//bin/java: No such file or directory > > One too many slashes? And, need another 'dot', in > jdk1.7.0-latest And probably some error checking if [[ ! -x {JAVA_CMD} ]] then send mail to webmaster :) fi Fixed, sorry about that. -M. (In reply to David Williams from comment #23) > (In reply to Eclipse Webmaster from comment #22) > > I've swapped in Java 7, worst case I can switch back to Java 8 monday > > morning. > > > > -M. > > Thank you. Tests started about 4:20 Eastern. Will post results about ... The results were the same. Literally. AND THEN I got the bright idea to find out more directly if there was a difference between Java 7 and Java 8 pack200 and unpack200. And, there is none, according to the "-version" query. (But, there is a difference from them, and Java 6 and Java 5). $ /shared/common/jdk1.5.0-latest/bin/pack200 -V com.sun.java.util.jar.pack.Driver version 1.23, 06/04/14 $ /shared/common/jdk1.6.0-latest/bin/pack200 -V com.sun.java.util.jar.pack.Driver version 1.26, 10/03/23 $ /shared/common/jdk1.7.0-latest/bin/pack200 -V com.sun.java.util.jar.pack.Driver version 1.31, 07/05/05 $ /shared/common/jdk1.8.0_x64-latest/bin/pack200 -V com.sun.java.util.jar.pack.Driver version 1.31, 07/05/05 = = = = $ /shared/common/jdk1.5.0-latest/bin/unpack200 -V unpack200 version 1.24, 08/10/16 $ /shared/common/jdk1.6.0-latest/bin/unpack200 -V unpack200 version %I%, %E% $ /shared/common/jdk1.7.0-latest/bin/unpack200 -V unpack200 version 1.30, 07/05/05 $ /shared/common/jdk1.8.0_x64-latest/bin/unpack200 -V unpack200 version 1.30, 07/05/05 So, bottom line, Matt was right in the beginning, and we just as well be on Java 8, which at this point, is the same as Java 7, but, you never know, the next "fix pack" of Java 8 might have an updated version of pack/unpack, and we would likely not get that, if still on Java 7. I've opened enhancement request via bug 464432 to provide a "version" option for the batch 'sign' command. (I am currently unsure how that interacts with the CBI maven plugin, to "sign jars"). So ... Java 8 on Monday? (And, that's more "for the future updates", as over the weekend, it will give same results as current Java 7 latest. Thanks Matt, for your work on this today. Very helpful, as always. I don't think moving selectively to Java 8 is a good idea. I think we should have a preferred Java version and wherever possible use that so that we minimize opportunities for version number conflict excitements. Until we are ready to recommend that all builds, aggregations, signings, .... use Java 8, I think the preferred version should be Java 7. (In reply to Ed Willink from comment #28) > I don't think moving selectively to Java 8 is a good idea. > > I think we should have a preferred Java version and wherever possible use > that so that we minimize opportunities for version number conflict > excitements. > > Until we are ready to recommend that all builds, aggregations, signings, > .... use Java 8, I think the preferred version should be Java 7. Did you not read in comment 27 that the version of pack200 is identical in Java 7 and Java 8? If you'd prefer, just think of it as "we are moving to pack200 version 1.30." I just got the following error from an Orbit contribution at the end of a Hudson build (https://hudson.eclipse.org/ocl/job/ocl-mars-master/181/). The previous build yesterday was fine. Please can we revert to Java 6 until we have a -version option. [ant] Queueing site_556104136.zip for signing [ant] WARNING: /shared/download-staging.priv/ocl/out20150411060726 is not a valid directory. Creating. [ant] File /shared/download-staging.priv/ocl/site_556104136.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.ocl.releng.build:eclipse.feature$1.3.0.qualifier#site.signed] INFO: [start org.eclipse.ocl.releng.build:eclipse.feature$1.3.0.qualifier#site.packed] java.lang.SecurityException: invalid SHA1 signature file digest for lpg/runtime/IAbstractArrayList.class Caused by: Terminating xvnc. Recording test results Archiving artifacts Sending e-mails to: adolfosbh@gmail.com ed@willink.me.uk ocl-luna-consumers is disabled. Triggering skipped Finished: FAILURE (In reply to Ed Willink from comment #30) > I just got the following error from an Orbit contribution at the end of a > Hudson build (https://hudson.eclipse.org/ocl/job/ocl-mars-master/181/). The > previous build yesterday was fine. Please can we revert to Java 6 until we > have a -version option. > I don't understand how this change for *this* bug could possibly be related to Orbit, Since we've not used it yet. If you mean you moving to Java 7 you have not found a new problem with Orbit bundles, which used pack200 from Java 6, then you are welcome to do what ever you would like, with your own build, either for your whole build, or with your pack200 processor: https://wiki.eclipse.org/JarProcessor_Options#Other_properties I hope you are not saying you are re-processing Orbit bundles. Honestly Ed. this change, for this bug, should not impact you hardly at all. If you are saying "moving your build to Java 7" is problematic, I think that is a whole other topic. Please don't pollute this bug, with everyone of those problems. (In reply to David Williams from comment #31) > I hope you are not saying you are re-processing Orbit bundles. > > Honestly Ed. this change, for this bug, should not impact you hardly at all. > > If you are saying "moving your build to Java 7" is problematic, I think that > is a whole other topic. Please don't pollute this bug, with everyone of > those problems. (I've built again and the problem is repeatable.) This problem appears to be a 6 to 7 (not 7 to 8) problem so it would still occur with my preferred Java 7 everywhere. From my limited understanding I think what has happened is: Orbit LPG has been built and packed with Java 5 pack200. Now the signer unpacks it with Java 7/8 unpack200 and fails. Workaround: Eclipse OCL will be unsigned. Simple solution: continue using Java 6 for signing Simplish solution: provide a -version option so that Orbit redistributors can use Java 6 signing Horrible solution: some Orbit bundles should be adjusted to have an eclipse.inf that suppresses bad packing. Really horrible solution: use Java 7 everywhere implies Orbit should be rebuilt using Java 7. (In reply to Ed Willink from comment #32) > Workaround: Eclipse OCL will be unsigned. Confirmed. We already had a no-sign option for faster test builds. Using it now enables us to build 'successfully'. (In reply to Ed Willink from comment #32) > (In reply to David Williams from comment #31) > > I hope you are not saying you are re-processing Orbit bundles. > > > > Honestly Ed. this change, for this bug, should not impact you hardly at all. > > > > If you are saying "moving your build to Java 7" is problematic, I think that > > is a whole other topic. Please don't pollute this bug, with everyone of > > those problems. > > (I've built again and the problem is repeatable.) > > This problem appears to be a 6 to 7 (not 7 to 8) problem so it would still > occur with my preferred Java 7 everywhere. > > From my limited understanding I think what has happened is: > > Orbit LPG has been built and packed with Java 5 pack200. > > Now the signer unpacks it with Java 7/8 unpack200 and fails. > I suggest you open an Orbit bug with the specific bundles that are causing not working for you you, and we can fix those. The vast majority should work with any VM, but it is known that some don't. Such as see bug 462276. (And, while it will bring you little comfort, I'll confess Orbit's "process" has been a little sloppy lately ... purely my fault ... but, that's really more an Orbit problem rather than anything related to *this* bug). (In reply to David Williams from comment #34) > that's really more > an Orbit problem rather than anything related to *this* bug). I beg to differ. While SimRel requires Eclipse bundles to be signed and some Orbit bundles are unsignable, it is very much an issue concerning this bug. The reversible signing change from Java 6 to 7 currently forces Eclipse OCL to be unsigned. (In reply to Ed Willink from comment #32) I've just rebuilt with the latest Orbit I-build. No change. > From my limited understanding I think what has happened is: > > Orbit LPG has been built and packed with Java 5 pack200. > > Now the signer unpacks it with Java 7/8 unpack200 and fails. I didn't read the log file carefully enough. The normal successful flow is: INFO: [start org.eclipse.ocl.releng.build:eclipse.feature$1.3.0.qualifier#copy.plugins] INFO: [end org.eclipse.ocl.releng.build:eclipse.feature$1.3.0.qualifier#copy.plugins] INFO: [start org.eclipse.ocl.releng.build:eclipse.feature$1.3.0.qualifier#site.repacked] INFO: [end org.eclipse.ocl.releng.build:eclipse.feature$1.3.0.qualifier#site.repacked] INFO: [start org.eclipse.ocl.releng.build:eclipse.feature$1.3.0.qualifier#site.signed] [ant] Queueing site_1964689.zip for signing [ant] WARNING: /shared/download-staging.priv/ocl/out20150408183134 is not a valid directory. Creating. [ant] File /shared/download-staging.priv/ocl/site_1964689.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.ocl.releng.build:eclipse.feature$1.3.0.qualifier#site.signed] INFO: [start org.eclipse.ocl.releng.build:eclipse.feature$1.3.0.qualifier#site.packed] INFO: [end org.eclipse.ocl.releng.build:eclipse.feature$1.3.0.qualifier#site.packed] INFO: [start org.eclipse.ocl.releng.build:eclipse.feature$1.3.0.qualifier#versioned.manifest] INFO: [end org.eclipse.ocl.releng.build:eclipse.feature$1.3.0.qualifier#versioned.manifest] from which it is seems that the internal functionality of Buckminster is: ... site.repacked site.signed site.packed ... The failure occurs in site.packed, which makes it look as if signing has been successful, but the signed output is not acceptable to Buckminster for packing. This seems to be nothing to do with Orbit. More possible is that a Java 8 signed output is not understood by Buckminster 4.4. Is Buckminster 4.4 using Java 7 packing from its VM, or Java 6 packing from its release BREE? You commented earlier that multiple packing and signing was not good. I've no idea what Buckminster is doing. Does the above sequence appear unwise? (In reply to Ed Willink from comment #36) > (In reply to Ed Willink from comment #32) > I've just rebuilt with the latest Orbit I-build. No change. > > > From my limited understanding I think what has happened is: > > > > Orbit LPG has been built and packed with Java 5 pack200. > > > > Now the signer unpacks it with Java 7/8 unpack200 and fails. > > I didn't read the log file carefully enough. > > The normal successful flow is: > > INFO: [start > org.eclipse.ocl.releng.build:eclipse.feature$1.3.0.qualifier#copy.plugins] > INFO: [end > org.eclipse.ocl.releng.build:eclipse.feature$1.3.0.qualifier#copy.plugins] > INFO: [start > org.eclipse.ocl.releng.build:eclipse.feature$1.3.0.qualifier#site.repacked] > INFO: [end > org.eclipse.ocl.releng.build:eclipse.feature$1.3.0.qualifier#site.repacked] > INFO: [start > org.eclipse.ocl.releng.build:eclipse.feature$1.3.0.qualifier#site.signed] > [ant] Queueing site_1964689.zip for signing > [ant] WARNING: /shared/download-staging.priv/ocl/out20150408183134 is not a > valid directory. Creating. > [ant] File /shared/download-staging.priv/ocl/site_1964689.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.ocl.releng.build:eclipse.feature$1.3.0.qualifier#site.signed] > INFO: [start > org.eclipse.ocl.releng.build:eclipse.feature$1.3.0.qualifier#site.packed] > INFO: [end > org.eclipse.ocl.releng.build:eclipse.feature$1.3.0.qualifier#site.packed] > INFO: [start > org.eclipse.ocl.releng.build:eclipse.feature$1.3.0.qualifier#versioned. > manifest] > INFO: [end > org.eclipse.ocl.releng.build:eclipse.feature$1.3.0.qualifier#versioned. > manifest] > > from which it is seems that the internal functionality of Buckminster is: > > ... > site.repacked > site.signed > site.packed > ... > > The failure occurs in site.packed, which makes it look as if signing has > been successful, but the signed > output is not acceptable to Buckminster for packing. This seems to be > nothing to do with Orbit. > More possible is that a Java 8 signed output is not understood by > Buckminster 4.4. Is Buckminster 4.4 > using Java 7 packing from its VM, or Java 6 packing from its release BREE? > > You commented earlier that multiple packing and signing was not good. I've > no idea what Buckminster is > doing. Does the above sequence appear unwise? Similar discussion is going in in bug 461669. While neither this one, nor that one was intended to be for "buckminster builds" let's focus the discussion in one place. See if my last comment there is helpful, bug 461669 comment 8. So should I have the signer use Java 8 or leave it alone for now? -M. (In reply to Eclipse Webmaster from comment #38) > So should I have the signer use Java 8 or leave it alone for now? > > -M. Yes, 8 please. From everything I can see, should be identical at this point in time. And, btw, I don't know for sure that it matters, but I think is should be point to the x64 version of Java 8 latest (which is 64 bit) ... the naming on /shared/common/jdk*-latest is very confusing. In principle (do not know about practice) a 64 bit app that is heavily IO dependent should be a tiny bit faster that it's 32 bit counter part. So, that'd be /shared/common/jdk1.8.0_x64-latest Thank you. P.S. I'm confident that these issues with Buckminster builds have been "bugs" all along (perhaps "bugs" of process, not necessarily Buckminster itself ... I don't know enough about it), and, this change makes those "bugs" more obvious, but it is important to fix them whether obvious or not. P.S.S. And, it's not just Buckminster, there was a bug in Orbit processes too that this change made more obvious, now fixed. (bug 464100). Ok I've updated the signing tool to use Java 8. -M. fixed per previous comment I verified the signing service still works .. no typos. :) Sorry. This is VERIFIED BROKEN. Eclipse OCL cannot be signed. Please revert to Java 6 or provide the Buckminster solution for Orbit Jars. (In reply to Ed Willink from comment #43) > Sorry. This is VERIFIED BROKEN. > > Eclipse OCL cannot be signed. > > Please revert to Java 6 or provide the Buckminster solution for Orbit Jars. Same here. After signing with java8 already signed orbit jars are re-signed and broken. java.inject for example. MANIFEST.MF Before: Bundle-ManifestVersion: 2 Name: javax/inject/Singleton.class SHA1-Digest: nWl5vSgc422lSXxvtBzhJ+VOZcw= Name: javax/inject/Provider.class SHA1-Digest: pIRji7h2izIB/+sCY2EnAFhTQn8= Name: javax/inject/Inject.class SHA1-Digest: hnbcAwYXUbkWOJsQxHhTqqR+c3s= ..after: Bundle-ManifestVersion: 2 Name: about.html SHA-256-Digest: Rj3IzLQTn+3IqFTA6An70TPyHPEYhXNfrZgAvtj9DJM= SHA1-Digest: uLAsDULTzC8HbUXgFh/wj37WTe4= Name: javax/inject/Inject.class SHA-256-Digest: mWzuF6vZrt9m0fzsdEC8HKmvdzbhIHz2Ia9HupJWnFQ= SHA1-Digest: hnbcAwYXUbkWOJsQxHhTqqR+c3s= Name: javax/inject/Scope.class SHA-256-Digest: HdDc9Ky7QfPupLfE2SQ6iH05r6uY5xFmF5GVDBqHsaM= SHA1-Digest: KpdRdjP9gxcZBs328OYQZxzWdwg= Also the files produced differ: before: MacHuebner:javax.inject_1.0.0.v20091030 dhuebner$ ls -l META-INF/ total 40 -rw-r--r-- 1 dhuebner staff 5638 24 Jan 2011 ECLIPSEF.RSA -rw-r--r-- 1 dhuebner staff 863 24 Jan 2011 ECLIPSEF.SF -rw-r--r-- 1 dhuebner staff 980 24 Jan 2011 MANIFEST.MF -rw-r--r-- 1 dhuebner staff 76 24 Jan 2011 eclipse.inf After: MacHuebner:javax.inject_1.0.0.v20091030.1 dhuebner$ ls -l META-INF/ total 64 -rw-r--r-- 1 dhuebner staff 5638 24 Jan 2011 ECLIPSEF.RSA -rw-r--r-- 1 dhuebner staff 863 24 Jan 2011 ECLIPSEF.SF -rw-r--r-- 1 dhuebner staff 6283 14 Apr 02:44 ECLIPSE_.RSA -rw-r--r-- 1 dhuebner staff 1081 14 Apr 02:44 ECLIPSE_.SF -rw-r--r-- 1 dhuebner staff 1538 14 Apr 02:44 MANIFEST.MF -rw-r--r-- 1 dhuebner staff 76 24 Jan 2011 eclipse.inf Note that the new files ECLIPSE_.* contains SHA-256-Digest but existing ECLIPSEF.* old SHA1-Digest created by java 1.6. I'm not a siging expert, but I hope it could be solved by one of the jarsigner options ? [-sigfile <file>] name of .SF/.DSA file [-digestalg <algorithm>] name of digest algorithm If we could update the old signatures in a jar, or just skip already signed jars (calling jarsigner -verify ?) it would fix the issue. Hi Dennis, Giving your comments and after a quick look up in the bucky book, I've got an idea for a possible a workaround from buckminster scripts. Buckminster provides an ant task in order to remove the jar signature (buckminster.signatureCleaner). Invoking that ant task at the proper moment, let's say after the orbit jar has been fetched, and prior to build the p2 site could make the redistributed orbit jar be properly resigned with the new signer and perhaps make the entire building process be happy again. Cheers, Adolfo. David: Is this an Orbit 'problem' that we can fix by re-signing things? At this stage based on Denniss report I'm going to agree with Ed that this does seem 'broken'. As such for right now I've reverted sign to use Java 6 so Ed and Dennis can get their builds done. -M. (In reply to Eclipse Webmaster from comment #46) > David: Is this an Orbit 'problem' that we can fix by re-signing things? > > At this stage based on Denniss report I'm going to agree with Ed that this > does seem 'broken'. As such for right now I've reverted sign to use Java 6 > so Ed and Dennis can get their builds done. > > -M. That's a shame. Easy to build, hard to build correctly, I like to say. And, I do sympathize that Buckminster is not more actively supported, but I think there must be ways that Buckminster could still be used ... but admit I don't have time to look at it. (In reply to David Williams from comment #47) > (In reply to Eclipse Webmaster from comment #46) > > David: Is this an Orbit 'problem' that we can fix by re-signing things? > > > > At this stage based on Denniss report I'm going to agree with Ed that this > > does seem 'broken'. As such for right now I've reverted sign to use Java 6 > > so Ed and Dennis can get their builds done. > > > > -M. > > That's a shame. Easy to build, hard to build correctly, I like to say. > > And, I do sympathize that Buckminster is not more actively supported, but I > think there must be ways that Buckminster could still be used ... but admit > I don't have time to look at it. That should not be the permanent solution. Just give us time to figure out how to fix this. It would be also interesting to know or better to see how the signing script works/looks like. Is it possible to have both versions running? So we can keep production jobs running against java 6 signing and set up a test job which sign with the java 8? (In reply to David Williams from comment #47) > And, I do sympathize that Buckminster is not more actively supported, but I > think there must be ways that Buckminster could still be used ... but admit > I don't have time to look at it. It has become increasingly clear in the last year that while moving from PDE to Buckminster was perhaps a good idea three years ago, it is not now. Tycho clearly rules. So I have migration to Tycho down on my Mars+1 activities, but there is no way I have time to migrate before Mars. This of course makes me even less enthusiastic about sorting out Buckminster fudges now. (In reply to Dennis Huebner from comment #48) > That should not be the permanent solution. Just give us time to figure out > how to fix this. I figured that we'd get things 'fixed' and then use the time after Mars to try and overhaul things. > It would be also interesting to know or better to see how the signing script > works/looks like. The process itself is pretty simple, and consists of 3 parts: 1) signing client 2) the signing queue manager 3) the signer As a rule projects use #1 to insert records into a queue, which is processed by #2 which calls #3 to do the actual signing. While these are basically all shell scripts #2 and #3 use Java(to call jarprocessor(#2) and jarsigner(#3)), and of course they were each using different Java versions which resulted in one of the bugs you found. > > Is it possible to have both versions running? I think so, if Ed and David agree I'm willing to try and tweak things so that people that want to use java 8 can pass some parameter to the sign script (-java8 ?) to try and support both versions. I'm a little concerned making these changes with Mars in the near future. -M. (In reply to Eclipse Webmaster from comment #50) > While these are basically all shell scripts #2 and #3 use Java(to call > jarprocessor(#2) and jarsigner(#3)), and of course they were each using > different Java versions which resulted in one of the bugs you found. It seems that you are in control of the code (unlike Buckminster where we are hidden behind helpful automation). It appears that one of the problems is that re-signing Orbit jars used to be ok. Now it isn't. So can you add a bypass so that already-signed jars are not re-signed? (In reply to Eclipse Webmaster from comment #50) > > I'm a little concerned making these changes with Mars in the near future. > Likewise, I'd be concerned about making these changes in a service release. (That was my motivation for suggesting to do it now). As for comments 44, I'm not sure if that's addressed to me, but if the comment means there are Orbit bundles with same id and qualifier, but are different, then that would ordinarily be an Orbit bug, and I would look at it and fix it there. If is is saying that "no one should re-sign" an Orbit bundle, then I'd agree. FWIW, I began looking at this in detail, due to bug 461669, where it's obvious we have some "slop" in the system, somewhere. While I still need to understand where that is coming from, if it is because people are re-signing Orbit bundles, then it will be a "blocking" bug later, getting the Sim. Release done. (Just to give a heads up.) But, perhaps that is not what was meant by comment 44? (In reply to Ed Willink from comment #51) > It appears that one of the problems is that re-signing Orbit jars used to be > ok. Now it isn't. So can you add a bypass so that already-signed jars are > not re-signed? Can you help me understand how I determine if a jar should(n't) be re-signed? Not having any insight into the build process and tooling, it seems odd to me that it would call the signer and expect things to remain unmodified.... -M. (In reply to Eclipse Webmaster from comment #53) > (In reply to Ed Willink from comment #51) > > > It appears that one of the problems is that re-signing Orbit jars used to be > > ok. Now it isn't. So can you add a bypass so that already-signed jars are > > not re-signed? > > Can you help me understand how I determine if a jar should(n't) be > re-signed? > > Not having any insight into the build process and tooling, it seems odd to > me that it would call the signer and expect things to remain unmodified.... > > -M. Yeah, and not sure how the jar signer could know, or not. But, your comment did remind me of one important reason to fix bug 464541! I presume that the status of "jarsigner -verify" will distinguish signed from unsigned. The purpose of the signing service is ambiguous unless someone can provide a formal specification. a) sign everything b) make sure everything is signed a) is easier to implement b) is easier to consume It seems that we perhaps accidentally used b) although the Java 8 change has highlighted that we had implemented a). It is difficult for a variety of different build systems to partition their candidate output into separate signed/unsigned parts, submit only the unsigned part for signing and then merge the partition back gain. It would seem relatively easy for the one signing service to do this. (In reply to David Williams from comment #54) > (In reply to Eclipse Webmaster from comment #53) > > (In reply to Ed Willink from comment #51) > > > > > It appears that one of the problems is that re-signing Orbit jars used to be > > > ok. Now it isn't. So can you add a bypass so that already-signed jars are > > > not re-signed? > > > > Can you help me understand how I determine if a jar should(n't) be > > re-signed? > > > > Not having any insight into the build process and tooling, it seems odd to > > me that it would call the signer and expect things to remain unmodified.... > > > > -M. > > Yeah, and not sure how the jar signer could know, or not. But, your comment > did remind me of one important reason to fix bug 464541! I think Dennis pointed out some clues. The signer could try to verify [1] the jar. If the verification is successful that means it's signed, hence no need to resign. I guess that additions can be considered, e.g. in order to skip the signing, the jar must be signed by Eclipse.org Cheers, Adolfo. [1] http://docs.oracle.com/javase/6/docs/technotes/tools/windows/jarsigner.html#Verifying (In reply to Ed Willink from comment #55) > It is difficult for a variety of different build systems to partition their > candidate output into separate signed/unsigned parts, submit only the > unsigned part for signing and then merge the partition back gain. That is also my opinion. > It would seem relatively easy for the one signing service to do this. If you need some help or just testers to implement a "smart signing" service, please let me know. We have separate jobs to run our production build in test mode, plus a simrel-test job that verifies even more things. (In reply to Dennis Huebner from comment #57) > (In reply to Ed Willink from comment #55) > > It is difficult for a variety of different build systems to partition their > > candidate output into separate signed/unsigned parts, submit only the > > unsigned part for signing and then merge the partition back gain. > > That is also my opinion. > > > It would seem relatively easy for the one signing service to do this. > > If you need some help or just testers to implement a "smart signing" > service, please let me know. We have separate jobs to run our production > build in test mode, plus a simrel-test job that verifies even more things. Just to cross-reference some history on this topic, bug 174475 was opened 9 years ago, for the "jarprocessor" to have this logic (of, not touching things that were already signed). One thing that is important to know ... though, I guess not directly related to this bug, is how CBI and Tycho "pack" and sign jars. Those with Tycho builds might have to do some special stuff to make sure they conform to Java 6, such as use
-Dorg.eclipse.update.jarprocessor.pack200=${JAVA_6_HOME}/jre/bin
where
JAVA_6_HOME=/shared/common/jdk1.6.0-latest
And, that implies users might have to do the same, to avoid "unpack" problems.
I guess the root problem with moving to Java 8 was (and still is) that, supposedly, Buckminster re-signs everything, with no way to override that.
And for some reason, "shows up" less of a problem when Java 6 is used. Perhaps due to old Orbit bundles which should not be re-signed, but were originally signed/packed using Java 5 or Java 6.
Mostly just wanted to document the potential issue with Tycho build, since I've reverted bug 463010 and since have moved Orbit builds back to use Java 6.
Another reason I started this investigation or issue was that so many people were having trouble with "pack200", they stopped using it completely, thus, increasing bandwidth required to "update" or "install" new features (but, I do not really know the magnitude of that effect, over all).
... Just making notes to communicate what I know (and, so I don't forget :). Sorry if "just noise" to others.
(In reply to David Williams from comment #59) > ... Just making notes to communicate what I know (and, so I don't forget :). > Sorry if "just noise" to others. This has been a very painful learning experience, but as you pointed out elsewhere, between SR2 and SR0 is the lowest risk time. Most of the problems seem to be plausibly explainable by having previously got away with double signing. So it would seem that the simple enhancement to the signer to not re-sign might solve all the problems and allow us to make Java 7/8 progress after all. NB we do not really know whether the double signing is two certificates or two Javas, so reverting to Java 6 may not solve the problem after all. Reverting to the old certificate is obviously not an option. NB2 Not re-signing should also mean no error for an unpack failure either, so already signed unchanged bundles should not be a Java 6/7 problem. The signer should 'catch' the Java 7 unpack failure and try Java 6 instead. (In reply to Ed Willink from comment #60) > Most of the problems seem to be plausibly explainable by having previously > got away with double signing. I think you might be right. And upon re-reading that 8 year old bug bug 174475 realize we have all be under educated about this. It was pretty well pointed out in that bug, that for some bundles it works, and for some bundles it does not work (and that was all using the same VM and same certificate!) AND, that even when it "worked" it would still sometimes be enough of a change to change the checksum of of the file, which of course, p2 will check, if it is available, which is especially problematic on composite repositories. (That is, you can have the same jar, down to the versioning, in two child repos, each with valid signatures, but different checksums, and you never know which one p2 will end up with; one might be seen as "md5 was as expected", the other might be "md5 differed from what was expected". (As I understand it). I've been trying to understand/reproduce the latest aggregator 'tampering' problems on the Epsilon bundles redistributed by QVTd. The original bundles from the Epsilon repo are unsigned and built with Java 6. Re-signing or chaned certificates cannot therefore be part of the problem. For the osgi.bundle,org.eclipse.epsilon.flock.engine,1.3.0.201503231233 failure, I have tried all permutations of pack/unpack with 6/7 and am unable to reproduce a failure as diagnosed by "jarsigner -verify". Probably because none of my permutations are signed. So it seems that it is not a pack 7 of Java 6 build that it is the problem. It is the signing of the pack 7 of the java 6 build. But what is 'signing'? since it is *.pack.gz files that are signed, presumably the 'signing' must involve unpack200/jarsigner/pack200, so the real issue may be that it is unsafe for the 'signing' re-pack200 to use a different Java to the earlier pack200. If this is correct, it may be mandatory for the signing service to detect the original packing-Java and unpack/re-pack with the original version. I've made a few changes to the singing process to try and 'make everyone happier'. Here are the 'main' changes: 1) The sign command now ignores(refuses to queue) jars that jarsigner -verify returns 'verified' for. 2) You must provide one of now,mail or nomail. Before this wasn't strictly enforced and my testing resulted in odd outcomes because of that. 3) You can use the flag 'java8' which will cause the signing queue processor to switch use the newest jarsigner.jar and invoke the signer command with Java 8 If you make no changes at all your build should continue to be signed/processed using Java 6(and will be ignored if the jar is already signed). I would like to see us move to using the newest version of Java be default before the end of the year. Is there a time (say September/October) that folks are comfortable with for a 'hard' change? -M. (In reply to Ed Willink from comment #62) > But what is 'signing'? since it is *.pack.gz files that are signed, > presumably the 'signing' must involve unpack200/jarsigner/pack200, so the > real issue may be that it is unsafe for the 'signing' re-pack200 to use a > different Java to the earlier pack200. If this is correct, it may be > mandatory for the signing service to detect the original packing-Java and > unpack/re-pack with the original version. No response ? (In reply to Eclipse Webmaster from comment #63) > I would like to see us move to using the newest version of Java be default > before the end of the year. Is there a time (say September/October) that > folks are comfortable with for a 'hard' change? As David pointed out, now between SR2 and SR0 is better. (I prefer a uniform preferred Java; i.e. move to Java 7 now for Mars, Java 8 for Mars+1. Mixing Java's is just too exciting.) (In reply to Ed Willink from comment #64) > No response ? Sorry I thought that was covered by comment 50. I have no insight into the jarprocessor, but I presume it is responsible for any re/un-packing, unless the 'skiprepack' flag is set. Outside of that we just use jarsigner to do the actual signing. > (In reply to Eclipse Webmaster from comment #63) > As David pointed out, now between SR2 and SR0 is better. Ok, > (I prefer a uniform preferred Java; i.e. move to Java 7 now for Mars, Java 8 > for Mars+1. Mixing Java's is just too exciting.) I agree but when I upgraded to Java 8 it apparently broke your builds(comment 35), and also seemed to cause Dennis some issues(comment 44). You made it clear(comment 43) that this was in your opinion 'broken', so I reverted to Java 6 to fix things(comment 46), which made David sad(comment 47). So now that it's possible for projects to use Java 8 to sign, without breaking their current Java 6 signing expectations, and we can try to change over with more notice, you're asking me to re-break things? -M. > > (I prefer a uniform preferred Java; i.e. move to Java 7 now for Mars, Java 8 > > for Mars+1. Mixing Java's is just too exciting.) > > I agree but when I upgraded to Java 8 it apparently broke your > builds(comment 35), and also seemed to cause Dennis some issues(comment 44). > You made it clear(comment 43) that this was in your opinion 'broken', so I > reverted to Java 6 to fix things(comment 46), which made David sad(comment > 47). For this problem it appears that Java 8 and 7 are the same so the move to 8 broke things. 7 would have too. By avoiding re-signing I think that you may have fixed most of the problems, so we can try again. But: (In reply to Eclipse Webmaster from comment #65) > > No response ? > Sorry I thought that was covered by comment 50 My experience with unsigned Epsilon bundles suggests that re-signing is not the sole problem. Inconsistent Java packing/unpacking rather than wrong Java packing is also a problem. So 'simple' questions: Are *.pack.gz files queued for signing directly or unpacked first and repacked afterwards by your scripts? Are *.pack.gz files queued for signing directly or unpacked first and repacked afterwards by signing tooling? If either is the true, then I think we require the Foundation's signing Java version to be the same as the Project's building Java version. Imposing one Java version on all project building is hard, so I suspect that the Foundation's signing should have a -version option. Better, it should sense the version automatically. (In reply to Ed Willink from comment #64) > (In reply to Ed Willink from comment #62) > > But what is 'signing'? since it is *.pack.gz files that are signed, > > presumably the 'signing' must involve unpack200/jarsigner/pack200, so the > > real issue may be that it is unsafe for the 'signing' re-pack200 to use a > > different Java to the earlier pack200. If this is correct, it may be > > mandatory for the signing service to detect the original packing-Java and > > unpack/re-pack with the original version. I'm not sure what you are saying, here, but I'll comment with what I think the steps are, and where important to "match": a. a "raw jar" is input (not previously conditioned (re-packed), not signed, and certainly no pack.gz files). b. the Jar is "repacked" (conditioned) in preparation for signing. c. jar is signed. d. the jar is "pack200'd", = = = = = e. user (p2) downloads and unpacks(200) the pack.jz file. ========================= Of all these, I think "b" and "d" are most important for the version of of tools to "match" each other (as well as what ever parameters are passed ... such as -E4 is common). c: I don't think the signing itself particularly has to match ... but just as well. e: I'm sure there are limits and limitations, but ideally several (at least newer) version can unpack200 any pack.gz file. Of course, we've seen where that's not completely true, which is one of the motivations to try to "be current" with what most users use (either 7 or 8, as far as I know, those two should behave the same). Like wise, version 7 or 8 should be able to "unpack bundles that were packed with Java 6 tools, or even java 5 tools. We are not the only ones that strive towards backwards compatibility. = = = = = Is this even close to what you are asking? On the issue of timing and when to do, and will it be breaking?, etc., It is, I think, important that we move up before Mars, to a "well known" version. But am not sure it is absolutely necessary. (And, I meant that literally, I do not know.) But, should be a lot easier, and safer now, that the "pack process" will not "re-sign" stuff. (Anyone know, is this the same "process" used by "web-service" version ... as might be used by CBI-signer plugin? I am just not sure how CBI and Tycho handles these ... since it's whole approach is fairly different. So wondering if "no re-sign" will apply to Tycho builds too? (automatically, or, perhaps they never did?) I suggest we try a "controlled" test phase, to see if feasible to "move to one" version. (Note: most builders, such as Tycho, and apparently Buckminster, do not really give release engineers the level of control to ever specify "-java8" to the processor/signer. The builder itself would have to do that ... and, suspect they would rahter not put in a temporary parameter, just for Eclipse. I hate to add to your workload, web masters, but perhaps you could look for an "environment variable too"? So anyone could find a place (as far as I know) to "export JAR_PROCESSOR_JAVA=8" or similar. One angle you webmasters probably are not aware of, that make it hard to "leave it up to each project" is that Orbit has to pick something ... and, lots of projects use those results ... and the b3 aggregator must pick something, and everyone has to "go through there" ... so it's not quite as easy as as 'everyone can do their own thing" But as I've said before ... I do not know what to recommend ... and think I've have literally said everything I know ... and given every bit of advise I can. And, ... even I am getting tired of changing builds, finding their faults, then having to revert, and sending notes to cross-project list, and then having to tell everyone "never mind" ... so, at this point, it is unclear what further help is wanted or needed from me. I believe the webmasters have taken over this work or process (which is probably how it should be, and which is much appreciated, by the way) so I see no alternative other than to go along with what they decide ... and am sure they will keep us informed ... and seek our feedback when they need it. (In reply to David Williams from comment #67) > I'm not sure what you are saying, here Ok a simpler question. What are the file name patterns that the user supplies for signing? *.jar or *.jar, *.pack.gz (In reply to Ed Willink from comment #69) > (In reply to David Williams from comment #67) > > I'm not sure what you are saying, here > > Ok a simpler question. > > What are the file name patterns that the user supplies for signing? > > *.jar or *.jar, *.pack.gz AFAIK, in this context, only *.jar and *.zip files (the zip, naturally, is recursed into, but only *.jar files are looked for. In fact, it will even look for jar files inside of jar files! It another context, in an eclipse client that is doing an "update", this area of code also deals with *.pack.gz files. Is there something to make you think otherwise? (In reply to David Williams from comment #70) > Is there something to make you think otherwise? My concern is that I find my observations with Epsilon bundles difficult to explain unless some form of pack/unpack occurs in the signing process, and since I thought our *.pack.gz files were being signed, I'm uncertain how this can happen without a potentially inconsistent form of pack/unpack there. I've tweaked the sign script to check for an environment var named 'JAR_PROCESSOR_JAVA', and if it contains 'java8' it will use that to do the signing and run the jarprocessor. Here's what I'd like to see happen now: Ed, David, and Dennis - can you guys try exporting this variable in a couple of your builds and then confirm here that the signed results are what you expect and most importantly that things are not broken. Once I have that I'm willing to invert the selector so that by default everything uses Java 8 and you can request via 'JAR_PROCESSOR_JAVA' that it use Java 6, with the idea that at some point Java 6 will no longer be supported. I understand this is a lot of work for all of us, but I'd like to try and get this 'right'. -M. (In reply to Eclipse Webmaster from comment #72) > I've tweaked the sign script to check for an environment var named > 'JAR_PROCESSOR_JAVA', and if it contains 'java8' it will use that to do the > signing and run the jarprocessor. > > Here's what I'd like to see happen now: > > Ed, David, and Dennis - can you guys try exporting this variable in a couple > of your builds and then confirm here that the signed results are what you > expect and most importantly that things are not broken. > > Once I have that I'm willing to invert the selector so that by default > everything uses Java 8 and you can request via 'JAR_PROCESSOR_JAVA' that it > use Java 6, with the idea that at some point Java 6 will no longer be > supported. > > I understand this is a lot of work for all of us, but I'd like to try and > get this 'right'. > > -M. Ok, thanks Matt. To clarify, the values are 'java8' (all lower case, no spaces) and will be 'java6' (all lower case, no spaces), right? I'll try a test build in Platform this weekend, but pretty sure will have no effect there since Maven/Tycho does it's own re-pack and pack, and pretty sure it has not been re-signing. I'll also try in Orbit, but this should only effect "new" bundles to Orbit, so will need to do some work or take some time before we have a new one ... or, I'll find an old one that needs some trivial repair. I won't change the aggregator right away, so Ed or Dennis, if you contribute something new there, and it "fails to unpack", I'll change right away, at that time to see if that "solves" the problem. (I'm sure I'll need to change at some point ... just don't want to change it for some reason we find out before then that something "prevents this change" from going forward. (In reply to Eclipse Webmaster from comment #72) > Ed, David, and Dennis - can you guys try exporting this variable in a couple > of your builds and then confirm here that the signed results are what you > expect and most importantly that things are not broken. I'm afraid that the signing service is about three levels of inaccessible away from what I understand. Any change I make is at least 90% likely to be wrong. If you can give me precise instructions on what you would like me to do to the https://hudson.eclipse.org/ocl/job/ocl-mars-master/ https://hudson.eclipse.org/ocl/job/qvtd-mars-master/ builds, I'll give it a go. I'm actually not having much luck with my test builds, so far with or without specifying JAR_PROCESSOR_JAVA It's as if here is some threading problem? Some sort of "leaking interaction"? I've opened my issues under another bug, Bug 464947 - Many "MALFORMED" exceptions during platform build, during pack200 And we can discuss there. (In reply to Ed Willink from comment #74) > (In reply to Eclipse Webmaster from comment #72) > > Ed, David, and Dennis - can you guys try exporting this variable in a couple > > of your builds and then confirm here that the signed results are what you > > expect and most importantly that things are not broken. > > I'm afraid that the signing service is about three levels of inaccessible > away from what I understand. Any change I make is at least 90% likely to be > wrong. > > If you can give me precise instructions on what you would like me to do to > the > > https://hudson.eclipse.org/ocl/job/ocl-mars-master/ > https://hudson.eclipse.org/ocl/job/qvtd-mars-master/ > > builds, I'll give it a go. Ed, I could not see in your scripts where to set environment variables, but from what I've read on the web, assuming you are the "HIPP instance admin" and all that HIPP instance does in OCL builds, then you can go under "Manage Hudson", "Syetmm Configuration" (I think), and under there, is a form to put "Global Properties", which should already have "environment variables" set .. and some key value pairs already set, such as ANT_OPTS with some proxy into. So, just "Add" another key-value pair, JAR_PROCESSOR_JAVA as key, and java8 as value. save, and to be safe, restart. You may want to add some place in some of your other bash scripts (that come before and after the Buckminstar build part, with echo "JAR_PROCESSOR_JAVA: ${JAR_PROCESSOR_JAVA}" just to be sure it is "in effect". And, even in your Java test code perhaps ave a small bit of code (or, uni test?) to use System.getEnvVariaable("JAR_PROCESSOR_JAVA"); and print out the value, to make sure it is in effect while running your code. ]Through out, check my spelling and exact names of variables and funtions ... I am jut going off the top of my head. (In reply to David Williams from comment #76) > So, just "Add" another key-value pair, JAR_PROCESSOR_JAVA as key, and java8 > as value. save, and to be safe, restart. > You may want to add some place in some of your other bash scripts (that come > before and after the Buckminstar build part, with > echo "JAR_PROCESSOR_JAVA: ${JAR_PROCESSOR_JAVA}" > just to be sure it is "in effect". I've tried that, but signing.log still reports it works with java6: 2015-04-20 08:07:32: build SIGNER(8934): Signing JAR file [/opt/public/download-staging.priv/modeling/emft/mwe/out20150420120407/temp_site_1979070228.zip/org.eclipse.emf.mwe2.runtime_2.8.0.v201504200803.jar] with Java 6 updating: META-INF/MANIFEST.MF (In reply to David Williams from comment #73) > Ok, thanks Matt. To clarify, the values are 'java8' (all lower case, no > spaces) and will be 'java6' (all lower case, no spaces), right? Correct. -M. (In reply to Dennis Huebner from comment #77) > (In reply to David Williams from comment #76) > > So, just "Add" another key-value pair, JAR_PROCESSOR_JAVA as key, and java8 > > as value. save, and to be safe, restart. > > You may want to add some place in some of your other bash scripts (that come > > before and after the Buckminstar build part, with > > echo "JAR_PROCESSOR_JAVA: ${JAR_PROCESSOR_JAVA}" > > just to be sure it is "in effect". > > I've tried that, but signing.log still reports it works with java6: > > 2015-04-20 08:07:32: build SIGNER(8934): Signing JAR file > [/opt/public/download-staging.priv/modeling/emft/mwe/out20150420120407/ > temp_site_1979070228.zip/org.eclipse.emf.mwe2.runtime_2.8.0.v201504200803. > jar] with Java 6 > updating: META-INF/MANIFEST.MF Ah, I see that too, in Orbit build, where I use the 'java8' argument, and tail the "signng log" 226947 2015-04-20 19:41:30: build SIGNER(9402): Signing JAR file [/opt/public/download-staging.priv/tools/orbit/orbit-I20150420213846.zip/temp_orbit-I20150420213846.zip/org.mozilla.javascript_1.7.4.v201504202130.jar] with Java 6 And yet, I'm pretty sure it is using Java 8 to call jarprocessor. Matt, besides the "jarprocessor" I think for 'java8' the *jarsigner* from Java 8 should also be called. Or, perhaps it is, and this is some "hard coded" message? Hmm, no, I don't think hard coded, I still see 'sha1' in MANIFEST, instead of SHA256. Some of this logging may come from the "jarprocesor" itself (which, may not be doing it right, or is hard coded?) would be best if the batch signer also logged java version (before and after starting on a zip file, simply because it's sometimes hard to capture the beginning .... and that'd be done by calling '<whatever java cmd is> -version Thanks. (In reply to David Williams from comment #79) > Ah, I see that too, in Orbit build, where I use the 'java8' argument, and > tail the "signng log" Hmmmm, that implies that the 'sign' command couldn't determine the value of JAR_PROCESSOR_JAVA and chose the default Java 6 path. > Matt, besides the "jarprocessor" I think for 'java8' the *jarsigner* from > Java 8 should also be called. Or, perhaps it is, You are correct, the Java 8 path uses both the new jar processor and the Java 8 jarsigner. >and this is some "hard coded" message? Both signers emit the 'same' message, but one will say 'Java 6' and the Other 'Java 8' > would be best if the batch signer also logged java version (before and after The queue processor should log which version of Java it's going to use: "Using Java8 to run jarprocessor and signing" or "Using Java6 to run old jarprocessor and signing" It should also be logging the entire command line for the jarprocessor. I've added a couple of debug messages to the batch signer so it should log "Batch signer is using Java X" into the signing log just before it checks to see if the jar is signed and before queuing the jar. -M. (In reply to Eclipse Webmaster from comment #80) > I've added a couple of debug messages to the batch signer so it should log > "Batch signer is using Java X" into the signing log just before it checks to > see if the jar is signed and before queuing the jar. > I'd already lost the log, before seeing that you added this msg, (so, I didn't check for it) but, I was still seeing 2015-04-21 14:15:48: build SIGNER(4266): Signing JAR file [/opt/public/download-staging.priv/tools/orbit/orbit-I20150421161440.zip/temp_orbit-I20150421161440.zip/org.slf4j.nop.source_1.6.4.v201212060702.jar] with Java 6 And, can still see my jars are signed with Java 6, since they say "SHA1" (instead of SHA266). So, can we check spelling? This it the ant task I'm using in Orbit builds: <exec executable="ssh" output="${signingHistory}" append="true"> <env key="JAR_PROCESSOR_JAVA" value="java8" /> <arg line="david_williams@build.eclipse.org /usr/bin/sign ${outputFile} nomail"/> </exec> Look right? In the little bit of 'signinghistory' I save automatically, I do see = = = = /usr/bin/sign: line 72: /home/data/httpd/download-staging.priv/arch/signer.log: Permission denied File /opt/public/download-staging.priv/tools/orbit/orbit-I20150421161440.zip/orbit-I20150421161440.zip added to queue. You will receive notification when the file is signed, if you used the mail parameter. You can check signing status by tailing /home/data/httpd/download-staging.priv/arch/signer.log = = = = So, something seems wrong with "line 72"? (Normally I see just that short part after the "line 72:" error msg. ) = = = = = = = = But, just to confirm, I'm setting an environment variable, for the script that "handles the queue". .... I assume it "passes it on" to the process that actually does the work? Perhaps that environment variable is "only" for the SSH environment (what ever that is?) If the spelling looks right, and you confirm "the queue script" passes it along to "the working queue", then guess I could try <arg line="david_williams@build.eclipse.org JAR_PROCESSOR_JAVA=java8 /usr/bin/sign ${outputFile} nomail"/> (In reply to David Williams from comment #81) > If the spelling looks right, and you confirm "the queue script" passes it > along to "the working queue", then guess I could try > > <arg line="david_williams@build.eclipse.org JAR_PROCESSOR_JAVA=java8 > /usr/bin/sign ${outputFile} nomail"/> Assuming nothing else has changed, *this* form of the command _finally_ worked! In our Orbit builds. Now comes the hard part. :) (of assessing impact). Unfortunately buckminster driven build have no control over the arguments passed to the sign executable [1].
<copy file="${input.file}" todir="${eclipse.staging.area}"/>
<exec executable="/usr/bin/sign" outputproperty="sign.output">
<arg value="${eclipse.staging.area}/${subject.file}"/>
<arg value="nomail"/>
<arg value="${staging.output.folder}"/>
</exec>
As you can see, there are only three args passed at the moment and there is no way to customize that. What we can set, is the eclipse.staging.area property. For MWE it's:
eclipse.staging.area=/shared/download-staging.priv/modeling/emft/mwe
@Matt
I know it's an effort, but is it possible to control the signing process by checking the signing source path? For example:
standard java6: /shared/download-staging.priv/modeling/emft/mwe
new java8: /shared/download-staging.priv/java8/modeling/emft/mwe
I will open a buckminster feature request, to add an additional JAR_PROCESSOR_JAVA argument to the signing service call. But I don't know when and if it will be implemented. The other problem is that we are using buckminster 4.3 at the moment, because we (and OCL) have some other issues with buckminster 4.4
[1] http://git.eclipse.org/c/buckminster/buckminster.git/tree/org.eclipse.buckminster.jarprocessor/src/org/eclipse/buckminster/jarprocessor/antscript/signing.ant#n210
(In reply to Dennis Huebner from comment #83) > Unfortunately buckminster driven build have no control over the arguments > passed to the sign executable [1]. I'm glad I've waited for David and you to path find. Seems like a nightmare. I expected it to be worse. IMHO any ability to influence the signing service should be a bug since a security service should be very resistant to tampering. > (and OCL) have some other issues with buckminster 4.4 OCL and QVTd seem to be ok with Buckminster 4.4. Indeed they are much better since with a modern JDT, we do not get inundated with spurious @NonNull diagnostics. For OCL and QVTd, this all seems like a lot of effort given that a move to Tycho seems increasingly necessary for Mars+1. Do any other projects see Buckminster as a long term build solution? In the long term it may be possible for Tycho to propagate a Java version for signing. Surely in the short and long term it would be much better for the signing service to sign each artefact automatically using the Java version with which the artefact was created/packed? Something like "javap -verbose MyClass | grep version" can determine the version, but it's a bit klunky. A simple tell-me-the-version program may be better. (In reply to David Williams from comment #81) > > So, something seems wrong with "line 72"? (Normally I see just that short > part after the "line 72:" error msg. ) In this case it means there was a permissions problem writing to the log file. I've fixed it. > But, just to confirm, I'm setting an environment variable, for the script > that "handles the queue". .... I assume it "passes it on" to the process > that actually does the work? Yes, it injects an extra value into the queue, which is picked up by the queue processor. > Assuming nothing else has changed, *this* form of the command _finally_ > worked! Great! (In reply to Dennis Huebner from comment #83) > I know it's an effort, but is it possible to control the signing process by > checking the signing source path? For example: > standard java6: /shared/download-staging.priv/modeling/emft/mwe > new java8: /shared/download-staging.priv/java8/modeling/emft/mwe Done. One thing I want to make everyone aware of: I've noticed that the batch signers logging of which java version it's requesting is sometimes a little confusing in the signing log, simply due to all 3 parts(queue manager,queue processor,signer) using the same log. For example: Batch signer is using Java 6 2015-04-22 10:39:01: build QUEUE(32163): Begin processing queue: /opt/public/download-staging.priv/z_webmaster/testing.jar:nomail:/opt/public/download-staging.priv/z_webmaster/test:: ======================= end of (32163) contents 2015-04-22 10:39:01: build QUEUE(32163): calling jarprocessor.jar for [/opt/public/download-staging.priv/z_webmaster/testing.jar] 2015-04-22 10:39:01: build QUEUE(32163): Using Java6 to run old jarprocessor and signing Batch signer is using Java 8 Basically the Java 8 notice is for the next item in the queue, but it kinda looks like it might be related to what's currently being processed. -M. To "report back" on Orbit assessment ... it's good! Based on this, I'm going to say we now "count on" this function, and assume it won't be reverted. In Orbit there were only two bundles that "didn't verify" after moving to Java 8. And they were old enough (and never used in Sim. Release) that I just removed them from our active build. Plus, we had several we had to "skip" early, (when things were in kind of a mixed state, where I thought I as re-packing with Java 8, but was really 6, so that broke verification of about 5 bundles, and those bundles have all been move back to normal, and verify just fine. I'm sure there's some old ones in Orbit that "should" be brought up to date .. but at least now, we an do "as needed", and not have to "touch everything". So, still don't know what to do about Buckminster, but I think the webmasters' fix to "not re-sign bundles" will help. As long as Buckminster does not automatically remove signatures? (Which, I don't think it does, as someone mentioned a "hook" that could be called before signing, to un-sign a bundle -- so, a) don't do that :) and b) I wonder if that same "hook" could be used to tweak that XML in comment 21? If that's not possible (or too much effort at this point), I'd suggest skipping the pack200 (but, still sign). One thing to be explicit about (i.e. that I'm not sure of) ... since the actual webservices "jar signer" was moved to Java 8, does that apply to all, now? no matter setting of JAR_PROCESSOR_JAVA? Thanks very much, > (In reply to Dennis Huebner from comment #83)
>
> > I know it's an effort, but is it possible to control the signing process by
> > checking the signing source path? For example:
> > standard java6: /shared/download-staging.priv/modeling/emft/mwe
> > new java8: /shared/download-staging.priv/java8/modeling/emft/mwe
>
> Done.
>
@Matt
Could you please create a folder /shared/download-staging.priv/java8/modeling/ with group&access rights like for /shared/download-staging.priv/modeling/ ? I have no write access to /shared/download-staging.priv/ :-/
(In reply to David Williams from comment #86) > To "report back" on Orbit assessment ... it's good! Awesome. > Based on this, I'm going to say we now "count on" this function, and assume > it won't be reverted. I not planning to, unless someone convinces me it'll be the end of civilization if I don't :) > One thing to be explicit about (i.e. that I'm not sure of) ... since the > actual webservices "jar signer" was moved to Java 8, does that apply to all, > now? no matter setting of JAR_PROCESSOR_JAVA? No. Since the webservice is independent of the batch signer(and does no jar processing) it's 'easier' to upgrade it in place. For right now(until Ed and/or Dennis confirm taht using Java 8 doesn't hose their builds) I'm going to leave the batch signer alone. Once I do have that confirmation though, I"m going to make Java 8 the default and Java 6 the option. Long term we should probably be moving towards having everyone use the webservice rather than the batch signer. (In reply to Dennis Huebner from comment #87) > Could you please create a folder > /shared/download-staging.priv/java8/modeling/ Actually my change should pickup on 'java8' anywhere in the path, so /shared/download-staging.priv/modeling/java8 should do the trick. -M. I've tried java8 signing and noticed that e.g. com.google.inject_3.0.0.v201312141243.jar was re-signed. Is that possible, that this jar is not recognized as signed? I've tried to verify the original orbit jar on my machine and got: ../java8/jarsigner -verify site-com.google.inject_3.0.0.v201312141243.jar jar verified. ../java7/jarsigner -verify site-com.google.inject_3.0.0.v201312141243.jar jar verified. Warning: This jar contains entries whose signer certificate has expired. This jar contains entries whose signer certificate will expire within six months. This jar contains entries whose certificate chain is not validated. Re-run with the -verbose and -certs options for more details. I will try with the latest orbit I-Build produced yesterday by David. Maybe I will have more luck. (In reply to Dennis Huebner from comment #89) > I've tried java8 signing and noticed that e.g. > com.google.inject_3.0.0.v201312141243.jar was re-signed. Is that possible, > that this jar is not recognized as signed? Webmasters, it is true we have some bundles that return "Jar verified" ... and then followed about other warnings "inside" the bundle. For the most part, those warnings re just "informational" for our purposes, and we still count the jar, as a whole, to be valid. If, in your check of output of jarsigner -verify, you are looking for strict ^Jar Verified$ then that's probably too strict, and anything that begins with ^Jar Verified would suffice. Are you using the "strict test"? (In reply to David Williams from comment #90) > (In reply to Dennis Huebner from comment #89) > > I've tried java8 signing and noticed that e.g. > > com.google.inject_3.0.0.v201312141243.jar was re-signed. Is that possible, > > that this jar is not recognized as signed? > > Webmasters, it is true we have some bundles that return "Jar verified" ... > and then followed about other warnings "inside" the bundle. For the most > part, those warnings re just "informational" for our purposes, and we still > count the jar, as a whole, to be valid. > > If, in your check of output of jarsigner -verify, you are looking for strict > ^Jar Verified$ > then that's probably too strict, and anything that begins with > ^Jar Verified > would suffice. > > Are you using the "strict test"? I used also the latest Orbit I Build, where com.google.inject jar verified well with both java, but the jar returned resigned. New 256 digest next to the old one: Name: com/google/inject/Scope.class SHA-256-Digest: Wa8rlWR0jmCkMPfJl8yYgjbXJTeTw7gA9zIeosJ3fc8= SHA1-Digest: GEkp/xnB1DG9mjUSaWRTpTRAsXo= ... and ECLIPSE_.RSA + .SF are changed/overridden Created attachment 252777 [details] re-signed jar jar I get back from the signing service. Ignore the -3 in file name, original was com.google.inject_3.0.0.v201312141243.jar. Original fetched from the Orbit I-Build http://download.eclipse.org/tools/orbit/downloads/drops/I20150422170642/ (In reply to David Williams from comment #90) > Are you using the "strict test"? No, the test is simply: $JARSIGNER -verify $FILE | grep -o "verified" . I've added an extra debug statement to /usr/local/bin/sign to log the result of the above test which should be either: Testing if $FILE is signed: [] <- jar is unsigned Testing if $FILE is signed: [verified] <- jar is signed. -M. (In reply to Dennis Huebner from comment #92) > Created attachment 252777 [details] > re-signed jar > > jar I get back from the signing service. Ignore the -3 in file name, > original was com.google.inject_3.0.0.v201312141243.jar. Original fetched > from the Orbit I-Build > http://download.eclipse.org/tools/orbit/downloads/drops/I20150422170642/ Dennis, I know Buckminster has the ability to "strip signatures" (and, thus resign them) ... could you by chance have that "on"? I don't know enough about Buckminster to describe how to tell if it is "on", but an earlier comment (in this or related bug) mentioned and "ant task hook" that would do it. I have confirmed even if there are "extra lines" (of informative warnings) that verify $FILE | grep -o "verified" returns 'verified' ... as desired. So, that's why I am thinking it is being "unsigned" in your build somewhere, Dennis. Update: I was able to exclude orbit jars from a zip send to the signing service. The remaining problem is, that we consume plain jars from orbit, so buckminster pack them with pack200 before including into our p2 repository. Need some more time for a workaround. If nothing helps I consider to remove orbit jars from our repository. (In reply to Ed Willink from comment #84) > Surely in the short and long term it would be much better for the signing > service to sign each artefact automatically using the Java version with > which the artefact was created/packed? > > Something like "javap -verbose MyClass | grep version" can determine the > version, but it's a bit klunky. A simple tell-me-the-version program may be > better. No response? This seems like a relatively simple and good way forward, sop that nobody sees a change. (In reply to Ed Willink from comment #96) > No response? This seems like a relatively simple and good way forward, sop > that nobody sees a change. I thought that the whole point of this bug was to get us using a less antiquated version of Java for the signing? -M. (In reply to Eclipse Webmaster from comment #97) > (In reply to Ed Willink from comment #96) > > > No response? This seems like a relatively simple and good way forward, sop > > that nobody sees a change. > > I thought that the whole point of this bug was to get us using a less > antiquated version of Java for the signing? > > -M. I'll comment too. If you use the highest version of Java to re-pack, sign, and pack, then that will (nearly always) be compatible with what ever lower version of Java was used to produce the byte codes. In the few cases it's not, then usually we need to change something anyway, or else users will hit the same problem if they use a higher version of Java (for example, when we learned we should not be packing nested jars). (In reply to David Williams from comment #98) > I'll comment too. If you use the highest version of Java to re-pack, sign, > and pack, then that will (nearly always) be compatible with what ever lower I think that it has been demonstrated very clearly that "nearly always" is not nearly always enough. So long as we accept that projects supply Java 5/6/7 builds using diverse build systems that have limited opportunities for intervention, the EF build extensions should support Java 5/6/7(/8). So IMHO, if the signing process recognized this, we would have had far fewer problems, and it would appear will still have far fewer problems. (In reply to Ed Willink from comment #99) > (In reply to David Williams from comment #98) > > I'll comment too. If you use the highest version of Java to re-pack, sign, > > and pack, then that will (nearly always) be compatible with what ever lower > > I think that it has been demonstrated very clearly that "nearly always" is > not nearly always enough. So long as we accept that projects supply Java > 5/6/7 builds using diverse build systems that have limited opportunities for > intervention, the EF build extensions should support Java 5/6/7(/8). > > So IMHO, if the signing process recognized this, we would have had far fewer > problems, and it would appear will still have far fewer problems. I do not understand your rationale, nor see you provide any evidence of it. Can you help us understand? (In reply to David Williams from comment #100) > I do not understand your rationale, nor see you provide any evidence of it. > Can you help us understand? Is seems that we have solid evidence that Java 7 unpack200 following a Java 6 pack200 causes trouble. Individual project builds have run consistently until recently on a given Java version that is the project's choice. A major source of trouble arose when the EF changed the signing step in the build process from Java 6 to 7/8. Reverting to Java 6 demonstrated that problems were fixed. In principle moving to 7 is good. Unfortunately it broke many things. So my suggestion is that the signing step automatically - use Java 6 for Java 6 projects => no breakage - use Java 7 for Java 7 projects => progress - use Java 8 for Java 8 projects => future proofing (In reply to Ed Willink from comment #101) > A major source of trouble arose when the EF changed the signing step in the > build process from Java 6 to 7/8. Reverting to Java 6 demonstrated that > problems were fixed. I have to agree. And although I didn't follow this bug very closely, I am stunned to see the outcome so far. It seems we were asked to use the central production service to test something that should have been tested offline before. David's comment below is quite assertive, and (understandably) went unchallenged, as it carried many assumptions -- one of them being that this change, a mere two months before the annual release, was understood and safe. Had we known that this change was largely unknown, we would have set up a parallel service! (In reply to David Williams from comment #13) > Changing title to avoid question, it's now affirmative. > > Webmasters, may I ask that this be done soon? (And, if not soon, can you say > when it can be scheduled?) If the current status of the signing infra is still flaky, I suggest we revert back to the previous Java 6 state, and we set up a parallel service for testing. (In reply to Ed Willink from comment #101) > (In reply to David Williams from comment #100) > > I do not understand your rationale, nor see you provide any evidence of it. > > Can you help us understand? > > Is seems that we have solid evidence that Java 7 unpack200 following a Java > 6 pack200 causes trouble. Yes, I agree with this one. This has been "well known" that you should use the same vm for -repack and pack. (Which is why I asked for a way to detect what version is being used, by batch signer). It seems to me, the main problem here is with Buckminster builds, for the simple reason no one can "control" them, or get fixes made. For those, I'd suggest you simply not pack this release, (but still sign), if you are having trouble. The webmasters adding the feature to not sign things that are already signed, I think solved many of the issues. (In reply to Denis Roy from comment #102) > > If the current status of the signing infra is still flaky, I suggest we > revert back to the previous Java 6 state, and we set up a parallel service > for testing. You'd break even more, by reverting at this point. I think what has not been clear to several reporting issues on this bug is that "things were broken before" ... and they just were never noticed. That is, yes, builds would "complete" but they were not correct builds. For example, they were changing signatures (and hence checksums) and these things would cause poor experiences for users. But, I agree, I certainly never realized there were builds being done, that people "could not control" -- but think that's better solved in other ways than reverting. (In reply to David Williams from comment #104) > (In reply to Denis Roy from comment #102) > > > > > If the current status of the signing infra is still flaky, I suggest we > > revert back to the previous Java 6 state, and we set up a parallel service > > for testing. > And, by the way, I think that's essentially one Matt ended up doing, by having the "java 8" be "opt in". If not opted in, then I believe buckminster builds go through same path that they did. And, I think Ed's problem is he can no longer build with Java 6, so ... he'd need some sort of change anyway, unless he can build with Java 6. I think that's out of the realm of "infrastructure". But can better understand now, that may be why he was indirectly asking for Java 7 too? In other words, we're done here? (In reply to David Williams from comment #105) > And, I think Ed's problem is he can no longer build with Java 6 I have made changes that enable me to live with a Java 7 build, so my comments are now aimed at avoiding problems that others may yet encounter. I predicted problems for EMF at M7 and Dennis has joined in the testing with strangely different problems now. My actions/workarounds are: - 90% of plugins moved to Java 7. - one plugin is not-packed. - six Epsilon plugin redistributions are hidden as internal libraries (In reply to Ed Willink from comment #101) > So my suggestion is that the signing step automatically > - use Java 6 for Java 6 projects => no breakage > - use Java 7 for Java 7 projects => progress > - use Java 8 for Java 8 projects => future proofing I have yet to see a comment on this. IMHO it gives the best of both worlds; progress without breakage. I can see that it requires some effort by the EF, but adding a version switch in a signing script would appear to be less than 10 script lines aided by a small tell-me-the-version tool. If this is too much effort, say so but please do not just ignore it. At this point, I see a gamble between the fairly predictable costs of implementing this solution and the uncertain costs of future pain for many projects. Note that it turned out that some/many Tycho projects did not have trouble at M6 because they have a Java 6 pack200 override. There is a risk that the difficulties experienced by Buckminster builds at M6 may affect Tycho builds at M7. (In reply to Denis Roy from comment #106) > In other words, we're done here? I think we are done, except that no one has "informed community" of all the different options and ways of picking one version over another, or the reasons why they might want to. In reply to Ed's comment 107, I don't think it is a bad idea to let user specify which version of Java to use (since, it is fundamental, that they do the final pack200 with the same version (and same parameters) as used for the -repack step. But, suggest we address that, with a different bug, at a slower pace. It will likely become important, when Java 9 comes out, since, at least from "executable versions" Java 7 and Java 8 report the same version is being used for pack200 (assuming that those programs are reporting their version correctly). I don't think it will be an issue for Tycho uses, since Tycho does both the -repack step, and the pack200 step (with same VM ... never heard of a Java 6 work around?) and Tycho uses "central service" only for signing (and there, pretty sure the version does not have to match anything else ... as long as nothing is re-signed). IMHO (In reply to David Williams from comment #108) > In reply to Ed's comment 107, I don't think it is a bad idea to let user > specify which version of Java to use (since, it is fundamental, that they do > the final pack200 with the same version (and same parameters) as used for > the -repack step. Apologies, I misunderstood the proposal. "letting user specify" is not what was proposed, and would have the same problems with some build systems as the "environment variable" or "command line option" had ... no control. So, if the proposal is to "peek at the byte codes", then not sure that would work, since some projects, use a bundles from a wide variety of "compiled Java". But would not want them (re-)packed with such variety. Was that the proposal, or was there another way to tell? [Another good reason for a new bug? :) ] (In reply to David Williams from comment #109) > So, if the proposal is to "peek at the byte codes", then not sure that would > work, since some projects, use a bundles from a wide variety of "compiled > Java". I'm assuming that the signing script contains a loop over the artefacts to be signed. I'm suggesting that within the loop, i.e. on a per-artefact basis, the Java version of that artefact is determined to select the Java version to be used by the signer for that artefact. (In reply to David Williams from comment #108) > I think we are done, except that no one has "informed community" of all the > different options and ways of picking one version over another, or the > reasons why they might want to. Yes please. The volume on this bug was a bit over my head. FYI, in a warm-up build for Object Teams M7 (explicitly calling batch signer on build.eclipse.org) I see lots of Signing JAR file [xyz] with Java 6 although all of the build is run on Java 8. What is this telling me? I'm happy to say that I didn't encounter any problems, so far, but I'm surprised by the above output. So: what should projects look for? How can we tell if our builds are fine after this change? (In reply to Stephan Herrmann from comment #111) > Yes please. The volume on this bug was a bit over my head. Agreed. I'll close this bug(as works for me) and others can be opened to discuss further specific changes. I've composed a note to cross-project to explain what's happened. > Signing JAR file [xyz] with Java 6 > although all of the build is run on Java 8. What is this telling me? This was added to make it clear that the batch signer is using both the Java 6 'jarsigner' command to do the actual signing as well as indicate it is using an older version of the jarprocessor.jar file. > So: what should projects look for? How can we tell if our builds are fine > after this change? I'm not really able to answer this, David, Ed can you provides some insight? -M. Not sure why you picked "worksforme" -- it has been "fixed", at least the sense you have provided a transition path that satisfies the original request. (In reply to Eclipse Webmaster from comment #112) > > > So: what should projects look for? How can we tell if our builds are fine > > after this change? > > I'm not really able to answer this, David, Ed can you provides some insight? Yes. I'm assuming you end up with a directory (such as p2 repository) that consists of *.jar files and *.jar.pack.gz file). For the *.jar files, it's simply a matter to run {JAVA_HOME}/bin/jarsigner -verify <jarname>.jar And make sure it says "jar verified". For the *.pack.gz files, you want to first execute {JAVA_HOME}/bin/unpack200 <jarname>.jar.pack.gz <jarname>-unpacked.jar (I just picked "-unpacked" as part of the name, not to overwrite, your original .. you can put then in a different directory or something too. Assuming no error messages, then the critical step is to now 'verify' the unpacked version: {JAVA_HOME}/bin/jarsigner -verify <jarname>-unpacked.jar It should also say "jar verified", but if you get an error, that it's been "tampered with", or similar, then you know that the byte codes did not survive the re-pack, sign, and pack200 process. What you pick as "JAVA_HOME" may make a difference. Our goal, is to "use what users use", so setting JAVA_HOME to a Java 8 install would be a good choice. In the "Sim. Release test" project, there are two batch files (for Linux) that I use to perform the above steps on a whole directory and produce some slightly formatted results for easier viewing. They may require modification, depending on your system, (and location of the various Java installs) but you can get them from http://git.eclipse.org/c/simrel/org.eclipse.simrel.tests.git/plain/bundles/org.eclipse.simrel.tests-bundle/verifydir.sh http://git.eclipse.org/c/simrel/org.eclipse.simrel.tests.git/plain/bundles/org.eclipse.simrel.tests-bundle/verify.sh The scripts have to be in your executable path, such as ~/bin, and then at the top of your repo directory, execute verifydir.sh. It will put the resulting resports in ~/verifydiroutput (by defautl). There's other options and "ways to do it", documented in the scripts themselves, if you want to do something slightly different. = = = = = = Since you used the "default" batch signer (Java 6) there *might* be some issues, but will be good to find out early. If issues, you have two choices: 1) do not "pack" those bundles that have problems 2) try the Java 8 transition path and see if that's any better. (It will probably be better, but pack200 is never perfect, so could still be some issues, maybe even the same issues -- in which case you still need to "not pack" those jars, or other, much more complicated options :). Hope that helps, If you do have issues, or need help with the scripts, I suggest you open a "cross-project" bug, and we'll discuss or deal with the issues there. If you have any cases of "jars already signed" (such as from Orbit), at the moment you just have to "manually" look to see if they were re-signed. They should no longer be (though would have been, in the past). I hope to add some "checksum" testing to confirm that doesn't happen, but it's not there yet. The "repo reports" are also described in https://wiki.eclipse.org/SimRel/Simultaneous_Release_Reports_FAQ and https://wiki.eclipse.org/SimRel/Simultaneous_Release_Reports_Running_Locally Just to document one interesting complication I just leaned about. Java 8 "signs" using SHA-256, as we know, AND, the first version of Eclipse (Equinox) that supported that was "Juno" (3.8/4.2, I believe). While that was the first "LTS" version, if anyone wanted to do long term support of even older versions, they will still need the "Java 6" version of the signing service. In practice, I do not think this will be an issue, and IMHO Eclipse Foundation does not even need to support it (since LTS was not "offered" before Juno). Just thought I'd make a note of here, in case it helps others doing "very long term support". Was it only last March to May we were having all this fun? Feels like 5 years ago. And even though such a short time, I have lost track, of ultimate resolution, or transition. I do not see a /shared/download-staging.priv/java8, as there was for a while (I think?) Or, was another solution found? I am partially asking, since when I look at the signing tailing log, I see things like = = = = = 2015-10-15 01:06:24: build SIGNER(4383): Signing JAR file [/opt/public/download-staging.priv/sapphire/signing/9.1.0/output/temp_repository.zip/org.eclipse.sapphire.workspace_9.1.0.201510150101.jar] with Java 6 = = = = = Notice the "with Java 6" at the end? Where's that coming from? I would have thought by now we would have moved entirely to Java 8? Why? I recently did a further Luna maintenance build. I obviously use the unchanged build in so far as possible. So I build and sign as I used to. Fortunately my build is never aggregated so the signing issues are hidden. IMHO The EF signing service should be a LTS service with at least 5 years backwards compatibility. (In reply to Ed Willink from comment #117) > Why? > > I recently did a further Luna maintenance build. I obviously use the > unchanged build in so far as possible. So I build and sign as I used to. > Fortunately my build is never aggregated so the signing issues are hidden. > > IMHO The EF signing service should be a LTS service with at least 5 years > backwards compatibility. I don't care. What I want to know is how does a user pick one or another? Where is that documented? From a quick peek I didn't see it in https://wiki.eclipse.org/IT_Infrastructure_Doc (In reply to David Williams from comment #118) > I don't care. > > What I want to know is how does a user pick one or another? Where is > that documented? > > From a quick peek I didn't see it in > https://wiki.eclipse.org/IT_Infrastructure_Doc Let me check what is the current status of CLI signing infra and I will write down my findings in https://wiki.eclipse.org/IT_Infrastructure_Doc. The usual 'sign' command still use the old Java 6 jarsigner to avoid issue that Ed and other faced when we migrated to Java 8. This change has been rollbacked and now to use Java 8 jarsigner, you have to use 'sign8' command. I updated https://wiki.eclipse.org/IT_Infrastructure_Doc with these information. I also updated https://wiki.eclipse.org/IT_Infrastructure_Doc#Web_service_.28Instant.29 to state that the webservice only sign with Java 8 and that there is no option to choose the Java version for it. I am working on bug 458597 to enhance the signing web service. It will scale better and we will have more options (re-signing strategy, digest algorithm to use to avoid bug 473402...). The CLI 'sign' / 'sign8' will eventually be deprecated. The schedule for that deprecation is not defined yet. (In reply to Mikael Barbero from comment #120) > The usual 'sign' command still use the old Java 6 jarsigner to avoid issue > that Ed and other faced when we migrated to Java 8. This change has been > rollbacked and now to use Java 8 jarsigner, you have to use 'sign8' command. literaly sign8 command? I get command not found. $ sign8 If 'sign8' is not a typo you can run the following command to lookup the package that contains the binary: command-not-found sign8 -committer_shell: sign8: command not found this is what 'sign' returns: $ sign Usage: /usr/local/bin/sign <file> <mail|nomail|now> [outputDir] [skiprepack] [notsa] Signs JAR or ZIP file <file>, placing the resulting file in optional [outputDir] and mails notification that signing is complete, if requested. You must provide one of mail,nomail or now (In reply to David Williams from comment #121) > (In reply to Mikael Barbero from comment #120) > > The usual 'sign' command still use the old Java 6 jarsigner to avoid issue > > that Ed and other faced when we migrated to Java 8. This change has been > > rollbacked and now to use Java 8 jarsigner, you have to use 'sign8' command. > > literaly sign8 command? I get command not found. > > $ sign8 > If 'sign8' is not a typo you can run the following command to lookup the > package that contains the binary: > command-not-found sign8 > -committer_shell: sign8: command not found > > this is what 'sign' returns: > > $ sign > > Usage: /usr/local/bin/sign <file> <mail|nomail|now> [outputDir] [skiprepack] > [notsa] > Signs JAR or ZIP file <file>, placing the resulting file in optional > [outputDir] and mails notification that signing is complete, if requested. > You must provide one of mail,nomail or now I see (now) in my Orbit scripts, I used an environment variable, JAR_PROCESSOR_JAVA=java8 to use Java 8, and the correct "jar_processor". Perhaps that's what you meant? Sorry about that. There are 3 signing scripts. One is /usr/local/bin/sign, another one is /home/data/users/genie/signing/sign.sh and last is /home/data/users/genie/signing/sign8.sh. I mistakenly thought that /usr/local/bin/sign was a symlink to /home/data/users/genie/signing/sign.sh and that a sign8 symlink also existed for sign8.sh. I should have checked it.
The thing is, they are all different... I will talk with Matt later today to see how and why and come back to you after.
What I can tell now, is that /usr/local/bin/sign uses java 8 with the tests below:
if [ -n "$JAR_PROCESSOR_JAVA" ]; then
echo "Batch signer is using Java 8" >> $LOGFILE
JARSIGNER="/shared/common/jdk1.8.0_x64-latest/bin/jarsigner"
else
#Check to see if the path name has java8 in it for projects that can't add extra params.
JAR_PROCESSOR_JAVA=$(echo -n "$DIR" | grep -o "java8")
if [ -n "$JAR_PROCESSOR_JAVA" ]; then
echo "Batch signer is using Java 8" >> $LOGFILE
JARSIGNER="/shared/common/jdk1.8.0_x64-latest/bin/jarsigner"
else
echo "Batch signer is using Java 6" >> $LOGFILE
JARSIGNER="/shared/common/jdk-1.6.x86_64/bin/jarsigner"
fi
fi
$DIR is set like this:
# Get directory name from file to ensure it is in the staging area
DIR=$(dirname "$1") # $1 being the path to the jar...
cd $DIR
DIR=$PWD
So I suppose you will use java 8 for signing if you put your jar to be signed in a path under "download-staging.priv" containing java8 or if you set $JAR_PROCESSOR_JAVA before calling /usr/local/bin/sign script.
But I have no idea from where does the $JAR_PROCESSOR_JAVA come from...
A question for you. I don't understand why you are still using this CLI signing infra. I thought that the platform build was done in tycho and the cbi-jarsigner-plugin and tycho-pack200a-plugin and tycho-pack200b-plugin were properly called around that.
I now understand the whole thing better: - /usr/local/bin/sign is the entry point for end-users (e.g., you) - it writes into a file (queue) the signing request - a cronjob read this queue and depending on what is written, call either sign.sh or sign8.sh. Sorry for the confusion. I think you have your reply about how to use java 8 for signing now, right? (In reply to Mikael Barbero from comment #119) > Let me check what is the current status of CLI signing infra and I will > write down my findings in https://wiki.eclipse.org/IT_Infrastructure_Doc. Can you express it in practical terms? I'm using Buckminster so I just set site.signing true. The BuckyBook only tells me it affects some internal actor... so I have absolutely no idea how I do signing or with what. site.p2 An action that creates the final p2 site. It uses the internal actor p2SiteGenerator which in turn uses the p2 publisher. The input to this action comes from the attributes manifest, product.configuration.exports, site.feature.exports, site.packed, and site.signed. Only one of the three site.«xxx» inputs will be used. Which one depends on the settings of the properties site.pack200 and site.signing such that: (In reply to Mikael Barbero from comment #123) > A question for you. I don't understand why you are still using this CLI > signing infra. I thought that the platform build was done in tycho and the > cbi-jarsigner-plugin and tycho-pack200a-plugin and tycho-pack200b-plugin > were properly called around that. Oh how I wish that the platform build was my only responsibility. Life would be easy then! Partially asking because I also build Orbit, which uses the batch signing method. But my immediate issue is I was trying to help someone else in Sim. Release figure out some problems with their packed/signed jars. (And, they use the batch processor, I think). (In reply to Ed Willink from comment #125) > (In reply to Mikael Barbero from comment #119) > > Let me check what is the current status of CLI signing infra and I will > > write down my findings in https://wiki.eclipse.org/IT_Infrastructure_Doc. > > Can you express it in practical terms? I'm using Buckminster so I just set > site.signing true. The BuckyBook only tells me it affects some internal > actor... so I have absolutely no idea how I do signing or with what. > > site.p2 > An action that creates the final p2 site. It uses the internal actor > p2SiteGenerator which > in turn uses the p2 publisher. The input to this action comes from the > attributes manifest, > product.configuration.exports, site.feature.exports, site.packed, and > site.signed. Only one of the three site.«xxx» inputs will be used. Which one > depends on > the settings of the properties site.pack200 and site.signing such that: I have absolutely no idea how does buckminster work. I suppose it calls /usr/local/bin/sign under the hood. It seems you have no way to give it any parameter so you are just fine with how it works now. It still uses java 6 for signing when you just call /usr/local/bin/sign. You should talk with the buckminster project if you want further support. (In reply to David Williams from comment #126) > (In reply to Mikael Barbero from comment #123) > > > A question for you. I don't understand why you are still using this CLI > > signing infra. I thought that the platform build was done in tycho and the > > cbi-jarsigner-plugin and tycho-pack200a-plugin and tycho-pack200b-plugin > > were properly called around that. > > Oh how I wish that the platform build was my only responsibility. Life would > be easy then! > > Partially asking because I also build Orbit, which uses the batch signing > method. > > But my immediate issue is I was trying to help someone else in Sim. Release > figure out some problems with their packed/signed jars. (And, they use the > batch processor, I think). Thanks! I was just wondering if there was something I missed in the way the platform is built ;) I changed https://wiki.eclipse.org/IT_Infrastructure_Doc#ZIP_and_JAR_files_from_the_Commandline_.28Queued.29 stating that people need to define JAR_PROCESSOR_JAVA=java8 to sign with Java 8. (In reply to Mikael Barbero from comment #129) > I changed > https://wiki.eclipse.org/ > IT_Infrastructure_Doc#ZIP_and_JAR_files_from_the_Commandline_.28Queued.29 > stating that people need to define JAR_PROCESSOR_JAVA=java8 to sign with > Java 8. Thank you! Not sure why I had trouble finding/remembering the solution. Thanks for tracking it down. ECF is struggling with the build as well also with Buckminster. Scott posted this on bug 487087 but I think it is more appropriate here: Scott Lewis said: "I've been experimenting with our external/existing builder and I have some information that may help diagnose. First, we've upgraded java8, buckminster, and jenkins. I've learned through experimentation that if I move back our usage of Orbit repo to the one we used for Mars version: R20150124073747 url: http://download.eclipse.org/tools/orbit/downloads/drops/R20150124073747/repository/ Then our build completes successfully. If, however, I change to use the Mars.2 Orbit release repo: version: R20151221205849 url: http://download.eclipse.org/tools/orbit/downloads/drops/R20151221205849/repository/ Then our build fails immediately *after* using the signing service, and it fails with an SHA256 error: org.eclipse.core.runtime.CoreException: java.lang.SecurityException: SHA-256 digest error for org/apache/http/client/cache/HttpCacheEntry.class at org.eclipse.buckminster.runtime.BuckminsterException.fromMessage(BuckminsterException.java:57) at org.eclipse.buckminster.runtime.BuckminsterException.wrap(BuckminsterException.java:123) at org.eclipse.buckminster.core.actor.AbstractActor.perform(AbstractActor.java:205) at org.eclipse.buckminster.core.internal.actor.PerformManager$DirectActionInvocation.execute(PerformManager.java:143) at org.eclipse.buckminster.core.internal.actor.PerformManager.internalPerform(PerformManager.java:454) at org.eclipse.buckminster.core.internal.actor.PerformManager.perform(PerformManager.java:293) at org.eclipse.buckminster.core.internal.actor.PerformManager.perform(PerformManager.java:305) at org.eclipse.buckminster.core.commands.Perform.internalRun(Perform.java:108) ... If I use the Neon.M5 stable repo version: S20151204220443 url: http://download.eclipse.org/tools/orbit/downloads/drops/S20151204220443/repository/ Then things also fail with SHA-256 digest error (with same httpclient class) as before. To summarize, it seems the more recent Orbit repo contents (httpclient/httpcomponents bundles) fail in our Buckminster job with this security error after the remote signing service is done and the zip has been retrieved back to our builder. Any thoughts appreciated." (In reply to Wim Jongman from comment #131) > First, we've upgraded java8, buckminster, and jenkins. I don't think that 100% of the infrastructure was ready for Java 8 in Mars, so advancing to Java 8 for legacy seems unwise. Use Java 7 for Mars builds. (AFAIAA there is no Buckminster 4.4.2). (In reply to Mikaël Barbero from comment #124) > I now understand the whole thing better: > > - /usr/local/bin/sign is the entry point for end-users (e.g., you) > - it writes into a file (queue) the signing request > - a cronjob read this queue and depending on what is written, call either > sign.sh or sign8.sh. > > Sorry for the confusion. I think you have your reply about how to use java 8 > for signing now, right? From wiki : https://wiki.eclipse.org/IT_Infrastructure_Doc#ZIP_and_JAR_files_from_the_Commandline_.28Queued.29 ... Move the file to be signed to a path that contains the string java6, java7 or java8 (e.g. /shared/download-staging.priv/path/to/your/project/java8/tobesigned.jar). It doesn't seem to work any more. cat /usr/local/bin/sign doesn't have the ntry: JAR_PROCESSOR_JAVA=$(echo -n "$DIR" | grep -o "java8") (In reply to Dennis Huebner from comment #133) > It doesn't seem to work any more. cat /usr/local/bin/sign doesn't have the > ntry: > JAR_PROCESSOR_JAVA=$(echo -n "$DIR" | grep -o "java8") On which machine did you do the cat /usr/local/bin/sign? fyi, the signing script has been revamped some times ago and is now available in CBI git repo (http://git.eclipse.org/c/cbi/org.eclipse.cbi.git/tree/cli-tools/signing/jar). (In reply to Mikaël Barbero from comment #134) > (In reply to Dennis Huebner from comment #133) > > It doesn't seem to work any more. cat /usr/local/bin/sign doesn't have the > > ntry: > > JAR_PROCESSOR_JAVA=$(echo -n "$DIR" | grep -o "java8") > > On which machine did you do the cat /usr/local/bin/sign? fyi, the signing build.eclipse.org > script has been revamped some times ago and is now available in CBI git repo > (http://git.eclipse.org/c/cbi/org.eclipse.cbi.git/tree/cli-tools/signing/ > jar). That's maybe be good. But my problem remains, I can't use java8 signing for: https://hudson.eclipse.org/xtext/job/emf-xcore/ As staging folder I've tried both: /shared/download-staging.priv/modeling/emf/xcore/java8 and /shared/download-staging.priv/modeling/java8/emf/xcore Signer log still prints: it is using java 6 Can you please check that the environment that starts /usr/local/bin/sign (the one that buckminster uses, not the one defined by your hudson script) does not contain a variable JAR_PROCESSOR_JAVA set to java6. It is the only reason why line 160 and 161 of http://git.eclipse.org/c/cbi/org.eclipse.cbi.git/tree/cli-tools/signing/jar/sign#n160 could return java6 (I just tried out manually). Also, try to update to latest buckminster version and see how it goes. Thanks. (In reply to Mikaël Barbero from comment #136) > Can you please check that the environment that starts /usr/local/bin/sign > (the one that buckminster uses, not the one defined by your hudson script) > does not contain a variable JAR_PROCESSOR_JAVA set to java6. It is the only > reason why line 160 and 161 of IMHO folder name should have priority over JAR_PROCESSOR_JAVA env var Thanks for clarification, Mikaël. (In reply to Dennis Huebner from comment #137) > IMHO folder name should have priority over JAR_PROCESSOR_JAVA env var The priority order has been defined like that when the feature has been added. The CLI signing service is very delicate and I did not want to break anyone already relying on this behavior > Thanks for clarification, Mikaël. You're welcome! (In reply to Mikaël Barbero from comment #136) > Also, try to update to latest buckminster version and see how it goes. Are you aware that the 'latest' Buckminster is for Mars? PMI shows only 4 commits in the last year, all in March 2016. Use of Buckminster is becoming quite difficult since post Mars JDT changes cannot be used. (In reply to Ed Willink from comment #139) > (In reply to Mikaël Barbero from comment #136) > > Also, try to update to latest buckminster version and see how it goes. > > Are you aware that the 'latest' Buckminster is for Mars? PMI shows only 4 > commits in the last year, all in March 2016. Use of Buckminster is becoming > quite difficult since post Mars JDT changes cannot be used. Yes, I am. I was giving this advice specifically to Dennis because his build runs with Buckminster 4.3 (IIRC, Kepler). |