Bugzilla – Full Text Bug Listing
| Summary: | 5 Projects not yet signing: Galileo M7 unsigned jars | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Community | Reporter: | David Williams <david_williams> | ||||
| Component: | Cross-Project | Assignee: | David Williams <david_williams> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | alex.panchenko, mtaal, oisin.hurley, remy.suen, thomas | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
David Williams
> org.eclipse.stp.*
This is surprising.
We've been signing jars for the last two years, and I personally watched
the jarsigner (using tail) process the jars for our build this time around
(it's a bad habit of mine).
So, I'm not sure why they don't appear to be signed. What method
did you use to check for signage?
Created attachment 135082 [details]
full list of jars not signed
I've attached the full list in case anyone wants/needs the details.
As for method use, I have a shell script that get's the list of jars and jar.pack.gz files at /releases/galileo. For the pack.gz files I unpack200 them to tmp first, and then verify with <java 5>jarsigner -verify.
> org.eclipse.dltk.*
We sign milestone builds, but I had not checked the M7 files after some build system related changes.
I confirmed that the STP jars are being signed, but the jarsigner verification fails jarsigner: java.lang.SecurityException: Invalid signature file digest for Manifest main attributes I recognize this as an indication that the jar has been altered somehow after the signing has happened, but I've no idea where the alteration may be occurring. I'll need to look into it in more detail. (In reply to comment #4) > > I recognize this as an indication that the jar has been altered somehow after > the signing has happened, ... > Maybe not. You use Buckminster build, right? There was a bug in their jar processor "until the last minute" that effected those manifest file signatures. See bug 275528. It was particularly insidious bug because some jar verifiers report it as "ok" (e.g. from 1.4 JDKs or the OSGi Signature Verifier). It may have been your jars were produced before first bug fixed and it wasn't detected because of the second bug. Feel free to re-try and re-submit early for RC1 if you want to check that it's now fixed (after you get the latest from Buckminster). (In reply to comment #5) > Maybe not. You use Buckminster build, right? There was a bug in their jar > processor "until the last minute" that effected those manifest file signatures. > See bug 275528. It was particularly insidious bug because some jar verifiers > report it as "ok" (e.g. from 1.4 JDKs or the OSGi Signature Verifier). > > It may have been your jars were produced before first bug fixed and it wasn't > detected because of the second bug. You got it - that was the issue. I've updated the jarprocessor and verified that the signing worked correctly. I remember that bug going by and somewhere in my head I had convinced myself I had updated my cached buckminster install. Turned out I hadn't. I'll update the stp.build with the new build later today. Hi David, I checked out the teneo.hibernate.libraries plugin you mention below. As you can see it is an old plugin (june last year). Somehow this plugin get's drawn in from somewhere, I don't know from where and I don't know why. I publish more recent builds for Galileo (ofcourse). This plugin is also mentioned in this recent issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=275839 Here is a snippet from this issue, maybe you know someone who can give some more insight on how p2 functions here (if it is even p2...): >>>>>>>>>>>>>>>>>>>>>>>>>> CDO has some optional dependencies on org.hibernate packages. I expected these to be unsatisfied, but that does not harm since they're optional. BUT: Somehow p2 discovered a very old version of a bundle in a p2 repository (no idea where). This is the org.eclipse.emf.teneo.hibernate.libraries_1.0.0.v200806111928 bundle that I mentioned before. This bundle is really harmful because it not only exports numerous packages but it does not even contain these packages. It was meant as an empty wrapper for some teneo/hibernate libraries. And IIRC it was abandoned because it was considered harmful (Martin, correct me if I'm wrong). Teneo itself does not seem to use it anymore. To be clear: CDO does not use it either! But somehow p2 finds this bundle and decides that it can be used to satisfy CDO's *optional* hibernate dependencies. I would say it's not the fault of CDO that p2 uses old (and malicious) bundles to satisfy optional dependencies. It's not the fault of CDO that this old bundle exports ant packages. It's not the fault of CDO that the Ant core plugin uses strange mechanisms so that it relies on nobody exporting ant packages. <<<<<<<<<<<<<<<<<<<<<<<<<<< gr. Martin (In reply to comment #7) > Hi David, > I checked out the teneo.hibernate.libraries plugin you mention below. As you > can see it is an old plugin (june last year). > > Somehow this plugin get's drawn in from somewhere, I don't know from where and > I don't know why. I publish more recent builds for Galileo (ofcourse). > Hm, that is interesting! Perhaps someone else is using it? Pulling it in? But, to be clear, P2 will pull in optional dependencies if it can find them (as far as I know) and it does not have to be named in a feature (as far as I know) but just named in a manifest. So, I assume you are saying this bundle is not on _your_ update site/repo at all? If that's the case, then I guess someone else is "contributing" it. Thomas, do you have any ideas, from your builder point of view, on how it deals with optional bundles, or how much effort it might make to find them? I guess we can find who "references it" from a complete install. Thanks for investigating, Martin. To add some more info: Maybe it is present on an update site for an earlier release of Eclipse (Ganymede looking at the date), but not for Galileo. This is a bit of a special plugin it is empty (no code and no jars), it is only used during testing during the build. It is included to ensure that the Teneo test plugins are installable. But it is not part of an sdk or runtime feature. I will research if I can completely remove it in rc1. However, this won't help if p2 (something else?) can pull old versions from other places. gr. Martin following current issues in bug 279369 |