Why filenames instead of rolenames in snapshot?

[trishankatdatadog]

Previously, we used to allow metadata files nested inside directories, which explains the following text in the specification:

   METAFILES is an object whose format is the following:

       { METAPATH : {
             "version" : VERSION,
             ("length" : LENGTH,)
             ("hashes" : HASHES) }
         , ...
       }

   METAPATH is the file path of the metadata on the repository relative to the
   metadata base URL. For snapshot.json, these are top-level targets metadata
   and delegated targets metadata.

However, I don't think we need METAPATH anymore. Instead, all we need is to list valid targets rolenames instead, correct?

[lukpueh]

But that would require the client to have implicit knowledge about the used file tree, name and extension convention on the repository, wouldn't it?

[trishankatdatadog]

But that would require the client to have implicit knowledge about the used file tree, name and extension convention on the repository, wouldn't it?

I think it's fair to assume that it does, no?

[lukpueh]

To some extent yes. Though I'm a bit hesitant in regards to the extension, given that it is usually determined through the metadata format and we are working on a spec change that adds a payloadType, which would allow the client to be oblivious to the format until the metadata is retrieved.

[trishankatdatadog]

To some extent yes. Though I'm a bit hesitant in regards to the extension, given that it is usually determined through the metadata format and we are working on a spec change that adds a payloadType, which would allow the client to be oblivious to the format until the metadata is retrieved.

I haven't been following the signing-spec closely, but do we expect a repository to host the same metadata in different data transport formats?

[trishankatdatadog]

Also, in Uptane, the notion of files is altogether problematic, and as much as we can avoid details of filesystems, the better.

[lukpueh]

... do we expect a repository to host the same metadata in different data transport formats?

Probably not. It's just something to think through. Should the client provide a setting for the "role name to metadata filename" conversion? Or should it be inferred from the root metadata payload type? Etc...

Btw. we don't only use METAPATH in snapshot but also in timestamp, but that probably doesn't change anything about the argument. Just something to keep in mind.

Also, in Uptane, the notion of files is altogether problematic, and as much as we can avoid details of filesystems, the better.

That makes sense, although that could also be seen as argument for something more generic like URIs, but not necessarily less specific?

[jku]

After implementing both client and some repo side tools, I still ask the question in the title... Even though all my work has been completely based on normal files, I've never had any benefit from the meta keys being filenames. Instead I have had to add code like filename = f"{role}.{ext}" in places that logically should not know about the specific file format, let alone the file extension that is used.