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>
Rephrase deprecation info in repo_example modules doc headers
to reflect that the deprecation has happened.
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
After we drop support for python3.6 we can relly that dictionaries
preserve the insertion order:
https://docs.python.org/3.7/whatsnew/3.7.html
This means we can replace the usage of OrderedDict with a standard
dictionaries.
Something we have to keep in mind is that even thought the insertion
order is preserved the equality comparison for normal dicts is
insensitive for normal dicts 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
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
The examples folder currently contains a repository example and it's
good if we start linting its content and as a result add type
annotations.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
As 'repository_tool' and 'repository_lib' are being deprecated,
repository metadata must to be created and maintained manually
using the low-level Metadata API. The added example code shall
serve as temporary replacement until a new repository tool is
available.
The sample code contains the following repo workflows:
- creation of top-level metadata
- target file handling
- consistent snapshots
- key management
- top-level delegation and signing thresholds
- target delegation
- in-band and out-of-band metadata signing
- writing and reading metadata files
- root key rotation
Co-authored-by: Teodora Sechkova <tsechkova@vmware.com>
Co-authored-by: Joshua Lock <jlock@vmware.com>
Co-authored-by: Jussi Kukkonen <jku@goto.fi>
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
