@kevinior Setting storepath=https://something.com/store/key=0815 will not be sufficient for your use case?

If storepath is set explicitly, there is no concatenation happening as you can see in the code snippet you referenced

Thanks for the quick response.

The problem with setting storepath is that we'd have to rewrite the RAUC system configuration file every time we did an update. A better option would be if we could override storepath from the command line: rauc install --storepath=https://something.com/store?key=0815. And that I should be able to patch myself.

Although casync seems to discard queries from URLs, so we'd have to fix the backend anyway to work with URLs like your example (key in path).

In general I'm a bit allergic to messing around with URLs without using a proper parser, I've been burned too many times.

@kevinior since we have the new D-Bus installation API allowing to pass new arguments on installation to the service, having an argument to pass it the storepath per-call either form any D-Bus client or from the rauc client itself (via --storepath) should be an option, yes.

RAUC itself tries to interpret URLs as little as possible (so we just use the scheme parser from glib) and forward it to casync or libcurl. The attempt to append .castr is just a convenience oversimplification for specific use cases. I'd tend to say that most will require to configure this, anyway.

For the casync way of handling URLs that's probably something one needs to fix there, yes.

OK, thanks for the information. I'll try to submit a pull request for overriding storepath from the command line.

If you don't mind I'd like to keep this open for reference and would ask you to put a "Fixes #606" in your commit that will both allow linking to this Issue as well as automatically closing it on merge.

@ejoerns I finally got round to creating a pull request for this. codecov seems unhappy with it but I don't know what the project's policy about test coverage is. Should all newly-added code have 100% coverage?

Developing tests that need to run in QEMU is a bit tricky since I'm forced to develop in Windows Subsystem for Linux (v1, not even the decent version) and running the tests in QEMU on top of WSL takes approximately forever.

I'd like to have a view on this from a security perspective before, as changing the store location could be a potential attack option if casync does not verify the data downloaded.
There is no very strict policy on coverage, but changes should be covered by tests if possible with manageable effort.