0

can anybody help me?

I would like to use osgi security in my application. Therefore i wrote a security bundle, that grant all bundles that was signed by my keystore. One of my bundles is a war file (Bundle10). If i start the server (glassfish with felix) on which i deployed the war bundle, i get a java.lang.SecurityException:

Exception while processing WEB-INF/classes/com/xy/SomeClass.class inside 
file:/tmp/osgiapp430591893594363740/WEB-INF/lib/Bundle10.jar of size 2.111

java.lang.SecurityException: Invalid signature file digest for Manifest main attributes
at sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:221)
at sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:176)
at java.util.jar.JarVerifier.processEntry(JarVerifier.java:288)
at java.util.jar.JarVerifier.update(JarVerifier.java:199)
at java.util.jar.JarFile.initializeVerifier(JarFile.java:327)
at java.util.jar.JarFile.getInputStream(JarFile.java:395)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.getEntry(InputJarArchive.java:244)
at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.handleEntry(ReadableArchiveScannerAdapter.java:166)
at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:133)
at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:348)
at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:70)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:307)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:296)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)

I signed the bundle with the maven jasigner plugin.

bg89
  • 1
  • 4
  • i get the exception for every class in WEB-INF/classes/, but the application runs without any problems. – bg89 Oct 07 '13 at 11:57

2 Answers2

0

The exception tells you that the digest in signers.sf for the manifest main section is incorrect. This is the section that contains the OSGi metadata. So it almost looks like this WAR was turned into a bundle after it was signed?

Signing is quite complicated. The manifest contains 2 sections, a main section and a section per resource in the jar. Each of these resource sections start with the Name: attribute identifying the path to the resource. When you want to sign a JAR you first create a manifest and a resource section for each attribute, where the resource section contains one or more digests (SHA, MD5, etc) of the resource.

You can have multiple signers so you have to pick a name for each signature file. In this signature file you again have a main section and a number of resource sections. In the main section you must have one or more of the

X-Digest-Manifest-Attributes: <X digest of manifest main section>

The X can again be one of the digest algorithms used. The resource sections in the manifest must contain the digest of the corresponding resource section in the manifest (not the resource!).

      MANIFEST.MF               <>.SF
      +--------------+  
 Main |Bundle-Sym .. |    <---  X-Digest-Manifest-Main-Attributes: 345678...
      |Bundle-Vers.. |   
      +--------------+ 
 Name |Name: a.class |    <---  Name: a.class
      |X-Digest: 56A5|          X-Digest:  4789...
      +--------------+
      |Name: b.class |    <---  Name: b.class
      |X-Digest: ACE |          X-Digest:   65123...
      +--------------+

In short, your main manifest section is not properly signed. You are either missing the -Digest-Manifest-Main-Attributes in your <>.SF file or it was (likely) calculated before you calculated the OSGi headers.

If you're using bnd, you can sign the bundle directly from bnd.

Peter Kriens
  • 15,196
  • 1
  • 37
  • 55
0

The problem is caused by the GlassFish WAB installation process. If the WAB contains loose class files in the WEB-INF/classes directory, they are packaged into a new JAR file. This breaks the signature.

In my opinion this is a GlassFish bug. I have created a GlassFish bug ticket: https://java.net/jira/browse/GLASSFISH-20861

Workaround: Package your loose class files into a JAR file and put it into the WEB-INF/lib directory. Then add the JAR file to the Bundle-ClassPath MANIFEST.MF entry.

Jochen Kraushaar
  • 1