ngclient: downloading targets fails if targetpath includes subdirectories

[jku]

ngclient has so far copied the legacy client decision of downloading files to the same directory structure as the repository uses. It has however removed the code that creates the directory structure.

So downloading any targets with paths like "path/to/file" will fail because the local directories do not exist.

[jku]

I think this is actually a good time to get rid of this idea of using target paths as local path with directories (as it has several issues, not just that we don't create the subdirectories)... I'll take this

[jku]

We might want to fix this with #1412
#1412 (comment)

[jku]

I have a branch but this is in practice blocked by #1587 : The legacy tests do not include any targets with sub directories (!) and I can't be bothered to add them, will wait for #1587.

I also suppose this one makes #1576 trickier to test (as the downloads just won't work).

[MVrachev]

I think this is actually a good time to get rid of this idea of using target paths as local path with directories (as it has several issues, not just that we don't create the subdirectories)... I'll take this

@jku I am sorry I created a commit before reading this issue and noticing you are assigned to it.
I created one commit possibly solving that issue: 6f108c9, but the question remains do we want
to further support targetpaths as local paths.

What other do you mean besides this one if we consider targetpaths as local paths?

[jku]

@jku I am sorry I created a commit before reading this issue and noticing you are assigned to it.
I created one commit possibly solving that issue: 6f108c9,

That's fine, I'm sure you needed to do something to test -- and we are annoyingly touching the same bits of code. We'll see how bad the merging/rebasing gets...

but the question remains do we want to further support targetpaths as local paths.

I don't want to create local directories based on a URL -- a specific TUF implementation might know that is a reasonable thing to do but I don't think the library can know that. I'm suggesting we use the whole target path (url encoded) as a filename, and then also offer a way for the client application to decide the filepath themselves (so if the client knows using target path as path is safe, it can create the directories).