[feat] add NewLiveTrustedRootWithClient()

[ramonpetgrave64]

Description

Re: slsa-framework/slsa-verifier#791 (comment)

I'm proposing that we change NewLiveTrustedRoot to accept an existing client, instead of making a new client for each fetch.
Or, we add a new function NewLiveTrustedRootWithClient() that does the same.

My use case is for my library slsa-verifer, where a user may pass in their existing client with custom opts, which slsa-verifier then uses for retrieving a TrustedRoot. Client.opts is private, so my library wouldn't be able to simply pass along the opts.

[ramonpetgrave64]

@haydentherapper @codysoyland

[codysoyland]

I'm not opposed to this in principle, but I think I had a good reason not to accept a TUF client in NewLiveTrustedRoot -- maybe something about the TUF client being stateful and not refreshing targets more than once, perhaps?

Currently, NewLiveTrustedRoot does not have any unit test coverage. I would accept this change if we can add unit tests that validate that the targets are indeed updated on each interval.

In order to make this testable, the refresh interval needs to be configurable, which is currently hardcoded to 24 hours. I would be happy to make this interval a required parameter to NewLiveTrustedRoot.

[ramonpetgrave64]

I'll consider that PR. In the mean time, it seems like it should be more natural for the TUF client itself to do its own update periodically, without the need to instantiate a new TUF client. What's Do you happen to know the reasoning behind why updates are only allowed once per client lifetime?

• https://github.com/theupdateframework/go-tuf/blob/f95222bdd22d2ac4e5b8ed6fe912b645e213c3b5/metadata/updater/updater.go#L105

[codysoyland]

Do you happen to know the reasoning behind why updates are only allowed once per client lifetime?

Good question... @rdimitrov ?

[rdimitrov]

Do you happen to know the reasoning behind why updates are only allowed once per client lifetime?

Good question... @rdimitrov ?

hey, yes, it is intentional and I can try to find the reasoning @jku has about this (unless he replies here in the meantime).

[jku]

Do you happen to know the reasoning behind why updates are only allowed once per client lifetime?

In python-tuf (where this design likely comes from) the logic is this:

• python-tuf is a library and does not make decisions about when to do things (like updating metadata or downloading artifacts)
• the application decides when things happen
• it's slightly simpler to safely implement the Updater so that it only refreshes metadata once: if the application wants to refresh metadata again, it can just create a new instance

There is nothing that prevents modifying the Updater so that the same instance could refresh metadata from repository multiple times... I just didn't see much advantage to doing so.

[ramonpetgrave64]

Thanks for chiming in. Alright, I think the LiveTrustedRoot can call the client's Refresh().