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

[Eirik Bjorsnos]

On Wed, 18 Jan 2023 12:57:17 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> 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)

On a similar note, I added test covering for the matching of custom SIG-* files in SignatureFileVerifier.isSigningRelated.

The test now checks both valid and invalid SIG- file extensions and directory locations inside/outside META-INF

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

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