Summary of the issue

Miloslav Trmač added a comment - 2024/05/03 8:19 PM And when the partial results are insufficient, do we want to return both "signature-1 wasn't trusted" and "I had trouble retrieving signature-2" in the error passed up to the kubelet? I think doing both is the clearly the best thing here. When the partial results are sufficient to validate the image, is it worth logging and/or bubbling up "...but we did have some unexpected difficulty with signature-retrieval" warnings? That’s unclear… … but, I’m afraid, it highlights a bigger issue: The signature policy enforcement is not the only place reading signatures. Image copies c/image/copy.Image also read signatures in order to write them into the destination; and in that case we do, in general, need  all of them so that the copy at the destination is correct and complete. The caller can opt out of that by setting Options.RemoveSignatures . But ordinary “pulls” do not opt out that way: we do want to store copies of the signatures locally, because we want a local record of how the image managed to pass the signature check (e.g. to allow forensic examination of a compromised computer, if the registry serving a malicious-but-correctly-signed image disappears after a successful attack). So that ~rules out the simple approach: We could handle partial signature lists in the signature check code, but the pull as a whole would still fail. We would need an entire new mode, where we collect the signature blobs that were required to confirm to the policy (and other blobs we have available?), and write those to the destination, even if we can’t read everything form the source.