Is the TUF target path separator always "/"?

[erickt]

I noticed that in 4.4.5 spec defines as TARGETPATH:

Each key of the TARGETS object is a TARGETPATH. A TARGETPATH is a path to a file that is relative to a mirror's base URL of targets. It should not have a leading path separator to avoid surprising behavior when constructing paths on disk.

Presumably this should be /, it says it's a file relative to the URL, and URLs use that as the path separator, but it'd be helpful if this was explicit.

This is relevant because in rust-tuf, we have a PathTranslator in order to use alternative path separators to support converting / to \ on windows, but I'm pretty sure this logic really should be moved to our FileSystemRepository.

[lukpueh]

Thanks for submitting this issue, @erickt. AFAIK TARGETPATHs are always unix-style paths with forward-slash path separators. And I can confirm that the reference implementation converts \\ to / when adding target paths to tuf metadata (in the repository tool). Do you want to submit a PR to clarify this in the spec?

[trishankatdatadog]

This really shouldn't be mandatory. / and \\ should both be allowed.

[erickt]

@trishankatdatadog Just to be safe, are you suggesting the targets role metadata should allow for both / and \\ path separators? Or that client libraries should internally map \\ to / before trying to fetch a target, but the metadata should use / as the path separator?

If we support \\ as separators in the metadata, then we could run into some confusing errors if a windows client tries to download a target foo\\bar, but to actually fetch the target, we can't just naively concatenate the mirror URL with the target path.

[trishankatdatadog]

My opinion is that the specification should be tolerant enough to accommodate both UNIX and Windows file separators. (You know never know what you're going to find out there.) It is up to the implementation to correctly handle file separators across platforms. WDYT?

[lukpueh]

I think you're right, @trishankatdatadog, it may not be necessary to make this mandatory. But it's probably still a good idea for an implementation to normalize paths to unix style for the reason that @erickt has mentioned, and also to behave unsurprisingly when expanding unix shell-style wildcards as the we do in delegation path patterns (see spec#L877-L878).

The metadata examples exclusively use forward-slashes. Is it worth adding a recommendation?

[trishankatdatadog]

@lukpueh Yes and yes, please

[erickt]

I personally vote for us standardizing on the target path to be the URL spec's path relative url string, since presumably all OSs should have some mechanism for resolving a file:// path.

Otherwise, if we allow different path separators, then we run into ambiguity with a target path foo\bar. If we try to naively open that on linux, it will try to open a file named "foo\bar". On Windows though, it'd open the file "bar" in the directory "foo". Things would get even more confusing if someone tries to store a target path using some of the other Windows path formats, like "\\.\UNC\LOCALHOST\c$\foo\bar".