There are no longer any files in TUF that came from Thandy, and
so the dual license is no longer required.
Signed-off-by: Marina Moore <mnm678@gmail.com>
We've been returning Signature objects since 49aa0fc167.
Also add a test case that does something with the returned signature.
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
Explain the ways a delegation can happen: Do not try to cover the
complete process (specification should do that) but offer enough
details that the complexity is not completely hidden from the viewer.
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
Try to keep dostrings and comments to the point, avoid mentioning
details if they are not necessary or are likely to become outdated
and try to minimize number of comment lines.
Co-authored-by: Joshua Lock <jlock@vmware.com>
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
The idea of this commit is to separate (de)serialization testing outside
test_api.py and make sure we are testing from_dict/to_dict for all
possible valid data for all classes.
Jussi in his comment here:
https://github.com/theupdateframework/tuf/issues/1391#issuecomment-849390669
proposed using decorators when creating comprehensive testing
for metadata serialization.
The main problems he pointed out is that:
1) there is a lot of code needed to generate the data for each case
2) the test implementation scales badly when you want to add new
cases for your tests, then you would have to add code as well
3) the dictionary format is not visible - we are loading external files
and assuming they are not changed and valid
In this change, I am using a decorator with an argument that complicates
the implementation of the decorator and requires three nested functions,
but the advantages are that we are resolving the above three problems:
1) we don't need new code when adding a new test case
2) a small amount of hardcoded data is required for each new test
3) the dictionaries are all in the test module without the need of
creating new directories and copying data.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
Securesystemslib digest() and digest_fileobject()
calls raise sslib specific exceptions that need to be
handled and re-raised as TUF exceptions.
Updated tests in test_api.py accordingly.
Signed-off-by: Teodora Sechkova <tsechkova@vmware.com>
Changes tests/repository_data/keystore/root_key3* to be an ecdsa key,
created and encrypted with the generate_ecdsa_key and
encrypt_key methods of securesystemslib.keys.
The test_updater_root_rotation_integration.py test
tests both repotool and updater.
Signed-off-by: Velichka Atanasova <avelichka@vmware.com>
- valid length: greater than zero
- valid hashes: a non-empty dictionary of type Dict[str, str]
Checking the validity of hash algorithms is not part
of the metadata input validation and is done by
securesystemslib during hash verification.
Signed-off-by: Teodora Sechkova <tsechkova@vmware.com>
Test unknown signature algorithm/scheme.
Also shorten the incorrect (but syntactically valid) signature a bit.
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
Aim to only raise UnsignedMetadataError from verify_signature().
Some of the situations could be things like UnsupportedAlgorithmError
-- where the underlying reason may be a missing dependency -- but it
seems impossible for a client to know whether it's that or whether it
is broken or malicious server side.
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
Clarify that we don't semantically validate "Key" instances during
initialization and that this is a responsibility of securesystemslib.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
Probably there could be future API calls that modify "threshold"
to a new value, but the problem is we don't have a clear idea
if they would exist and what exactly they will do.
That's why it makes sense to validate against the potential problems
we can imagine - in this case, is passing a threshold below 1.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
In our discussion with Jussi we come to the conclusion that we want
to verify that all Key attributes contain values in the expected types,
but at the same time, we don't want to focus on validating the semantics
behind them.
The reason is that having a Key instance with invalid attributes is
possible and supported by the spec.
That's why we have a "threshold" for the roles meaning we can have up to
a certain number of invalid Keys until we satisfy
the required threshold.
Also, for deeper semantic validation it's better to be done in
securesystemslib which does the actual work with keys.
For context see: https://github.com/theupdateframework/tuf/issues/1438
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
According to point 2 in the semver specification:
"A normal version number MUST take the form X.Y.Z where X, Y, and Z are
non-negative integers...". See: https://semver.org/#spec-item-2
Also, even though version strings like "2.0.0-rc.2" or "1.0.0-beta" are
valid strings in semantic versioning format, in TUF we never needed
to add letters for our specification number.
That's why I validate that: spec_version is a . separated string
and when split it has a length of 3 and that each of the
three elements is a number.
The modules under the tuf/api folder in TUF are an alternative TUF
implementation. That's why they should use their own constant for
SPECIFICATION_VERSION in tuf/metadata/api.
This time, I used a list for the SPECIFICATION_VERSION constant in order
to retrieve major and minor versions easier.
I use the SPECIFICATION_VERSION to check that the given spec_version is
supported against the tuf code spec version.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
Extend MetaFile and TargetFile classes with methods
for length and hash verification. The common functionality
is implemented as static methods of the base class while
MetaFile and TargetFile implement the user API based on it.
Define LengthOrHasheMismathError.
Signed-off-by: Teodora Sechkova <tsechkova@vmware.com>
Clearing the OrderedDict makes it easier to see what happens and
avoids having to call OrderedDict() again.
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
In issue #1418 in this comment:
https://github.com/theupdateframework/tuf/issues/1418#issuecomment-852147689
I summarized the discussion we had with the participants in this issue.
In summary: no additional changes are needed for "version" validation
considering there is "bump_version()" function for that.
If we won't be adding "version" validation elsewhere we can keep it
the way it is.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
Dict ordering is part of regular Dict from Python 3.7: Use OrderedDict
for signatures to make sure signatures are serialized in a reproducible
order even on 3.6.
The added benefit is that reader will immediately understand that the
order has some significance.
The actual type annotations are a bit convoluted because:
* typing does not include OrderedDict before 3.7 so can't use that
* Annotating inner types does not work for collections.OrderedDict
in older pythons (so have to use the "stringified annotations")
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
store signatures in a Dict of keyid to Signature. This ensures
signature uniqueness. Raise in from_dict() if input contains multiple
different signatures for a keyid.
This changes Metadata object API, and makes it slightly different from
the file format: this is justified by making the API safer to use and
easier to validate.
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
This is likely not needed by users of the API (as they are interested
in the higher level functionality "verify delegate metadata with
threshold of signatures").
Moving verify to Key makes the API cleaner because including both
"verify myself" and "verify a delegate with threshold" can look awkward
in Metadata, and because the ugly Securesystemslib integration is now
Key class implementation detail (see Key.to_securesystemslib_key()).
Also raise on verify failure instead of returning false: this was found
to confuse API users (and was arguably not a pythonic way to handle it).
* Name the function verify_signature() to make it clear what is being
verified.
* Assume only one signature per keyid exists: see #1422
* Raise only UnsignedMetadataError (when no signatures or verify failure),
the remaining lower level errors will be handled in #1351
* Stop using a "keystore" in tests for the public keys: everything we
need is in metadata already
This changes API, but also should not be something API users want to
call in the future when "verify a delegate with threshold" exists.
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
This simplifies life for API users as usually a key needs its
identifier: this is already visible in how update() becomes simpler
in the API.
The downside is that 'from_dict()' now has two arguments (so arguably
the name is not great anymore but it still does _mostly_ the same job
as other from_dicts).
This is an API change, if a minor one.
Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
Currently we have one use of tuf/formats.py in tuf/api/metadata.py.
If we do the conversion of the expires string in metadata.py,
we can keep the two implementations separate.
Signed-off-by: Velichka Atanasova <avelichka@vmware.com>
This change is relevant to the new metadata class Targets.
In the specification, when describing the Targets metadata file format
and more precisely "TARGETPATH" (or targets containing the actual
target files) it's said:
"It is allowed to have a TARGETS object with no TARGETPATH elements.
This can be used to indicate that no target files are available."
If there is no "TARGETPATH" keys for the dictionary "targets", this
would mean that "Targets.targets" is {}.
Make sure we test for that.
See: https://theupdateframework.github.io/specification/latest/#targetpath
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
