-
Notifications
You must be signed in to change notification settings - Fork 272
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
API : Add hash verification for timestamp/snapshot/targets #1361
Comments
Targets/TargetInfo (#1329) should support something similar but not necessarily the same function: with targets we should avoid loading the whole file so the function needs to accept a fileobject -- otherwise it's the same idea So updating the examples: The high level objects option: Timestamp.verify_snapshot_hashes(data: bytes)
Snapshot.verify_hashes(role_name: str, data: bytes)
Targets.verify_hashes(target_name, file_object: BinaryIO) MetadataInfo and TargetInfo option: MetadataInfo.verify_hashes(data: bytes)
TargetInfo.verify_hashes(file_object: BinaryIO) I still like the latter I think. Also: both could offer multiple methods for the different argument types, but at least the listed argument versions should exist |
Status here is that #1329 needs to progress first (assuming we implement this functionality in MetadataInfo and TargetInfo). Thinking about the API, are variable type arguments frowned upon? I would have objected to this before type hinting (and suggested duplicate methods) but I'm not so sure now: MetadataInfo.verify_hashes(data: Union[bytes, BinaryIO])
TargetInfo.verify_hashes(data: Union[bytes, BinaryIO]) This keeps the api tidy and provides verification for both immutable byte arrays and binary streams (aka file like objects). Looks ok to me. if isinstance(data, bytes):
# use securesystemslib.hash.digest()
else:
# use securesystemslib.hash.digest_fileobject() |
Agree that
I would have objected to functions with the same name on different classes having different signatures, but the typing and
|
I just realized that we may want to extend this to length checks as well:
This is basically an optimization for the case where the file is the wrong length. MetaFile is a more interesting case:
So good docs are needed at least to make this all clear |
Feature request: Would be nice to have hash verification builtin to the API: it's not a massive amount of code but a single call to a function with a descriptive name is a lot better than 6 lines of sslib-calling code...
I can see a couple of options:
or, as alternative to both of those, with MetadataInfo Martin is building in #1329 :
Last one is probably the correct place.
I'm not sure what should happen on failure though: Exception probably makes sense but then we probably want to change
Metadata.verify()
to do that as wellThe text was updated successfully, but these errors were encountered: