Enable Refresh() to be called more than once

[rdimitrov]

Describe the bug

Currently a Refresh() can be done only once during the lifetime of an Updater.

This is not optimal for long-living processes so it would be better if we enable calling Refresh() more than once.

References:

• https://github.com/rdimitrov/go-tuf-metadata/blob/4e20edf17ab0b724127ca3d2374e5a9580f3b519/metadata/updater/updater.go#L98C1-L98C72

Reproduction steps

...

Expected behavior

Upon calling Refresh() make sure everything is up-to-date and if that's true:

• return nil, instead of an error (better imho)
  or
• return a custom error type so the user can check it via errors.Is (less favourite)

If something else occurred which failed us to refresh the metadata, still return the appropriate error value.

Additional context

No response

[rdimitrov]

cc: @kommendorkapten

[joshuagl]

FWIW in python-tuf there was an explicit decision to only allow one refresh() call during an Updater's lifetime: https://github.com/theupdateframework/python-tuf/blob/f711997a08cbb558fc8ab91406a846bbe4883d1a/tuf/ngclient/updater.py#L115

Mostly sharing this so that you can dig into the rationale for the choice on the Python side and make an explicit choice to diverge from their implementation approach. I know this codebase started out implementing the same architecture.

[kommendorkapten]

👋 @joshuagl I'm working now on integrating this into the Sigstore TUF client, and if you remember, there are some requirements on caching, and especially to allow a client to use the locally cached metadata without performing a TUF update. We know this is a deviation from the TUF spec, but it was still a desired feature to have.

As part of adding that functionality, it would be required to first load the metadata on disk, then if expired, perform an update. This currently fails due to this.

Another example is long-lived processes, such as services that may have a lifetime far beyond the timestamp's expiration time. Such components could of course periodically recycle the client used, but that feels a bit unnecessary. Would be interesting to hear your thoughts here.

[kommendorkapten]

Actually I think I can solve most of this in the sigstore tuf client, let me think of that for a while.

But I would still need the deviation from the tuf spec (load metadata on disk only), I'll prepare a PR and we can discuss it more.

[kommendorkapten]

See #87

[joshuagl]

See theupdateframework/python-tuf#2472 for some exploration of offline mode for python-tuf

[jku]

See theupdateframework/python-tuf#2472 for some exploration of offline mode for python-tuf

Yes the last comment hopefully explains why we finally decided not to merge anything yet in python-tuf: At the moment sigstore-python can achieve the same security benefits (roughly none) by just using cached artifacts without verifying them.

If we had theupdateframework/python-tuf#1168 then offline verification would be a little more useful.

[kommendorkapten]

Ah, the bootstrapped root functionality is expected to be part of python-tuf itself? My thinking is a bit different, go-tuf requires a root.json (LocalTrustedRoot) and so it would be the the actual program's responsibility to make sure that it can be trusted (and the technique used to protect it can differ between programs).

[rdimitrov]

Closing in favour of theupdateframework/go-tuf#593