- Status: accepted
- Date: 2021-04-08
Technical Story: #1266
The current reference implementation will ignore unrecognized fields in a metadata file when loading it. This leads to the side effect that if you read a metadata file with unrecognized fields and immediately write it back to the disk, this file will be modified.
Furthermore, some TAPs like:
are relying on that unrecognized fields will be accepted to introduce new fields to the specification without making the metadata invalid for older clients who don't recognize the field.
- The TUF specification implies support for unrecognized attribute-value fields, see Document formats
- If we perform the following operations on a metadata file with no intermediate operations:
- read the metadata file
- write the metadata file back to the disk
then, the checksum (the content) of the file must not be changed.
- Flexibility to add new fields in the spec without adding breaking changes.
- Don't store unrecognized fields when it is not allowed by the specification.
- Ignore and drop unrecognized fields.
- Ignore, but store unrecognized fields as an additional attribute.
- Ignore, but store unrecognized fields as an additional attribute except for a couple of places where it's not allowed by the specification.
Chosen option: "Ignore, but store unrecognized fields as an additional attribute except for a couple of places where it's not allowed by the specification." The motivation for this decision is that the TUF specification already implies that we should accept unrecognized fields for backward compatibility and easier future extensibility.
Additionally, it seems unacceptable to change a metadata file content just by reading and writing it back.
There are exceptions however for places in the metadata format when it is not
allowed by specification: keys, roles, meta, hashes, and targets are
actual dictionaries (vs JSON objects that most structures in the format are)
where unrecognized field
is not a meaningful concept.