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>
Change to @lukpueh proposal with more clarification on why and how
the `securesystemslib.signer.Signer` interface is used
Co-authored-by: Lukas Pühringer <luk.puehringer@gmail.com>
Signed-off-by: Ivana Atanasova <iyovcheva@vmware.com>
This change updates some parts of the Metadata API docstrings
that did not give enough details and context
Fixes#1600
Signed-off-by: Ivana Atanasova <iyovcheva@vmware.com>
After we have dropped OrderedDict in e3b267e2e0
we are relying on python3.7+ default behavior to preserve the insertion
order, but there is one caveat.
When comparing dictionaries the order is still irrelevant compared to
OrderedDict. For example:
>>> OrderedDict([(1,1), (2,2)]) == OrderedDict([(2,2), (1,1)])
False
>>> dict([(1,1), (2,2)]) == dict([(2,2), (1,1)])
True
There are two special attributes, defined in the specification, where
the order makes a difference when comparing two objects:
- Metadata.signatures
- Targets.delegations.roles.
We want to make sure that the order in those two cases makes a
difference when comparing two objects and that's why those changes
are required inside two __eq__ implementations.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
By adding __eq__ we can compare that two objects are equal.
That will be useful when adding validation API call.
One bug I have found during testing is that I don't check if the type
of "other" in the __eq__ implementations are the expected ones.
I assumed that when comparing "root == obj" if "obj" is None that
automatically the result will be false.
Later after a mypy warning, I realized we should implement the __eq__
methods to accept "Any" type as other and we should check manually
that "other" is the expected type.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
We don't want to error out from the whole verify_delegate() process if
e.g. a single key fails to load but we do want to provide details for
debugging in the unexpected failure cases.
This means "example_client -vv download file1.txt" fails like this:
Found trusted root in /home/jku/.local/share/python-tuf-client-example
INFO:tuf.api.metadata:Key
4e777de0d275f9d28588dd9a1606cc748e548f9e22b6795b7cb3f63f98035fcb failed
to verify sig: Failed to load PEM key bogus-key-content-here
INFO:tuf.api.metadata:Key 4e777de0d275f9d28588dd9a1606cc748e548f9e22b6795b7cb3f63f98035fcb failed to verify root
Failed to download target x: root was signed by 0/1 keys
Fixes#1875
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
The Document formats section (chapter 4) of the
specification says the following:
"All of the formats described below include the ability to add more
attribute-value fields to objects for backward-compatible format
changes. Implementers who encounter undefined attribute-value pairs in
the format must include the data when calculating hashes or verifying
signatures and must preserve the data when re-serializing."
I initially thought it's applicable only to the SIGNED fields as
"undefined attribute-value pairs in the format must include the data
when calculating hashes or verifying signatures"
This doesn't mean that the sentence before that excludes "Metadata" as a
possible place for additional fields.
The other maintainers agreed with me and we are going to add support for
'unrecognized_fields" inside "Metadata".
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
If a securesystemslib.FormatError is raised inside
Key.from_securesystemslib_key() then reraise ValueError.
This is done so that our users don't have to import securesystemslib
in order to handle the error and because the securesystemslib error
itself is securesystemslib implementation-specific.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
This change updates some obvious and unnecessary fields docs in the
Metadata API with more despriptive details
Signed-off-by: Ivana Atanasova <iyovcheva@vmware.com>
This change unifies as mush as the context allows and improves the
use of definite vs. indefinite vs. no article across docs in the
Metadata API. It sticks to no article in most cases for simplisity
and readability, but leaves definite article where it's strictly
necessary
Signed-off-by: Ivana Atanasova <iyovcheva@vmware.com>
