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.
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.