Enable Refresh() to be called more than once about go-tuf-metadata HOT 9 CLOSED

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.

from go-tuf-metadata.

cc: @kommendorkapten

from go-tuf-metadata.

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.

from go-tuf-metadata.

👋 @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.

from go-tuf-metadata.

See #87

from go-tuf-metadata.

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

from go-tuf-metadata.

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.

from go-tuf-metadata.

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).

from go-tuf-metadata.

Closing in favour of theupdateframework/go-tuf#593

from go-tuf-metadata.