Design client library

[lukpueh]

Identify what functionality from existing updater/download modules should exist in a TUF client on top of a metadata model as sketched in #1112.

Start with API functionality.

Coordinate with #1134.

[joshuagl]

Things to consider, based on learnings from a PoC integration with pip (cc @jku):

• download progress reporting Updater: No download progress hooks #1057 handled with the abstract Fetcher interface Abstract out the network IO #1250
• allowing a package manager to plug-in their own network/download stack resolved with the abstract Fetcher interface Abstract out the network IO #1250
• minimal footprint (minimal dependencies and being able to be installed independently of the repository library and tools)
• supporting metadata and targets on separate hosts, and different targets on different hosts client/updater design: mirror config redesign #1143
• ability to check for existence of local configuration for a given repository Updater: Add ability to check for existence of (local) repository #1063

TAPs to be aware of when designing:

• TAP 3: Multi-role delegations – accepted, but not in the specification because it is not implemented for the reference implementation
• TAP 4: Multiple repository consensus on entrusted targets – accepted, but not yet in the specification. Implemented in the current reference implementation

[jku]

• allowing a package manager to plug-in their own network/download stack

Filed #1142 for this

[jku]

• supporting metadata and targets on separate hosts, and different targets on different hosts

and #1143 for this

[jku]

See #1158 for "client/updater: Parallel Downloads"

[joshuagl]

We're seeing multiple areas where the current Updater interface/API is brittle or confusing (#1143, #1174, possibly others).

I had originally expected that we would try to maintain the current updater API, but we should review that and even if we do stay close to the current API plan to fix the confusing/outdated/inflexible aspects.

[jku]

I had originally expected that we would try to maintain the current updater API, but we should review that and even if we do stay close to the current API plan to fix the confusing/outdated/inflexible aspects.

Same same.

Now that we've kicked out mirrors (so are not directly compatible anyway) and now that I've had time to think about it, I think we should improve the API as much as we can. It'll still be quite close to the old one (so not hard to port) but hopefully an improvement.

Latest ideas in #1317 (comment)

[MVrachev]

I think that in a way this issue and issue #1317 are covering the same stuff.
Do we need that one?
If we don't, I think the only two proposals left that are not addressed are

TAPs to be aware of when designing:

• TAP 3: Multi-role delegations – accepted, but not in the specification because it is not implemented for the reference implementation
• TAP 4: Multiple repository consensus on entrusted targets – accepted, but not yet in the specification. Implemented in the current reference implementation

which we can move in #1317 as TODO items.

[jku]

IMO the final missing piece(s) here might be documented in #1580.

[jku]

I'm sure there are features that are still wanted by someone, but I think the client design is now done and implemented: anything still missing is a new feature, closing this one