RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs [v2]

[Sean Mullan]

On Thu, 13 Jan 2022 21:54:17 GMT, Weijun Wang <weijun at 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