fu_engine_install_blob may result in the device being reset during attach or
detach and needing to be replugged.
The device handle we're holding may be stale, but it is still used by the do
while loop itself for the ANOTHER_WRITE_REQUIRED test.
Similar to the other functions in the loop, let's get the device handle by id
in case that happened.
Original patch by Benson Leung <bleung@chromium.org>, many thanks.
Fixes https://github.com/fwupd/fwupd/issues/2297
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.
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.
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!
At the moment we just blindly assume the capabilities of the front-end client
when installing firmware. We can somewhat work around by requiring a new enough
fwupd daemon version, but the client software may be older or just incomplete.
This would allow, for instance, the firmware to specify that it requries the
client to be able to show a detach image. This would not be set by a command
line tool using FwupdClient, but would be set by a GUI client that is capable
of downloading a URL and showing a PNG image.
Clients that do not register features are assumed to be dumb.
The idea here is that we can show the user both a string and an optional
line-art image when the update has completed. The line art is often more well
understood for non-English speakers.
This means we only parse the complicated xpath query once, rather than for
every GUID the device has.
The code flow is also simplified and split out into two functions.
Newer versions of libxmlb do not auto-cache XbNodes, and we have to opt-into
this beahviour for the _set_data() and _get_data() to work.
Although this is a behaviour change which also increases complexity, it lowers
our RSS usage by 200kB which is about a quarter of the total RSS used...
fmap is a Google flash layout format that is used in several of Google's
firmware projects, including Chrome OS Embedded Controller and the Chrome OS
coreboot firmwares. Introduce it as a firmware format in libfwupdplugin.
Add two new vfuncs that can be used to collect report metadata from devices
both before and after the update has run. This means we can remove the hacks
where we set add 'global' metadata entries and just hope that there is only one
device from the same plugin that is updated.
This also allows us to collect debugging metadata from devices after an offline
update has been run.
When verifying a signature the valid results are ordered by timestamp. The
CHECKSUM results have a zero timestamp and should have been ordered last.
The sorting callback was wrong, which explains the odd result where we could
downgrade Jcat signatures before we fixed 64ebf9, and nicely explains why we
ignored a timestamp of zero in the first place.
When getting the timestamp, ensure we actually get the newest _signature_ not
just the newest result in case checksums start having timestamps in the future
for some reason. Use new API from libjcat where available, else fall back to
sneaking it out using GObject properties and magic values.
