5.6.7 role not in snapshot

[Martin Harriman]

Section 4.4 File formats: snapshot.json: "It MUST list the version numbers of the top-level targets metadata and all delegated targets metadata."

Section 5.6.7 search for metadata: "if any metadata requested in steps 5.6.7.1 - 5.6.7.2 cannot be downloaded nor validated, end the search and report that the target cannot be found."

I presume then that a client MUST NOT report the non-conformant snapshot.json, and instead MUST report simply target-not-found. I believe the conformance test does present a delegation to a role not present in snapshot.json in its fast-forward-recovery test. If the conformance client throws an error, the conformance test fails.

Is this intentional? If so, would it be better to make section 4.4 "it SHOULD list the version numbers for all delegated targets metadata"? Or should it be acceptable for the client to throw an error if there are delegated roles not present in the snapshot?

Thanks!

  Martin Harriman

[Trishank Kuppusamy]

Good question, Martin!

I do believe the client MUST throw an error if there is a delegated role that is not present in the snapshot, and the client is looking for a target that has been delegated (especially when terminating) to this role.

Does this make sense to everyone?

--
You received this message because you are subscribed to the Google Groups "The Update Framework (TUF)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to theupdateframew...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/theupdateframework/3ef713c2-72fc-484a-81fd-97d706c13250n%40googlegroups.com.

[Justin Cappos]

When terminating, I think this is clearly true.   

Are there any cases where a repo would let users delete their targets files?   I can't think of a reason to do this, but given leftpad, etc. I'm not sure if operationally this will always be true.

To view this discussion visit https://groups.google.com/d/msgid/theupdateframework/CAEd-exNG6SXQLg51iZOXHe-vP0cJ4iqFkK-WZB9bgGrP64T9qA%40mail.gmail.com.

[Martin Harriman]

The fast-forward escape in 5.3.11 allows a repository to rewrite history and in effect do a sanctioned rollback on itself by deleting any saved timestamp and snapshot knowledge in the client. Without that escape, 5.5.5 requires that any role present in snapshot version N be present in each subsequent snapshot, so deleting a formerly-present role would be rejected and reported as a rollback attack.

For 5.6.7, the distinction in language for a delegated role may not be significant. I don't know that there's any practical difference between "report the failure" (in sections 5.6.1 through 5.6.6) and "report that the target cannot be found" (in section 5.6.7).

[Trishank Kuppusamy]

On Mon, 16 Dec 2024 at 13:28, Martin Harriman <larv...@gmail.com> wrote:

For 5.6.7, the distinction in language for a delegated role may not be significant. I don't know that there's any practical difference between "report the failure" (in sections 5.6.1 through 5.6.6) and "report that the target cannot be found" (in section 5.6.7).

Makes sense to me, yes: no real distinction. 

[Trishank Kuppusamy]

On Sat, 14 Dec 2024 at 20:58, Justin Cappos <jca...@poly.edu> wrote:

Are there any cases where a repo would let users delete their targets files?   I can't think of a reason to do this, but given leftpad, etc. I'm not sure if operationally this will always be true.

Some package repositories allow developers to yank specific package releases / versions without actually deleting them.

I imagine some of them do allow you to outright delete them if you so wished.

Some package repositories also allow you to unpublish / delete entire projects (entire collections of package releases/versions) altogether.