libtuf.py needs method for dynamically retrieving a delegated targets role #165
Labels
Comments
vladimir-v-diaz
added a commit
that referenced
this issue
Jan 2, 2014
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 |
vladimir-v-diaz
added a commit
that referenced
this issue
Jan 2, 2014
Update the libtuf.py diagram following Issue #165 changes.
vladimir-v-diaz
added a commit
that referenced
this issue
Jan 2, 2014
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. |
Merged
awwad
added a commit
that referenced
this issue
Apr 16, 2019
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]>
lukpueh
pushed a commit
that referenced
this issue
Sep 17, 2019
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]>
lukpueh
pushed a commit
that referenced
this issue
Sep 17, 2019
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]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Observed
Presently,
libtuf.pyassumes 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: