The resource loader verifier should verify resources listed in the manifest as follows:

• Read and cache the META-INF/MANIFEST.MF
• The JDK assumes that the manifest is the first entry in the directory, but we cannot (and should not) make that assumption
• Find all files in the META-INF directory which end in .SF, .DSA, .RSA, or .EC (these are signature files); this check should be done after applying name.toUpperCase(Locale.ROOT) to the file name
• .SF files are loaded using the same Manifest API because they share the same format
• .RSA files are binary and contain a PKCS#7 signature with an algorithm of SHA-256+RSA
• .DSA files are binary and contain a PKCS#7 signature with an algorithm of DSA
• .EC files are binary and contain a PKCS#7 signature with an algorithm of ???
• .RSA, .DSA, .EC, and SIG- files are signatures over the corresponding .SF file content
• Each signature file corresponds to one CodeSigner
• The manifest signature should be verified before processing entries
• The main attributes of a signature file are:
  • Signature-Version - a version number for the signature version (must be "1.0")
  • Created-By - ignored
  • XXX-Digest-Manifest-Main-Attributes - an optional digest over the main attributes of the MANIFEST.MF file
  • XXX-Digest-Manifest - an optional digest over the entire MANIFEST.MF file
• Each signature file entry:
  • Corresponds to a manifest entry of the same name
  • Contains an "XXX-Digest-Manifest" entry
• For each JAR entry being read:
  • Locate the main manifest attributes for the entry corresponding to the resource name (after being normalized) (some JARs have non-spec "/foo" or "./foo" entry names; we don't need to support these though)
  • Search for an attribute name of the form "XXX-Digest", where XXX is a supported MessageDigest algorithm name
  • Decode and record the content of the attribute using Base64.getMimeDecoder()
  • Verify the digest of the content of the resource data using the digest, if one is present, throwing an exception at the end of resource reading if the digest does not match
  • The results may be cached; the MessageDigest instance should be cached by algorithm to avoid repeated instantiation overhead (efforts should be made to minimize locking)
  • Unrecognized digest algorithms should result in an exception
  • Perform similar verification using the "XXX-Digest" entries of the .SF file (if any)
  • All verification exceptions should be thrown when the end of the underlying entry is reached, thus it is necessary to create one or more wrapping "verifying input stream(s)" for resources that have verification data; it may make sense to have a separate digest verifier and signature verifier