[
https://issues.jboss.org/browse/CDI-641?page=com.atlassian.jira.plugin.sy...
]
Laird Nelson commented on CDI-641:
----------------------------------
Where in the manifest specification does it state that per-entry attributes must have a
corresponding jar file entry?
I read this:
bq. Per-entry attributes apply only to the individual JAR file entry to which the manifest
entry is associated with.
Rephrased so it is valid English:
bq. Per-entry attributes apply only to the individual JAR file entry with which the
manifest entry is associated.
Then a {{Build-Info}} manifest per-entry attribute would apply only to a {{Build-Info}}
jar file entry. Let us suppose that no such entry exists. Does this render the
{{Build-Info}} per-entry attribute invalid? I don't read it that way. I read this as
saying only: the {{Build-Info}} per-entry attribute _would_ apply to a jar file entry
named {{Build-Info}}, but since no such entry exists, this per-entry attribute has
undefined behavior, which is of course exactly what it's being used for at the
moment.
(I have no stake in the presence or absence of this particular per-entry attribute, nor in
this bug. I just want to make sure that I am properly understanding the manifest
specification in this regard.)
Invalid manifest section in cdi-api JAR
---------------------------------------
Key: CDI-641
URL:
https://issues.jboss.org/browse/CDI-641
Project: CDI Specification Issues
Issue Type: Bug
Components: Packaging and Deployment
Affects Versions: 1.0, 2.0-EDR2
Reporter: Björn Kautler
In the {{MANIFEST.MF}} of your {{cdi-api}} JAR you have a section {{Build-Information}}.
This violates that 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 either remove this section and include the entries in that secion in the main
section which is according to the specification or include a file called
{{Build-Information}} at the root of your JAR file.
----
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
(v7.2.2#72004)