It seems uuid_parse() doesn't check the string length before unwrapping the
string into a struct. Fixes:
Conditional jump or move depends on uninitialised value(s)
at 0x4E0C358: uuid_is_null (isnull.c:44)
Some firmware has a different on-device checksum to the hash of the firmware
file itself. This may be because:
* The content is not a binary file, e.g. Intel HEX or SREC
* Only part of the firmware is flashed, e.g. ignoring the bootloader section
* The device checksum is calculated using another method entirely, e.g. PCR0
It's also made complicated as there may be more than one 'correct' device
checksum in some cases, but nothing that a union query can't solve.
We can't actually access the UEFI ROM from userspace, but the PCR0 is a hash
built from the ROM itself. We could use this value to ensure the firmware has
been written correctly, and that the PCR0 matches the expected value specified
in the metadata.
Future metadata from the LVFS will set the protocol the firmware is expected to
use. As vendors love to re-use common terms like DFU for incompatible protocols,
namespace them with the controlling company ID with an approximate reverse DNS
namespace.
This also allows more than one plugin to define support for the same protocol,
for instance rts54hid+rts54hub and synapticsmst+dell-dock.
This solves issues with implementations that require 4k alignment
of pages in BIOS which is seen on certain architectures.
The UEFI spec prescribes that the "minimum" size is the size of
the EFI header but that this may be increased up to larger sizes
due to extended header entries.
This mirrors the update process over DP aux to run the ESM update
first.
The thought process is as follows:
The "version" displayed doesn't show ESM version, only standard
bank version.
So if the update fails for the ESM then because the update of the
standard happening first it would never be flashed.
`g_ascii_strtoull` returns 0 and sets `errno` to `-EINVAL` only when
the base is invalid. It's hardcoded to `16` so this is impossible.
Reading `-EINVAL` from `errno` is incorrect in these circumstances.
Fixes: https://github.com/hughsie/fwupd/issues/879
This makes startup quicker as we no longer have to probe every USB device, and
is now possible with the new GUIDs we added. Devices not using the
specification-provided values can (and already are) worked around with quirks.
The LVFS has always sent components with the old-style '<metadata>' section
rather than the new-style '<custom>' section, and when using appstream-glib
we just accepted either element name. Although the LVFS has just been fixed to
use the new name, old metadata might be present on the system already.
When all clients have downloaded new metadata we can revert this, perhaps in a
couple of weeks time. Until then, the belt-and-braces approach is probably a
good idea.
Fixes https://github.com/hughsie/fwupd/issues/874
The client uses GObject introspection to use the libfwupd2 library.
The client offers a reduced set of commands, but may be useful in some
environments.
This allows plugins to load an archive supplied as the 'deliverable' of the
cabinet archive. This means plugins can bundle up a set of images in a cross
platform way, for instance adding boot.img+os.img+manifest.xml into a zip file,
rather than having to (ab)use the DfuSe file format or deal with libarchive
directly.
