This is required when the calling application needs the low-level soup-session
with the user agent set correctly rather than using the helper methods like
fwupd_client_download_bytes().
This is what GNOME Software needs to handle the GsApp progress completion.
If a system is configured without any downloadable remotes (e.g. with
a remote pointing to a local directory) the call of
fwupdmgr get-updates
fails by outputting "No remotes enabled." even though the call
"get-remotes" clearly shows the configured remote.
I found the following commit:
commit 991c95697e
Author: Mario Limonciello <mario.limonciello@dell.com>
Date: Wed Jun 17 15:23:13 2020 -0500
trivial: fu-util: correct an assertion when no remotes configured
introduced the problem. In the call chain:
fu_util_get_updates
-> fu_util_perhaps_refresh_remotes
-> fu_util_check_oldest_remote
the function fu_util_check_oldest_remote now returns FALSE if no
remote of kind FWUPD_REMOTE_KIND_DOWNLOAD is found.
The function fu_util_perhaps_refresh_remotes then returns FALSE
indicating failure even though without a downloadable remote the
concept of refreshing is not useful.
I think, we should return TRUE in this case, as no refresh is needed
and the operation can continue.
As the failure of fu_util_check_oldest_remote is ignored we also need
to pass NULL as error pointer here.
The use-case of this scenario without downloadable remote is by
distributing firmware updates through software updates where the
vendor directory with the capsule file is provided.
The I²C proxy specification is not always shared with all other devices as
I originally hoped, instead there are other legacy devices that use different
sets of I²C commands.
Un-share various bits of code to allow for additional I²C devices to be added.
No logic changes.
This takes care of downloading the correct files and allows remotes to be
refreshed from other CLI and GUI tools without copying large chunks of code.
This also allows us to download the metadata without writing two temp files
to the users cache directory. Although not security sensitive, it's probably
not a good idea if we can avoid it.
Write the firmware to the usb device, first finding which section to
write to, then breaking into blocks (based on maximum pdu size),
and then into chunks, which are transferred to the device using bulk transfers.
The logic here is that we can use one central session for all client actions.
Also, set the user agent for the *runtime* version of fwupd -- it's the runtime
version we use when checking capabilities, rather than the built-against
version. This would also explain why there are so many very obsolete versions
of fwupd being recorded on the LVFS...
At the moment at startup we're calculating the attrs so we can export the HSI
string property on the D-Bus interface. Running `fwupdtool security` actually
gets all the security attributes at least twice!
