On Wed, 18 Jan 2023 12:57:17 GMT, Eirik Bjorsnos <d...@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
