RFR: 8215788: Clarify JarInputStream Manifest access [v6]
Weijun Wang
weijun at openjdk.org
Mon Sep 19 20:34:46 UTC 2022
On Mon, 19 Sep 2022 17:53:51 GMT, Lance Andersen <lancea at openjdk.org> wrote:
>>> I can remove, but I am not sure I agree we need to describe main vs attribute here given we are pointing to the Jar spec and if there is any discussion of Pre-entry attributes, it should be in JarEntry IMHO. I guess the clarification I was trying to make, apparently unsuccessfully is that `JarEntry` will not have access to the attributes if `getManifest` does not return the Manifest.
>>
>> Wording it is hard. The draft wording made it look that must call getManifest, ignore the return value, and then subsequent calls to JarEntry::getAttributes will return attributes for the JAR file entry. I think to properly describe would require more setup to explain that a manifest can optionally include per entry attributes and these are read with JarEntry::getAttributes when the manifest is found at the beginning of the stream..
>
>> > I can remove, but I am not sure I agree we need to describe main vs attribute here given we are pointing to the Jar spec and if there is any discussion of Pre-entry attributes, it should be in JarEntry IMHO. I guess the clarification I was trying to make, apparently unsuccessfully is that `JarEntry` will not have access to the attributes if `getManifest` does not return the Manifest.
>>
>> Wording it is hard. The draft wording made it look that must call getManifest, ignore the return value, and then subsequent calls to JarEntry::getAttributes will return attributes for the JAR file entry. I think to properly describe would require more setup to explain that a manifest can optionally include per entry attributes and these are read with JarEntry::getAttributes when the manifest is found at the beginning of the stream..
>
> Thinking about this some more, would the following be any better:
>
>
> * <p>
> * The {@code Manifest} for a JAR file may include
> * <a href="{@docRoot}/../specs/jar/jar.html#main-attributes">main</a> and
> * <a href="{@docRoot}/../specs/jar/jar.html#per-entry-attributes">per entry</a>
> * attributes. {@link JarEntry#getAttributes()} will return the per entry
> * attributes for the current JAR file entry, if any, providing
> * {@code getManifest()} returns the {@code Manifest} for the JAR file.
> * </p>
Does this mean that the "Verifying a JarInputStream" should also avoid mentioning "getManifest method returns the manifest"? I understand precisely it should be "getManifest method is able to return the manifest if you call it".
It almost sounds like we should first define the concepts of "well-formed JAR file" and "well-formed signed JAR" and then specify what these methods behave.
-------------
PR: https://git.openjdk.org/jdk/pull/10045
More information about the security-dev
mailing list