xerces-xml-commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Crossley (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (XMLCOMMONS-90) Invalid manifest section in resolver JAR
Date Fri, 04 Nov 2016 04:57:58 GMT

    [ https://issues.apache.org/jira/browse/XMLCOMMONS-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15635251#comment-15635251

David Crossley commented on XMLCOMMONS-90:

Moved from Apache XML to Apache Xerces sometime in late 2006:

> 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

To unsubscribe, e-mail: xml-commons-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: xml-commons-dev-help@xerces.apache.org

View raw message