theupdateframework / specification

The Update Framework specification
https://theupdateframework.github.io/specification/
Other
368 stars 54 forks source link

Stepping-stone releases #178

Closed a21152 closed 3 years ago

a21152 commented 3 years ago

Often, a client running outdated software can't directly update to the very latest update. Instead they need to update to some predefined stepping-stone releases, which could for example help transition the client into a more capable state (the exact transition details only best handled by the specified stepping stone release).

Is TUF designed to handle this already? Otherwise it seems freeze-attack checking would get in the way of updating to these intermediary release (whose signature may have expired).

trishankatdatadog commented 3 years ago

For as long as the latest, server-hosted TUF metadata is not incompatible with the old clients, this can be handled on the application level. The latest TUF metadata can host all versions of the client, and the client can use its own logic to figure out which one to update to first.

OTOH, if the client is not able to TUF due to incompatible changes in TUF metadata, this can be handled by TAP 14, which discusses how to update to backwards-incompatible versions of TUF.

Does this make sense?

a21152 commented 3 years ago

Yes. This makes a ton of sense.

Basically the client just need an extra target file that defines the valid/mandatory hops per the client's current version.

We don't have a situation for incompatible TUF metadata but good to know TAP 14 exists.

Thanks, Ali

trishankatdatadog commented 3 years ago

Basically the client just need an extra target file that defines the valid/mandatory hops per the client's current version.

In fact, you don't even need an extra target file. You could use custom targets metadata per client/target file to attach whatever application-specific information you like.