send_download_authentication option not respected in streaming mode

[b4u-mw]

The send_download_authentication configuration option is not respected when using stream_bundle=true. The authentication header is always passed to RAUC regardless of the send_download_authentication setting.

In start_streaming_installation() (hawkbit-client.c, line ~1090), the auth_header is unconditionally assigned:

.auth_header = auth_header,

Compare this to get_binary() (line ~405) where the option is correctly checked:

if (hawkbit_config->send_download_authentication &&
    !set_auth_curl(curl, &headers, error))
        return FALSE;

Suggested fix:

.auth_header = hawkbit_config->send_download_authentication ? auth_header : NULL,

[Bastian-Krause]

Yes, currently send_download_authentication = false has an effect only in download mode (stream_bundle = false), hence the name. I guess it could also influence the streaming behavior as outlined, as long as we document that properly. PR welcome!

[b4u-mw]

PR welcome!

There you go.

I have added "and streaming" in the docs. Otherwise the doc seems clear to me and does not exclude streaming (which is also a kind of "download request" IMO - but I'm not so familar with your domain language).

[b4u-mw]

For Cross-Reference I link UpstreamDataInc/goosebit#400 here.

Together with this PR I'm able to deliver casync rauc images directly from a fileserver (protected by basic auth) to IoT devices. Goosebit sends the URL containing the credentials. Rauc first streams the minimal bundle, then resolves casync index relative to this URL and passes the whole URL including the credentials to casync. So no need to put credentials or absolute URLs into raucb images.

The only remaining issue: when an error occured, the while URL (including credentials) is logged back to the hawkbit server. Would you be open for a PR that masks this in the logged URL?

[jluebbe]

Perhaps only slightly related... Why do you prefer to use casync instead of adaptive updates via streaming?

[b4u-mw]

Perhaps only slightly related... Why do you prefer to use casync instead of adaptive updates via streaming?

Because we have NAND + UBIFS on that device which does not support adaptive streaming.

I also found that Casync with file based hashes results in very small delta updates and it allows to use the old rootfs as seed (I think rauc delta uses the target device as seed on an a/b setup). I'll check later on our newer devices (with eMMC + ext4) how the results are between rauc adaptive and casync.

[jluebbe]

Perhaps only slightly related... Why do you prefer to use casync instead of adaptive updates via streaming?

Because we have NAND + UBIFS on that device which does not support adaptive streaming.

Ah, yes. It would be possible to implement adaptive streaming for UBIFS images with out too much difficulty. Without doing experiments, I can't say how large the download would be, though.

I also found that Casync with file based hashes results in very small delta updates and it allows to use the old rootfs as seed (I think rauc delta uses the target device as seed on an a/b setup). I'll check later on our newer devices (with eMMC + ext4) how the results are between rauc adaptive and casync.

OK. Note that adaptive updates can reuse data from all slots of the same class (e.g. both rootfs slots). If really small update size (i.e. via binary patches) is interesting to you, we should talk directly, as we have some ideas what could be done. :)

[b4u-mw]

If really small update size (i.e. via binary patches) is interesting to you, we should talk directly, as we have some ideas what could be done. :)

Let's do this. But what about this PR? I think this is unrelated.