New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Verify misbehaves when multiple signatures exists #2158
Comments
FYI - there was previous discussion of this / related multiple signature issues in SingularityCE at sylabs/singularity#1150 |
Thanks for the link, DT. That refers to #462 which is also related, but already implemented. |
I originally brought this up. The errors make sense in hindsight. It was not obvious to me that by default Apptainer attempts to verify all signatures at once. I may submit a PR for userdocs again when I discover the final right way to verify all sigs at once (might be a while- I am slow and have other priorities and still have a lot to learn about X509) pointing this out. This probably has little to do with Apptainer, and more to do with me being completely baffled by X509 :^) I don't think any code changes need to be made. However for a given sif if object 5, 6, 7 have signatures, and only the cert for 7 is provided, it will complain about 5 missing, although 6 is missing too. It might take a lot of work to make checks for all the signatures and report which ones are missing, and I am skeptical it's necessary. |
I disagree, I think the the current behaviour doesn't make sense. If there is a use for requiring all signatures to be verified, it should be chosen by a flag. Even worse, specifically for the directly supplied public key, it didn't (somewhat surprisingily) even work to provide keys for both signatures either. |
apptainer supports multiple signatures, but verification does not seem to work as expected for these, instead adding a new signature will break verification for the previously existing signature.
Version of Apptainer
from git commit 8028a38 (17 Apr)
1.3.0+170-g8028a3889-dirty
Steps to reproduce this behavior
Expected behavior
Actual behavior
If using the public key corresponding to the first signature, the user gets a FATAL error about the signature object for the second object not being possible to verify, but I'd argue we shouldn't care about that (adding a signature shouldn't break verification of previous).
It is somewhat communicated to the users that part of the file do verify, but that's followed by a scare error and the exit code signals an error.
For the case of the key for the second signature, one gets the same error for a different signature object, but it doesn't list any objects being verified. I don't know but my guess is that it doesn't try to look at the correct signature object (6 in the example above) but rather sees that the first it encounters doesn't match the provided key and bails out.
(Exit code matters since this might be used automated and bail out if it fails, e.g. a workflow where "blessed" images are signed and some script tries to verify that by checking that a given image is signed with the relevant key - that will currently break at the stage of verification.
What OS/distro are you running
How did you install Apptainer
Built from git main.
The text was updated successfully, but these errors were encountered: