clarify paths vs path_hash_prefixes (once more)

[jku]

There was an attempt to clarify paths vs path_hash_prefixes use in delegations (4.5) a few months ago but it looks like the result is still not quite finished:

The "path_hash_prefixes" and "paths" attributes are OPTIONAL, if used, exactly one of them should be set.

both fields are defined as optional yet it's undefined what happens if neither is set. Currently python-tuf Metadata API is actually not spec compliant: it requires one or the other field to be set: if neither is set, that's an error.

This seems to require a spec clarification and there seem to be two possibilities:

• spec should require either "path_hash_prefixes" or "paths" to be set OR
• spec should define what it means if neither is set

I don't have strong opinion but would like a decision. There is an obvious use case for the latter option: If paths and path_hash_prefixes are unset, then everything is delegated:

• This is a use case for pypi for example: they want a "targets" delegating everything to "bins".
• There is no obvious way otherwise to delegate everything (as paths=["*"] does not delegate paths with directory separators)

[JustinCappos]

I'm a little concerned that if path_hash_prefixes and paths is omitted, it isn't immediately obvious by reading the resulting targets file that this should be delegating everything. I would prefer some other, more explicit way to do this.

[joshuagl]

+1 on an explicit mechanism.

For context, the way this used to work in legacy python-tuf is that a * wildcard would delegate everything (as used in the initial Warehouse TUF initialisation work).

However, we recently amended the spec to state that PATHPATTERN strictly adheres to glob-like behaviour and, therefore, a * will not match path separators (see https://github.com/theupdateframework/specification/commit/6fffd3696eaf5fe86cb6ec7d132898a47b0c1bbf).

[trishankatdatadog]

Agree: explicit >> implicit for security