Backwards Compatibility (TAPs 3, 4, 5)

There's some hand-waving in the current TAPs about backwards-compatibility that I'd like to address. I think that backwards-compatibility is an important goal that would aid adoption, not just of TAPs but of TUF in general, by setting the precedent that the code you deploy today will continue to work tomorrow for some reasonable definition of tomorrow.

I think that the TAPs should analyze the pre- and post-TAP world for both client and server, and determine if it is safe to change the TAP to be backwards compatible. A client failure would be appropriate in situations where the feature provided by the TAP is in use and critical for valid client behavior.

TAP 3

Current Backwards Compatibility Section:

This TAP is incompatible with previous implementations of TUF because the targets metadata file format has been changed in a backwards-incompatible manner. However, note that it should take very little effort to adapt an existing implementation to resolve or encode delegations using the new file format.

New Backwards Compatibility Section Proposal:

This TAP can be made backwards compatible with the previous implementation of TUF by treating metadata with a name field the same as a metadata with a names field containing one entry.

Unaware clients (that is, clients that don't understand TAP3's changes) will fail to update to new metadata containing the new names key and not the name key.

Aware clients that attempt to update to new metadata containing the pre-TAP3 format will understand it as the degenerate case of TAP3's format and proceed as normal.

Because TAP3 does not address any security flaws, it is safe to allow old and new clients to coexist for a time.

TAP 4

Current Backwards Compatibility Section:

This specification is not backwards-compatible because it requires:

• TUF clients to support additional, optional fields in the root metadata file.
• A repository to use a specific filesystem layout.
• A client to use a map file.
• A client to use a specific filesystem layout.
• A client to download metadata and target files from a repository in a specific manner.

New Backwards Compatibility Section Proposal:

This TAP can be made backwards compatible with the previous implementation of TUF by treating a client without a mapping.json file as one with a single entry that delegates * to the root URL configured in the TUF client.

Unaware clients (that is, clients that don't understand TAP4's changes) will not have the ability to distribute trust in the way TAP4 specifies, but will continue to work assuming all requested targets live in the single configured repository.

Aware clients that attempt to update, but don't have a mapping file, will continue to operate the same as unaware clients. Aware clients that attempt to update and have a mapping file by definition operate as specified in this TAP.

There may be a case where a user assumes that an Unaware client is actually an Aware client, in which the user believes a mapping file is being consumed but is in fact being ignored. In most useful cases, the user will become aware of the issue because they either have no way to provide a mapping file as specified by the client's interface or because the attempted operation will fail (unable to find required metadata). In the case where the mapping file is used for simple mirroring, and the interface is simply the presence of a mapping file on the filesystem, the user may be unaware that the metadata they use is not coming from the source they expect. This should be solved by clear messaging around the source of the metadata during updating operations. Additionally, any targets downloaded under these assumptions still have the full guarantees of TUF metadata in general.

Because TAP4 does not address any security flaws, it is safe to allow old and new clients to coexist for a time.

TAP 5

Current Backwards Compatibility Section:

This specification is not backwards-compatible with clients that do not recognize TAP 5, because the changes to the root and snapshot metadata file has implications on how metadata files are downloaded. However, note that it should take very little effort to incorporate these changes with an existing implementation.

New Backwards Compatibility Section Proposal:

This TAP is backwards compatible with the previous version of TUF.

Unaware clients (that is, clients that don't understand TAP5's changes) will not understand the URLs field and will either fail or ignore it. If they ignore it, all metadata files will be fetched from the same repository as root.json, after which the target file will either exist in the metadata or fail to be found. If it succeeds, then the client may be putting more load on the repository than intended (by ignore mirrors listed in URLs) or it may be served a different version of the target (with the same name). If it fails, then the target was not found, and the URLs were used to serve alternate metadata, and a client failure is appropriate.

Aware clients will see metadata without URLs as existing in the same repository as the root file, which is the same as the pre-TAP5 case. Aware clients can ignore the root hash, if it exists in the snapshot file, so they will continue to work with repositories that publish data under the pre-TAP format.

Because TAP5 does not address any security flaws, it is safe to allow old and new clients to coexist for a time.

@trishankkarthik @JustinCappos (please loop in anyone else that may be interested, just didn't want to spam everyone)

Review the current and proposed backwards-compatibility sections for TAPs 3, 4, and 5, comparing pre- and post-TAP behavior for clients and servers. Done means each TAP clearly states compatibility, failure cases, coexistence safety, and the implications of fields such as name/names, mapping.json, and URLs.