Description
API docs say that Key.verify_signature raises either UnverifiedSignatureError (Failed to verify signature), or VerificationError (Signature verification process error.)
As a consequence, we have the following pattern in current Key implementations:
try:
- prepare key and signature (e.g. pop value from dict, deserialize)
- verify signature
except implementation-specific "unverified signature"-error:
- re-raise as UnverifiedSignatureError
except everything else:
- re-raise as VerificationError
During review of #585, we discussed, if catching generic Exception was acceptable here, and if the method should pass through or raise other exception types like ValueError (e.g. if a keyids in key and signature don't match) or UnsupportedLibraryError.
The underlying question is, how should a client be able to handle (e.g. fail, ignore, recover) all types of verification errors? This includes failures due to key or signature formats, which are not supported by the library (at all, or because an optional dependency is missing).
EDIT: Let's also make sure that this is properly tested.
Activity
lukpueh commentedon Jun 2, 2023
Some thoughts about requirements:
Key.from_dict), and attempt verification (usingkey.verify_signature), even with keys with unknown or unsupported keytypes or schemes.lukpueh commentedon Jun 2, 2023
Currently,
Key.from_dictraises an error on unknown keytypes and schemes. If the application just catches the error and skips the unknown key, it will break any signature verification of the container metadata, if it depends on canonicalisation. Which is the default for tuf and in-toto.