-
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
libtuf.py needs method for dynamically retrieving a delegated targets role #165
Comments
Issue 147: Finalize conversion of all written metadata behavior. This commit ensures that compressed and uncompressed metadata is also written as outlined in the issue. Issue 158: As requested, updater.refresh() may now unsafely fetch (i.e., unknown file size and hash) Root metadata if valid top-level metadata cannot be downloaded successfully (e.g., top-level keys may have been revoked). The repository must also sign the new Root file (at least until all clients have updated) with any revoked keys so that clients may successfully update. After unsafely updating Root, the top-level metadata is updated again as normal (and only once to avoid an infinite loop). By default, refresh() unsafely updates Root if only invalid top-level metadata can be downloaded, although this behavior may be overriden by the caller if they wish. Changed default behavior: refresh(self, unsafely_update_root_if_necessary=True) Issue 165: Delegated roles are no longer added as attributes of a Targets object by libtuf.py (e.g., repository.targets.delegated_role). The previous bahavior restricted rolenames to Python identifiers (i.e., can only include letters, numbers, the underscore character, and must start with a nonnumeric character). Now, delegated roles may be referenced as strings (e.g., repository.targets('recently-claimed')) and include characters other than '_'. In addition, methods have been added to return all the delegated rolesnames of a target (e.g., repository.targets.get_delegated_rolenames()) and the immediate delegated Target objects of a role. Previous behavior: repository.targets.unclaimed.django.version = 8 Current behavior: repository.targets('unclaimed')('django').version = 8.
Delegated roles are no longer added as attributes of a Targets object by libtuf.py (e.g., repository.targets.delegated_role). The previous bahavior restricted rolenames to Python identifiers (i.e., can only include letters, numbers, the underscore character, and must start with a nonnumeric character). Now, delegated roles may be referenced as strings (e.g., repository.targets('recently-claimed')) and include characters other than '_'. In addition, methods have been added to return all the delegated rolesnames of a target (e.g., repository.targets.get_delegated_rolenames()) and the immediate delegated Target objects of a role. Previous behavior: repository.targets.unclaimed.django.version = 8 |
Update the libtuf.py diagram following Issue #165 changes.
Update documentation following Issue #165 changes.
👍 Seems more Python-ish, though, to make it index-able (like dictionaries or lists). Community can decide this later. |
Removal of securesystemslib exceptions that are TUF-specific occurs in securesystemslib PR #165 secure-systems-lab/securesystemslib#165 This commit adapts to those changes. Exceptions that are specific to TUF should be in TUF and not in securesystemslib. This commit uses those already-existing TUF exceptions instead of pointing to securesystemslib exceptions that will be removed. For example, securesystemslib has no notion of repositories, so it's ridiculous to have a RepositoryError in securesystemslib and ridiculous for TUF to use securesystemslib.exceptions.RepositoryError. Signed-off-by: Sebastien Awwad <[email protected]>
Removal of securesystemslib exceptions that are TUF-specific occurs in securesystemslib PR #165 secure-systems-lab/securesystemslib#165 This commit adapts to those changes. Exceptions that are specific to TUF should be in TUF and not in securesystemslib. This commit uses those already-existing TUF exceptions instead of pointing to securesystemslib exceptions that will be removed. For example, securesystemslib has no notion of repositories, so it's ridiculous to have a RepositoryError in securesystemslib and ridiculous for TUF to use securesystemslib.exceptions.RepositoryError. Signed-off-by: Sebastien Awwad <[email protected]>
Removal of securesystemslib exceptions that are TUF-specific occurs in securesystemslib PR #165 secure-systems-lab/securesystemslib#165 This commit adapts to those changes. Exceptions that are specific to TUF should be in TUF and not in securesystemslib. This commit uses those already-existing TUF exceptions instead of pointing to securesystemslib exceptions that will be removed. For example, securesystemslib has no notion of repositories, so it's ridiculous to have a RepositoryError in securesystemslib and ridiculous for TUF to use securesystemslib.exceptions.RepositoryError. Signed-off-by: Sebastien Awwad <[email protected]>
Observed
Presently,
libtuf.py
assumes that the developer knows the name of a delegated targets role before runtime. For example, retrieving the "unclaimed" role would be specified asrepository.targets.unclaimed
.However, this is not always true or even possible. For example, how would a developer address in this manner a delegated targets role with the name
recently-unclaimed
? Furthermore, sometimes the developer may not known the names of the delegated targets role until name (perhaps because it is supplied by a user at the command-line).Expected
We simply need a method for retrieving a delegated targets role by its name in a string. I will defer the exact mechanism to @vladimir-v-diaz , but a simple function should do the job.
The text was updated successfully, but these errors were encountered: