Archives uploaded to LVFS will have checksums written by hexdigest
and be set to lowercase, but hand generated archives this may not
be true.
For maximum compatibility with the most fwupd versions they should
be written in lowercase, but in case they aren't, convert to lowercase.
Reference https://github.com/fwupd/firmware-lenovo-thinkpad/issues/145
All the other vfuncs have 'plugin, device, flags' but prepare and
cleanup vfuncs being 'plugin, flags, device' order has been triggering
my OCD for the last few years.
We've just broken the symbol names, so it's the right time to fix this.
More than one person has asked about 'why call fu_plugin_update() for a
reinstall or downgrade' and I didn't have a very good answer.
The plugin API is not officially stable, and we should fix things to be
less confusing. Use the same verbs as the FuDevice vfuncs instead.
The LVFS is now adding an artificial NUL to the metainfo data to work
around a possible buffer over-read on old fwupd versions. This breaks
new code that reads the XML buffer using xb_builder_source_load_bytes
as GLib then tries to parse the final NUL byte.
As `xmllint` actually ignores the trailing NUL, we should as well.
This was only true by accident. We'll need another fix for the LVFS to
add the missing NUL to restore compatibility for older clients.
Fixes https://github.com/fwupd/fwupd/issues/3533
The raw SMBIOS tables that Linux exposes in /sys/firmware/dmi
are restricted to being readable by root only. If running as
non-root access is still permitted by fields that have been
pre-parsed by the kernel in /sys/class/dmi, most of which are
world-readable. This allows the daemon to load most HWIDs even
if running as a non-root user, as is done on Chromium OS.
The benefit of using the proxy device is that we can 'use' the proxy
device for device access, but 'report' the progress on the passed
FuDevice instance.
This means the front-end reports the device status correctly when
updating composite devices that us proxies.
The comment always said we should move it to the daemon if another
plugin started doing this, and that is now.
I assume at some point we forgot to remove it when converting an object
from FINAL to DERIVABLE and the anti-pattern just got copied around the
codebase...
The "return error and hope the client resubmits the firmware again"
pattern is clunky. There are two plugins doing this now, and about to
be one more.
This adds FwupdRequest which provides a structured way of asking the
user to perform an action, e.g. to replug the device or to press a
special key or button.
This replaces much of the UpdateMessage and UpdateImage API although
it is still used internally. Clients capable of processing the new
DeviceRequest signal should add REQUESTS to their feature flags.
Also, this allows us go back to the old meaning of _NEEDS_BOOTLOADER,
which was "needs rebooting into a bootloader mode" rather than the
slightly weird "user needs to do something and resubmit request".
The kernel allows configuring this, and certain plugins will use this
path to be able to load firmware in the kernel driver through runtime,
but to flash to the device.
