Question: What would we expect whenever the server restarts ? It is okay to recreate the repository again and again.

[vaikas]

Question: What would we expect whenever the server restarts ? It is okay to recreate the repository again and again.

Originally posted by @hectorj2f in #262 (comment)

[asraa]

Oh, it's not idempotent based on the same inputs?

Correct, because signatures are generated during the metadata creation, so recreating the metadata would result in different bytes.

What would we expect whenever the server restarts ? It is okay to recreate the repository again and again.

Correct me if I'm wrong, let me give this a stab!
On first creation, we currently CreateRepo from the three secrets. This code stores the initial 1.root.json to the secrets and then serves the repository.

If we can also store the TUF repo signing key in the secrets on the initial creation, then we can do the following if the server is being re-started:

1. Retrieve the 1.root.json and the TUF repo signing key.
2. Issue a 2.root.json with the TUF repo signing key and new generated keys for the other roles.
3. Continue with the same process in CreateRepo to add the targets, snapshot, timestamp, and commit. from here on wards.
4. Serve the new repository.

Clients will be able to chain their existing 1.root.json to the refreshed server.

Does that make sense?

We can further simplify if we use the same signing key for all roles. Then we don't need to do step (2).

[vaikas]

I think that makes sense. Just to make sure I'm on the same page, if we were to take the results from here:
https://github.com/sigstore/scaffolding/blob/main/cmd/tuf/server/main.go#L90

And move it to where we create the unified secret instead of doing in the server and serialize it and then unserialize it on server restart, that would also work?

But, I kind of like exercising also the resigning path, by doing this, we could add some more testing on this path by restarting and ensuring that things keep working?

[asraa]

And move it to where we create the unified secret instead of doing in the server and serialize it and then unserialize it on server restart, that would also work?

Yes! If we took the entire dir or local Store result and serialized that, we could just re-serve that entire dir.

could add some more testing on this path by restarting and ensuring that things keep working?

Good idea, I can add some testing that recreates the repo and uses sigstore's tuf client to continue verifying

[vaikas]

Ok, thanks! I think it might be easier and be better for testing to do what you suggest then instead of serializing/unserializing, I think. Also more tests are always good :)