Repository.writeall() may not need to write all dirty roles
#964
Comments
lukpueh
added a commit
to lukpueh/tuf
that referenced
this issue
Dec 2, 2019
TUF does not reliably mark roles as dirty whose metadata needs to be re-generated. Only roles that have changed are marked as dirty, but sometimes roles metadata needs to be updated, although the role wasn't changed directly (see theupdateframework#958). Furthermore, the tutorial assumes at one point that the reader leaves and re-enter the interpreter session, being forced to reload the signing keys, roles that later need to be re-written, are marked as dirty. If the reader does not leave the interpreter, the roles are not marked as dirty (see theupdateframework#964). To not confuse the reader with flawed state-keeping, and to never write an inconsistent repository to disk, the tutorial lets the reader explicitly mark all roles that need to be re-written as "dirty". This can be changed once above issues are fixed. Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
|
When fixing this issue, we may remove the explicit |
lukpueh
added a commit
that referenced
this issue
Dec 11, 2019
TUF does not reliably mark roles as dirty whose metadata needs to be re-generated. Only roles that have changed are marked as dirty, but sometimes roles metadata needs to be updated, although the role wasn't changed directly (see #958). Furthermore, the tutorial assumes at one point that the reader leaves and re-enter the interpreter session, being forced to reload the signing keys, roles that later need to be re-written, are marked as dirty. If the reader does not leave the interpreter, the roles are not marked as dirty (see #964). To not confuse the reader with flawed state-keeping, and to never write an inconsistent repository to disk, the tutorial lets the reader explicitly mark all roles that need to be re-written as "dirty". This can be changed once above issues are fixed. Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
lukpueh
added a commit
that referenced
this issue
Dec 16, 2019
TUF does not reliably mark roles as dirty whose metadata needs to be re-generated. Only roles that have changed are marked as dirty, but sometimes roles metadata needs to be updated, although the role wasn't changed directly (see #958). Furthermore, the tutorial assumes at one point that the reader leaves and re-enter the interpreter session, being forced to reload the signing keys, roles that later need to be re-written, are marked as dirty. If the reader does not leave the interpreter, the roles are not marked as dirty (see #964). To not confuse the reader with flawed state-keeping, and to never write an inconsistent repository to disk, the tutorial lets the reader explicitly mark all roles that need to be re-written as "dirty". This can be changed once above issues are fixed. Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
3 tasks
3 tasks
|
Closing this issue as it was filed against (what is now known as) the legacy codebase: issue seems to not be relevant anymore. Please re-open or file a new issue if you feel that the issue is revelant to current python-tuf. More detailsCurrent source code (and upcoming 1.0 release) only contains the modern components
Legacy components (e.g. tuf.client, tuf.repository_tool, tuf.repository_lib as well as the repo and client scripts) are no longer included. See announcement and API reference for more details. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of issue or feature request:
TUF marks roles as dirty if they are changed in roledb. This information is then used by
writeallto update role metadata on disk. But not all changes in roledb require updating metadata on disk. E.g. loading a signing key does not.Current behavior:
At least one function, i.e.
load_signing_keymarks a role as dirty, although it shouldn't update the corresponding metadata on disk.Expected behavior:
Reliably track the state of the repository in memory and on disk to know if role metadata needs to be updated. Also see #958.
The text was updated successfully, but these errors were encountered: