[
https://issues.apache.org/jira/browse/XMLCOMMONS-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15613744#comment-15613744
]
Björn Kautler commented on XMLCOMMONS-90:
-----------------------------------------
Well the code at least is still present at
http://svn.apache.org/repos/asf/xerces/xml-commons/, but last commit was 2
years, 9 months ago
> Invalid manifest section in resolver JAR
> ----------------------------------------
>
> Key: XMLCOMMONS-90
> URL: https://issues.apache.org/jira/browse/XMLCOMMONS-90
> Project: XML Commons
> Issue Type: Bug
> Affects Versions: XML Commons Resolver 1.2.0
> Reporter: Björn Kautler
>
> In the {{MANIFEST.MF}} of your {{resolver}} JAR you have a section
> {{org/apache/xml/resolver}}.
> This violates the JAR specification.
> A section in the manifest always refers to an entry in the JAR.
> If you have sections in the manifest that do not refer to an entry in the
> JAR, it is assumed that the JAR was tampered with as there are entries
> missing that are referenced in the manifest.
> Please fix this manifest entry to be correctly called
> {{org/apache/xml/resolver/}}.
> ----
> In my concrete use-case this happened with other JARs with invalid manifest
> entries:
> - I have signed those JARs and included them in a WebStart application
> - I started the application with 8u102 32-bit {{javaws}}
> - The JARs were downloaded and their entries signatures verified
> - As there were entries in the manifest that are not present in the JAR, the
> file was not seen as completely signed with one signature, but Java
> remembered for each entry with which signature it was signed
> This already is not too nice as it slows down the application as now for each
> class that gets loaded the signature has to be retrieved from a map and a
> list instead of having just one signature for all entries. But it gets much
> worse:
> - The acutal application was to be executed with 8u102 64-bit, so the 32-bit
> one wrote its session information out into files, including the information
> about verified JARs and also their entries if needed, and starts the 64-bit
> JVM
> - The 64-bit JVM loads this session information and thus does not have to do
> the time-consuming verification of the JARs all over again
> - Unfortunately since 8u91 or so there is a bug in this session reading and
> writing algorithm, so that some of the entry names get crippled with
> additional characters in-between
> - If now a class should be loaded that has such a crippled entry in the
> JAR-entry-to-signature map, the entry is not found and the class is
> considered as not signed which will block the application from further
> execution
> Of course this second part is a bug in Java, but it would work flawlessly if
> the JARs would not have invalid sections.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
