Confirm terminating roles logic from spec

In https://github.com/php-tuf/php-tuf we are making sure we have the logic correct around terminating delegations. As we have updated our implementation of the spec from v1.0.9(the release when we started) to the most recent releases we have notice there has been some changes to wording in this area of the spec.

To make sure we get the logic correct for terminating delegations I have created this simple example to make sure our assumptions are correct(actually we don’t all have same assumptions these are mine)

Constraints

term = terminating delegation non-term = non terminating delegation Priority: The roles in each level are ordered from left to right in the order they would appear under [delegations][roles] All roles have paths = [‘assets/*’] (just to provide matches for every role only focus on terminating logic now) Target being searched for = 'assets/always-match.txt’

Expected outcome

Expected role evaluation: Targets -> A > B > C > D

Am I correct?

[tedbow]

Thanks everyone for the confirmation. I working on fixing our implementation increasing our test coverage for different cases here https://github.com/php-tuf/php-tuf/pull/216

If anyone is interested we test our client implementation by creating test fixtures with a FixtureBuilder that uses the Python server implementation. For example here is 1 for that PR that creates the above test case https://github.com/php-tuf/php-tuf/blob/tedbow-fix_terminating_2/fixtures/TUFTestFixtureTerminatingDelegation/__init__.py (BTW @phenaproxima and myself are learning python to create these test fixtures so don’t expect great python code 😁)

We then make test case for a given test fixture and given target, whether it should be found and which metadata files the client should retreive/evaluate to determine this. Like this case for role “F” in the example not finding a target because of terminating delegation in “B” https://github.com/php-tuf/php-tuf/blob/tedbow-fix_terminating_2/tests/Client/UpdaterTest.php#L653

[mnm678]

The spec states that

A terminating delegation for a package causes any further statements about a package that are not made by the delegated party or its descendants to be ignored.

Which by a literal reading does contradict TAP 3. I don’t think TAP 3 is supported by 1.0 of the specification, but this is something we should figure out before adding it.