Change new _Delegator.verify_delegate to take payload bytes and
signatures instead of a Metadata object and a payload serializer.
This allows using verify_delegate for payloads that do not come in
a Metadata container, but e.g. in a DSSE envelope (see #2385).
Usage becomes a bit more cumbersome, but still feels reasonable with the
recently added shortcut for default canonical bytes representation of
Metadata.signed.
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
- Add shortcut to canonical json representation of self.signed
- Use in tests and Metadata.sign
- Do not use in _Delegator.verify_delegate (will be updated in subsequent
commit).
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
Remove duplicate docstrings: these are already documented in
_DelegatorMixin and sphinx will find them there.
Tweak a few other strings to remove duplication in the sentence.
Signed-off-by: Jussi Kukkonen <jkukkonen@google.com>
Metadata API: Improve dosctrings
Signed-off-by: Jussi Kukkonen <jkukkonen@google.com>
This makes logical sense and makes a lot of code using
verify_delegate() a little easier since there is no need to keep a
reference to the containing metadata anymore.
The implementation is in practice in a new class but that's an
implementation detail that allows sharing between Targets and Root.
Signed-off-by: Jussi Kukkonen <jkukkonen@google.com>
* Use the same solution for producing the paths as we already do in ngclient
* Fix linting issues
* Modify the test results according to new code (I believe these are
correct, although some cases are so edge cases that disagreement may
exist. Most importantly I think the method should always return as
many paths as there are hashes listed
Signed-off-by: Jussi Kukkonen <jkukkonen@google.com>
Simplify the lookup of delegated keys and roles by moving it to
Targets and Root: this follows the examples set by add_key() and
remove_key().
Most of the methods are trivial but they make sense because this way
the calling code does not have to care if the object is a Targets or a
Root: the same methods work on both.
The new methods are public since they are useful to applications as
well.
Signed-off-by: Jussi Kukkonen <jkukkonen@google.com>
verify_delegate() unfortunately needs an almost complete rewrite
as the Key.verify_signature() API change affects it quite a bit.
Refactoring the role and key lookup into a separate method makes the
code readable again.
Signed-off-by: Jussi Kukkonen <jkukkonen@google.com>
Key has been moved to Securesystemslib: use it from there.
This still fails tests as Key API has changed a bit: issues are fixed
in followup commits.
Signed-off-by: Jussi Kukkonen <jkukkonen@google.com>
This makes sense to me: if you create a new MetaFile, logically it
is version 1). This does not change serialization in any way.
Practical code becomes slightly nicer as
metafiles = defaultdict(MetaFile)
now works without lambdas.
Signed-off-by: Jussi Kukkonen <jkukkonen@google.com>
Bump the supported specification version to 1.0.31 and additionally
update the generated test metadata as it has to be up to date with the
latest changes.
The new changes in the specification version 1.0.31 clarify the
requirement for the new root version as compared to the old root version
in step 5.3.5:
https://theupdateframework.github.io/specification/latest/#update-root
We already do what the specification suggests in the new changes, so
no other changes are required.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
Bump the supported specification version to 1.0.30 and additionally
update the generated test metadata as it has to be up to date with the
latest changes.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
In the spec version 1.0.30, a new change has been added considering what
should happen if there is a new timestamp with the same version.
It says the following:
"In case they [versions] are equal, discard the new
timestamp metadata and abort the update cycle.
This is normal and it shouldn't raise any error."
In other words, if there is a new timestamp with the same version, then
stop the update process and use the old timestamp.
Those changes reflect these latest specification modifications.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
Here is the list of all breaking API changes:
1) The "role" and "key" arguments in "Root.add_key()" are in reverse
order - "key" becomes first and "role" second.
2) "Root.remove_key()" has been renamed to "Root.revoke_key()".
3) The "role" and "keyid" arguments in "Root.revoke_key()" are in
reverse order - "keyid" becomes first and "role" second.
4) The "role" and "key" arguments in "Targets.add_key()" are in reverse
order - "key" becomes first and "role" second.
5) "Targets.remove_key()" has been renamed to "Targets.revoke_key()".
6) The "role" and "keyid" arguments in "Targets.revoke_key()" are in
reverse order - "keyid" becomes first and "role" second.
7) In both methods "Targets.add_key()" and "Targets.revoke_key()" the
"role" argument becomes an optional with a default value of None.
Those changes are made in an effort to make those methods logical
for both cases when standard roles and succinct_roles are used.
The "Root" API change was done in order to preserve naming and argument
order consistency with "Targets" API.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
This commit contains 2 API changes in "Delegations" class from
tuf/api/metadata.py:
1. roles argment is made optional
2. unrecognized_fields argument becomes the 4-th rather than the 3-rd
as it used to be
In this commit, I add support for succinct_roles roles inside
Delegations class. This change is related to TAP 15 proposal.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
Clarify explicitly that exactly one of "paths" and "path_hash_prefixes"
must be set inside DelegatedRole.
Also simplify the check for "paths" and "path_hash_prefixes".
Finally, add a test case inside the "test_metadata_serialization.py"
test file about wrong keyids type for "Role" serialization.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
Add two helper methods in SuccinctRoles.
Those methods proved useful in the testing code, but I believe they have
a potential value for production code as well.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
Add zero padding to bin names inside SuccinctRoles.
Zero padding ensures that the bin names always have the same length.
This characteristic is implied in the example given by TAP 15 where
the third bin is named "alice.hbd-03". For context read TAP 15:
https://github.com/theupdateframework/taps/blob/master/tap15.md
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
Add SuccinctRoles class containing the information from the
succint_roles dict described in TAP 15.
This allows for easy mypy checks on the types, easy enforcement on
TAP 15 restrictions (as for example that "bit_length" must be between 1
and 32) and support for unrecognized fields inside succinct_roles
without much of a hassle.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
Fixes#1937
Initialization of unrecognized_fields acts surprisingly when the input
container is empty. Hence, We're checking for None instead of falsyness.
Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>
Fixes#1938
Description of the changes being introduced by the pull request:
Annotating as Mapping seems wrong as further changes to the content might
be added in the code base. Hence, annotation changed to Dict.
Signed-off-by: Abhisman Sarkar <abhisman.sarkar@gmail.com>
This means the metadata is by default expired: this seems like a fine
default since we only allow a default value for practical reasons (not
allowing it would mean backwards incompatible API change).
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
If argument is an empty container, we want to use the given empty
container. Only create a new container if argument is None.
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
This allows creating new metadata with less boilerplate:
root = Metadata(Root())
targets = Metadata(Targets())
Set reasonable default values for all the arguments -- version to
1, spec_version to current supported version, etc.
Expires does not have a good default value and my original plan was
to require expires argument to be set. That would mean an
incompatible API change though as arguments before expires would be
now optional... So expires now defaults to an arbitrary value of 1
day from moment of creation.
One noteworthy special case is consistent_snapshot where the default
value is True (since that's what we want people to use for new
metadata) but None is also used to imply that metadata does not contain
the field at all.
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
