Skip to content
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

Clean up updater metadata update stack #841

Closed
awwad opened this issue Mar 26, 2019 · 4 comments
Closed

Clean up updater metadata update stack #841

awwad opened this issue Mar 26, 2019 · 4 comments
Labels
client Related to the client (updater) implementation enhancement up for grabs

Comments

@awwad
Copy link
Contributor

awwad commented Mar 26, 2019

tuf.client.updater has Updater objects. These contain a variety of client information, and also use some client information in settings.py. Though some client information lives in settings.py, an Updater object is, basically, a client. You update metadata using an Updater object.

There are a few issues with the stack:

Verification procedure is buried

The stack looks like this, where all functions are methods of Updater except where a module is noted:

  • You call refresh() on an updater object.
  • refresh() calls, for each role, _update_metadata(...)
  • _update_metadata(...) calls _get_metadata_file(...)
  • _get_metadata_file() loops over mirrors and:
    • calls (misleadingly named) tuf.download.unsafe_download(...) to get a temp file (max length limit)
    • calls _verify_uncompressed_metadata_file(...) to check the file
  • _get_metadata_file() stops when it has a successfully verified file, and returns it up the stack.

This stack limits the interface so that verification is hidden more deeply: it means that it looks like the only way to obtain a file in the API results in that file being already verified. I do not think this is reasonable here, as it's important for understandability and modularity to avoid this burying of verification.

The stack should, I think, instead look like this:

  • You call refresh() on an updater object.
  • refresh() calls, for each role, update_metadata(...) (now public)
  • update_metadata(...) loops over mirrors and:
    • calls get_unverified_metadata to get a temp file (max length limit)
    • calls verify_metadata (now public)
  • update_metadata(...) stops when it has a successfully verified file, and returns it up the stack.

You should be able to look at the public refresh() and the public update_metadata(...) and have an immediate understanding of what is happening, and naturally know where to make changes to metadata verification. These are high-level functions that are central to an implementation's TUF's specification conformance.

Redundant code in _update_metadata, _update_metadata_if_changed

@awwad awwad added enhancement good first issue Bite-sized items for first time contributors refactor client Related to the client (updater) implementation up for grabs labels Mar 26, 2019
@MatthewBosek
Copy link

Hello, can I work on this issue?

@awwad
Copy link
Contributor Author

awwad commented Jul 23, 2019

There's work on this already in #868, as part of #846. That's been left sitting, since I've been pretty busy. When I get TUF time, it's on the top of my stack. That said, you can always provide a PR, suggestions, or talk about what you need / think is best. Work can be integrated or replace existing work.

@lukpueh
Copy link
Member

lukpueh commented Mar 17, 2020

Note to myself: @awwad points out in #868 that the "updater shouldn't use roledb at all".

@joshuagl joshuagl added this to the Refactor milestone Jul 7, 2020
@joshuagl joshuagl removed this from the Refactor milestone Sep 8, 2020
@joshuagl joshuagl removed good first issue Bite-sized items for first time contributors refactor labels Sep 10, 2020
@jku
Copy link
Member

jku commented Nov 30, 2021

Closing this: ngclient has a fairly different design and I don't see the legacy client getting refactored

@jku jku closed this as completed Nov 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client Related to the client (updater) implementation enhancement up for grabs
Projects
None yet
Development

No branches or pull requests

5 participants