Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8271286

jarsigner doc is not precise when describing jar file re-signing

    XMLWordPrintable

    Details

    • Type: CSR
    • Status: Closed
    • Priority: P4
    • Resolution: Approved
    • Fix Version/s: 8-pool, 11-pool, 17
    • Component/s: docs
    • Labels:
      None
    • Subcomponent:
    • Compatibility Risk:
      minimal
    • Compatibility Risk Description:
      No new behavior change. Just fix the error in the doc to be consistent with the actual behavior.
    • Interface Kind:
      Other
    • Scope:
      JDK

      Description

      Summary

      Update the jarsigner doc to be more precise and clear.

      Problem

      The text (as shown in the spec below) says it is the jar tool that modified the manifest but actually it's jarsigner.

      Solution

      See spec.

      I also take this chance to make the text more clear by adding some new and original words and rewrite some sentences.

      Specification

      diff --git a/closed/src/jdk.jartool/share/man/jarsigner.md b/closed/src/jdk.jartool/share/man/jarsigner.md
      index a3de42272bdfa3ef30b4db55d9b7b1be9413dc23..c003b3168dbf73532cc2cdd42ea7db748e09704b 100644
      --- a/closed/src/jdk.jartool/share/man/jarsigner.md
      +++ b/closed/src/jdk.jartool/share/man/jarsigner.md
      @@ -379,15 +379,18 @@ have changed since then. JAR file verification involves the following steps:
           Signature File.
      
           One reason the hash of the manifest file that is stored in the `.SF` file
      -    header might not equal the hash of the current manifest file is that one or
      -    more files were added to the JAR file (with the `jar` tool) after the
      -    signature and `.SF` file were generated. When the `jar` tool is used to add
      -    files, the manifest file is changed by adding sections to it for the new
      -    files, but the `.SF` file isn't changed. A verification is still considered
      -    successful when none of the files that were in the JAR file when the
      -    signature was generated have been changed since then. This happens when the
      -    hashes in the non-header sections of the `.SF` file equal the hashes of the
      -    corresponding sections in the manifest file.
      +    header might not equal the hash of the current manifest file is that it
      +    might contain sections for newly added files after the file was signed. For
      +    example, suppose one or more files were added to the signed JAR file (using
      +    the `jar` tool) that already contains a signature and a `.SF` file. If the
      +    JAR file is signed again by a different signer, then the manifest file is
      +    changed (sections are added to it for the new files by the `jarsigner` tool)
      +    and a new `.SF` file is created, but the original `.SF` file is unchanged. A
      +    verification is still considered successful if none of the files that were
      +    in the JAR file when the original signature was generated have been changed
      +    since then. This is because the hashes in the non-header sections of the
      +    `.SF` file equal the hashes of the corresponding sections in the manifest
      +    file.
      
       3.  Read each file in the JAR file that has an entry in the `.SF` file. While
           reading, compute the file's digest and compare the result with the digest

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              weijun Weijun Wang
              Reporter:
              weijun Weijun Wang
              Reviewed By:
              Sean Mullan
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: