On Thu, 13 Jan 2022 21:54:17 GMT, Weijun Wang <wei...@openjdk.org> wrote:
>> The algorithm constraints check will be skipped (because `permittedAlgs` >> will be `null`) but the hash check will not be skipped. >> >> I don't think `null` would be returned in a normal case. The only case I can >> think of is if there was an entry in the Manifest, but no corresponding >> entry in the SF file. I suppose we could still do a constraints check as if >> there were no signers. However, it doesn't seem that useful since >> technically the entry is not protected by the signature and the hash check >> is still done, unless I am missing something. > > Or maybe the key/signature algorithm is weak and ignored. I was only thinking > it's not worth calculating the hash anymore. Of course there will be a > behavior change. If there's a hash mismatch, it used to be a security > exception, but if ignored, it's just a plain unsigned entry. It will never get here if all of the signers are using disabled algorithms (or for some other reason cannot be parsed/verified) as `JarVerifier.nothingToVerify()` will return true. But I think it's possible if one of the signers is ok. But I'd prefer not to make that change because of the change in behavior. And I think in most cases, JARs will have a single signer. >> Yes, I can do that. However, I'm a bit wary of using lambdas in this code >> which may get exercised early in app startup. WDYT? > > Maybe, I don't know how problematic if lambda is used this early. > > Anyway, I still prefer moving the update of `permittedAlgs` here. Updating it > inside the method seems too faraway. Changed as suggested in latest revision. ------------- PR: https://git.openjdk.java.net/jdk/pull/7056
