RFR: 8300140: ZipFile.isSignatureRelated returns true for files in META-INF subdirectories [v11]

[Eirik Bjorsnos]

On Wed, 18 Jan 2023 09:51:35 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> While `JarSigner` has not normalize to uppercase, the check is the same. As for `/META-INF/`, it must be very broken now since `JarFile::maybeInstantiateVerifier` is using `JUZFA.getManifestName(this,true)` to read the manifest and since `ZipFile` cannot see the signature-related files starting with `/META-INF/` this method will always return null.
>
> I agree this deserves a cleanup, and since we're already deep into it it can make sense to fix this in this PR.
> 
> I have introduced SignatureFileVerifier.isInMetaInf as a common method to replace duplicated logic in JarVerifier and  JarSigner. I also noticed that SignatureFileVerifier.isSigningRelated performs the same check, so I updated that method to also call the isInMetaInf.
> 
> This introduces two subtle behavioural changes:
> 
> - JarSigner is relaxed to ignore case when checking isInMetaInf, meaning "meta-inf/" files will now be moved to the beginning of the signed JAR
> - JarVerifier is tightened to reject /META-INF/ as not in META-INF/. This is believed to have little practical impact, since ZipFile.Source.isMetaName already rejects such paths.

When introducing the call to isInMetaInf in isSigningRelated, I accidentally broke the matching of MANIFEST.MF and SIG-* files.

When fixing this regression, I now match against the full path instead of the existing prefix stripping substring. (A nice side effect of this is that isBlockOrSF is now always called with the full path)

Since the regression was not caught by any existing test, I'm also adding a sanity check that a basic signed JAR has the expected sections in MANIFEST.MF. (The regression introduced a section for META-INF/MANIFEST.MF which seemed to not be caught by tests)

-------------

PR: https://git.openjdk.org/jdk/pull/11976