Wrong statement suspected in jar.html
philipp.kunz at paratix.ch
Tue Dec 25 09:27:01 UTC 2018
Your proposed sentence looks good to me. Certainly better than removing
it. Two points that could hardly be less important:
I'm not native English but the word "resign" came to my attention. A
look into a dictionary told me it already has a meaning completely
unrelated to signing. Would a hyphen help as in "re-sign"? Or maybe
something like "signed again afterwards"? It might have struck me as
You may be right about referring to main attributes as manifest header
but I did not find such a definition or explanation in
To some extent the way it is now, I still think, in my opinion, the
term "header" in "non-header section" is ambiguous and confusing.
On Tue, 2018-12-25 at 08:37 +0800, Weijun Wang wrote:
> More precisely, it should be something like:
> If the JAR file is resigned by a different signer after new files
> were added, the manifest file is changed (sections are added to it
> for the new files) and a new signature file is created, but the
> original signature file is unchanged.
> According to spec of Manifest, the "header" is called the main
> attributes and all the others manifest entries.
> And yes, this is the correct mail list to talk about this issue. I
> also have no idea where the source of that tooldoc is. Someone on the
> list should know.
> > On Dec 25, 2018, at 6:42 AM, Philipp Kunz <philipp.kunz at paratix.ch>
> > wrote:
> > Hi,
> > https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#signature
> > -val
> > idation says:
> > When the jar tool is used to add files, the manifest file is
> > changed
> > (s
> > ections are added to it for the new files), but the signature file
> > is
> > n
> > ot.
> > It appears to me that using the jar tool to add files to a jar file
> > does not change the jar manifest. The jar manifest is changed by
> > the
> > jarsigner tool when signing the jar.
> > I haven't found the sources of that referenced jar.html and
> > therefore
> > I'm not sure whether my concern still currently applies or has been
> > fixed since JDK 10.
> > I'm also not sure where and how to report this issue. I'd be glad
> > if
> > someone could point me to the right place or forward this message
> > accordingly.
> > A suggested alternative for the sentence in question might be to
> > delete
> > it without replacement. In my opinion, the remaining text would
> > look
> > fine like this:
> > One reason the digest value of the manifest file that is stored in
> > the
> > x-Digest-Manifest attribute may not equal the digest value of the
> > current manifest file is that one or more files were added to the
> > JAR
> > file (using the jar tool) after the signature (and thus the
> > signature
> > file) was generated. A verification is still considered successful
> > if
> > none of the files that were in the JAR file when the signature was
> > generated have been changed since then, which is the case if the
> > digest
> > values in the non-header sections of the signature file equal the
> > digest values of the corresponding sections in the manifest file.
> > When at it already, let me mention that I'm not entirely sure if
> > the
> > term "non-header sections" fits the context optimally. What about
> > "individual sections" or "source file information sections"
> > instead?
> > Philipp
More information about the core-libs-dev