As has been planned, the latest I-builds are now all signed ... both our own bundles and the third party ones, coming from Orbit. See for example or WTP build of I20080224222938 or later.
If you ever want to confirm a jar is signed, you can peek in the manifest.mf file of a jar file, and you should see a bunch of SHA signatures in there, one for each file. If you ever want to confirm the signing is correct ... you can use the jarsigner.exe program (that comes with SDKs) to verify a jar, such as jarsigner -verify <jar file> You may want to test WTP builds a little more than usual this week, or a little earlier than usual, and make sure there are no obvious problems, or severe performance impacts. See http://wiki.eclipse.org/JAR_Signing#What_effect_does_signing_have_on_runtime_behaviour.3F for information and possible courses of actions for performance impacts. There are two I think might effect code in WTP: Class loaders may perform verification when they encounter signed content. Since verification is potentially expensive, this can impact performance. In particular, URLClassLoader and any subclasses will always verify any JAR from which classes are loaded if they contain a signature. By contrast, the class loaders used by OSGi will not perform verification by default. Therefore this does not impact most typical Eclipse/OSGi code, but may affect code that uses custom class loaders. java.util.jar.JarFile will verify jars unless explicitly configured not to. The JarFile constructors have an optional boolean parameter to configure whether verification should be performed. The simple constructors, such as JarFile(File) and JarFile(String), will perform verification. This can have a performance impact when dealing with signed jars. This is one of the "must do" items for Ganymede, and is an important step forward in Eclipse joining the modern world of secure programming. Thanks,
_______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
