0

誰でも私を助けることができますか？

アプリケーションで osgi セキュリティを使用したいと考えています。したがって、キーストアによって署名されたすべてのバンドルを許可するセキュリティ バンドルを作成しました。私のバンドルの 1 つは war ファイル (Bundle10) です。war バンドルをデプロイしたサーバー (glassfish with felix) を起動すると、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)

Maven jasigner プラグインでバンドルに署名しました。

4

2 に答える 2

0

この例外は、マニフェストのメイン セクションの signers.sf のダイジェストが正しくないことを示しています。これは、OSGi メタデータを含むセクションです。では、この WAR は署名後にバンドルになったように見えますか?

署名は非常に複雑です。マニフェストには、メインセクションと jar 内のリソースごとのセクションの 2 つのセクションが含まれています。これらの各リソース セクションは、リソースへのパスを識別する Name: 属性で始まります。JAR に署名する場合は、最初に各属性のマニフェストとリソース セクションを作成します。リソース セクションには、リソースの 1 つ以上のダイジェスト (SHA、MD5 など) が含まれます。

複数の署名者を持つことができるため、署名ファイルごとに名前を選択する必要があります。このシグネチャ ファイルにも、メイン セクションと多数のリソース セクションがあります。メイン セクションには、1 つ以上の

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

X は、使用されるダイジェスト アルゴリズムの 1 つです。マニフェストのリソース セクションには、マニフェストの対応するリソース セクションのダイジェストが含まれている必要があります (リソースではありません!)。

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

つまり、メインのマニフェスト セクションが適切に署名されていません。<>.SF ファイルに -Digest-Manifest-Main-Attributes がないか、(おそらく) OSGi ヘッダーを計算する前に計算されました。

bnd を使用している場合は、bnd から直接バンドルに署名できます。

于 2013-10-07T12:42:08.760 に答える
0

この問題は、GlassFish WAB のインストール プロセスが原因で発生します。WAB の WEB-INF/classes ディレクトリにルース ク​​ラス ファイルが含まれている場合、それらは新しい JAR ファイルにパッケージ化されます。これにより、署名が壊れます。

私の意見では、これは GlassFish のバグです。GlassFish バグ チケットを作成しました: https://java.net/jira/browse/GLASSFISH-20861

回避策: ルーズ クラス ファイルを JAR ファイルにパッケージ化し、WEB-INF/lib ディレクトリに配置します。次に、JAR ファイルを Bundle-ClassPath MANIFEST.MF エントリに追加します。

于 2013-10-18T12:49:55.087 に答える