Manifest Related Bugs JDK-6372077, JDK-6202130, JDK-8176843, JDK-4842483, JDK-6443578, JDK-6910466, JDK-4935610, and JDK-4271239
Sean Mullan
sean.mullan at oracle.com
Thu Oct 12 20:32:46 UTC 2017
Hi Phillip,
All of these bugs are in the core-libs area, so I am copying the
core-libs-dev list since that is where they should be discussed and
reviewed. I have -bcc-ed security-dev (where this was originally posted).
--Sean
On 10/2/17 1:24 PM, Philipp Kunz wrote:
> Hi,
>
> While fixing JDK-6695402 I came across other related bugs to manifests
> such as JDK-6372077, JDK-6202130, JDK-8176843, JDK-4842483, and
> JDK-6443578 which all relate to manifest reading and writing. Somewhere
> bug 7071055 is mentioned but I cannot find anywhere. Another group of
> bugs, JDK-6910466, JDK-4935610, and JDK-4271239 concern the mandatory
> manifest main attributes Manifest-Version or Signature-Version and at
> first glance are duplicates. If you know of more known bugs, not
> necessarily present in jira, I'd be glad to get notified.
>
> There are also some comments about utf handling and line breaking in the
> code of Manifest:
> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Attributes.java#l299
> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Attributes.java#l327
> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Attributes.java#l370
>
> Furthermore, Attributes.map should declare appropriate type parameters:
> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Attributes.java#l61
> The specification would also require that `header names must not start
> with _, - or "From"`
> (http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Section-Specification)
> but I would opt not to add this as a hard restriction because I guess it
> can be assumed that such names are in use now after having been working
> for years. A warning to a logger might be conceivable such as in
> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Attributes.java#l424
> Attribute values are never checked at all and invalid characters such as
> line breaks are never detected except that when reading the manifest
> again the values are cut off.
> The tab character (U+0008) does not work in manifest values.
> I suspect that there are also issues regarding the iteration order but I
> haven't got a prove yet unlike for the other points above:
> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Manifest.java#l54
> There is duplicated or very similar code in Attributes and Manifest:
> Attributes.write-Manifest.write-Attributes.writeMain and
> Attributes.read-Manifest.read.
> Resolving JDK-6202130 would have the additional benefit to be able to
> view manifests with any utf-8 capable editor even if multi-byte
> characters break across lines.
>
> Fixing these issues individually looks like more complicated work than
> fixing them all at once, I guess, also because of a very low current
> test coverage. So I'd suggest to add some thorough tests along with
> fixing these issues. But before I start I would like to get some
> guidance, assistance or at least confirmation on how to proceed. I'm new
> to open jdk and have submitted only one patch so far.
>
> Is it ok to add tests for things that have worked before?
> Is it ok to refactor duplicated code just for the added value to reduce
> effort for testing?
> I assume compatibility to and from existing manifests is the highest
> priority, correct? This would also be the hard part in adding as
> complete test coverage as possible. What would be acceptable criteria to
> meet?
> Why does Attributes not extend LinkedHashMap and why does Manifest not
> extend HashMap? Any objection?
> While I would not want to write code that looks slow or change more than
> necessary one can never know before having performance actually
> measured. Is there some way this is dealt with or should I wait for such
> feedback until after patch submission?
>
> Would someone sponsor?
>
> Regards,
> Philipp
>
>
>
>
> ------------------------------------------------------------------------
>
>
>
> Paratix GmbH
> St Peterhofstatt 11
> 8001 Zürich
>
> +41 (0)76 397 79 35
> philipp.kunz at paratix.ch <mailto:philipp.kunz at paratix.ch>
More information about the core-libs-dev
mailing list