| Signature verification issues with pack200 [message #535244] |
Fri, 21 May 2010 17:33 |
 Kate Glickman
Messages: 3
Registered: July 2009 |
Junior Member |
|
|
I tried to run pack200 on a directory of plugins which contains inner jars. None of the plugins contain eclipse.inf files before this process.
This is the sequence of actions I took:
1. Normalized the whole directory using these commands:
set ECLIPSE_LAUNCHER=C:\Eclipse3.4.2\eclipse\plugins\org.eclipse .equinox.launcher_1.0.101.R34x_v20081125.jar
c:\Java50\bin\java -jar %ECLIPSE_LAUNCHER% -application org.eclipse.update.core.siteOptimizer -jarProcessor -processAll -repack -verbose -outputDir c:\plugin_dir c:\plugin_dir
2. Unjarred each plugin jar, signed the inner jars (not using jarProcessor), re-jarred each plugin jar.
3. Packed the directory using the same command as above but with pack instead of repack.
This seemed to work fine and when I unpacked the directory and ran jarsigner -verify on the resulting jars, all looked good. However, we have a unit test that uses org.eclipse.osgi.signedcontent.SignedContentFactory to compare the digests of the files in the outer jar with the digest that is written into the manifest of the outer jar and those tests were failing on the inner jars. Also, when I did a binary diff of the unpacked jars with the never packed jars, the inner jars showed up as not matching, but then when I drilled into the jars and diffed, they did match.
Here's the unit test:
private void checkBundle( Bundle b ) throws Exception
{
final String _method = "checkBundle";
SignedContentFactory scf = Activator.getSignedContentFactory();
List<String> signedList = new ArrayList<String>();
try {
SignedContent sc = scf.getSignedContent( b );
SignedContentEntry[] entries = sc.getSignedEntries();
boolean failures = false;
for (SignedContentEntry entry : entries ) {
signedList.add( entry.getName() );
try {
entry.verify();
} catch (Throwable t) {
logger.logp( Level.SEVERE, CLASSNAME, _method, "Signature verification failed for " + b.getSymbolicName() + ":" + entry.getName(), t );
failures = true;
}
}
if (failures) {
throw new Exception( b.getSymbolicName() + " has been modified after signing" );
}
} catch (Throwable t) {
logger.logp( Level.SEVERE, CLASSNAME, _method, "Signature verification failed for " + b.getSymbolicName(), t );
throw new Exception( b.getSymbolicName() + " has been modified after signing" );
}
}
We had a theory that the problem was that the signing of the inner jars was somehow invalidating the normalization that had already been done on the outer jars and so change the sequence to work like this instead:
1. Unjar the outer jars.
2. Normalize and sign the inner jars
3. rejar the outer jars
4. normalize and sign the outer jars
5. pack the whole directory
This procedure got rid of the problem with the junit test failing. However, for one particular inner jar (out of many) the second normalization of the inner jar (caused by the recursive normalization of the outer jar) causes the signature of the inner jar to get corrupted on one of the class files.
So, I have several questions:
1. In my first scenario, why would the signature verification unit test fail when jarsigner -verify succeeded? Was my methodology wrong and it is true that the signing of the inner jar was unnormalizing the outer jar?
2. In my second scenario, does it seem likely that there is a bug in the normalization that is just being hit by that particular jar or is my methodology wrong and I need to generate a pack.properties file to avoid re-normalizing the inner jar? (This doesn't really make sense to me since it seems to defeat the purpose of the -repack being recursive.)
Thank you very much for you insight.
Kate Glickman
|
|
|
Powered by
FUDForum. Page generated in 0.03199 seconds
] 
Search
Help
Register
Login
Home
