Tap14 updates

[mnm678]

I updated TAP 14 based on some implementation questions from @abs007.

This replaces references to the now-rejected TAP 5 with TAP 13 and adds a new optional file to support a range of filesystem types.

[lukpueh]

LGTM modulo one type and a request for clarification (see inline)

[lukpueh]

I have an non-PR-related question about the following sentence in the TAP:

This allows them to differentiate between metadata that is expired due to deprecation and metadata that is expired due to an attack.

What does "expired due to an attack" mean?

[znewman01]

Ahh, sorry to be annoying. I just had a bunch of worries come up

[trishankatdatadog]

Thanks, Marina! My biggest concern is on why we need a signed supported-versions.json somewhere for repositories that don't support listing of what appear to files in what appear to be folders. Could we please consider simpler mechanisms?

[znewman01]

My biggest concern is on why we need a signed supported-versions.json somewhere for repositories that don't support listing of what appear to files in what appear to be folders. Could we please consider simpler mechanisms?

@trishankatdatadog I think that's most repositories. For instance, go-tuf only has built-in support for HTTP remotes, and IIRC python-tuf is the same, but HTTP doesn't have a (standard/uniform) way to list the contents of a directory. We ran into this when attempting to build out TAP-14 support in python-tuf.

We're open to alternatives suggestions, of course. The first thought was to stick an index.txt file in each folder, but if there's a lot of root metadata files that gets annoying really quickly. So then we decided to filter it down to just a list of folders containing supported versions, but v1.x.y is a funky special-case (do we call it 1/ or /) so we figured being explicit was better.

Signing is something that feels appropriate to me as a "better safe than sorry" thing. I think we could get away with not requiring it, but it feels nicer to me to have the roots sign off on something as consequential as a major version transition.

[JustinCappos]

FYI all, @marina Moore ***@***.***> and I had a nice chat about this issue and laid out the pros and cons. She's going to capture this in writing here so we have it for posterity. Let's wait for her analysis and then discuss further.

…

On Fri, Sep 30, 2022 at 11:28 AM Trishank Karthik Kuppusamy < ***@***.***> wrote: I don't think it's expected to be signed by the root role. Don't think of it as a metadata file, think of it as a hint. SGTM. Now the Q is: do we sign or not sign this hint? — Reply to this email directly, view it on GitHub <#158 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD4FIH4DAUUCTDKKRRLWA4BJJANCNFSM54W2DCEQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mnm678]

I wrote up the pros and cons in a google doc.

In summary, I agree with Trishank that this information can be included in existing TUF metadata.

Edit: I updated this pr to show what this would look like

[mnm678]

Can we get consensus on this approach from TAP maintainers? @JustinCappos and @trishankatdatadog have already looked. @lukpueh and @joshuagl wdyt?

[joshuagl]

Adding a field to root metadata feels like a more appropriate path forwards. 👍

[lukpueh]

Unrelated observation about this paragraph:

For example, during the course of an update a client could use 4.0.0_parse_root, 4.0.0_parse_snapshot, 4.0.0_parse_timestamp, 4.0.0_parse_targets, 4.0.0_parse_delegation, and 3.0.0_parse_delegation.

If the order of function calls should represent the course of an update, *_parse_timestamp should be before *_parse_snapshot.

[lukpueh]

Unrelated observation about this paragraph:

If the change adds a new feature that is backwards compatible, for example in TAP 4 and TAP 10 [...]

TAP 10 claims that it is backwards incompatible.

[lukpueh]

Ping unrelated observation from #158 (comment), cc @mnm678

[lukpueh]

Following a chat with @mnm678 and @JustinCappos, I just pushed a couple of minimal fixes for the concerns I raised. @joshuagl, can you green-light again?

[mnm678]

Based on discussion with @JustinCappos and @lukpueh I simplified the root metadata update mechanism in this TAP. The new mechanism allows the root version numbers to diverge between specification versions without compromising the security of an upgrade. I will update the PoC shortly to reflect this change.

[JustinCappos]

Thanks for the hash / supported_versions change to the text. Looks ready to me.

[trishankatdatadog]

LGTM to merge as draft for now, please do address my comments as we discussed earlier:

• The unclear benefits of becomes_obsolete at the expense of added complexity (e.g., delegatees could accidentally create conflicts)
• If we keep becomes_obsolete, clarify whether it uses the same datetime format as expires
• Clarify that root rotation is done as before this TAP for the current known MAJOR spec version before looking at (the latest) supported_versions
• Clarify whether a root metadata file refer to MAJOR versions lower than or equal to the current spec_version in that file (and metadata version directory)
• There are only 3 cases for checking version numbers: <, =, or >. The current text is ambiguous about the < case. Please clarify.