The only users of `SERIO\FWID` and `I2C\NAME` are already 'safe' and
the device GUIDs should all be unchanged.
There are no current users of the `MTD\NAME` instance IDs, and these
are the ones that may be more unpredictable and in need of sanity.
Most vendors do not mirror the firmware update to an external display,
and some don't behave correctly when the lid is shut and the machine is
docked. Add this quirk just for Lenovo for now.
Fixes https://github.com/fwupd/firmware-lenovo/issues/181
A UF2 device exposes a VFAT block device (sometimes called a Mass
Storage Device) which has a virtual file called `INFO_UF2.TXT` where
metadata can be read. It may also have a the current firmware exported
as a file called `CURRENT.UF2` which is in a 512 byte-block UF2 format.
Writing any file to the MSD will cause the firmware to be written.
Sometimes the device will restart and the volume will be unmounted
and then mounted again. In some cases the volume may not “come back”
until the user manually puts the device back in programming mode.
Match the block devices using the VID*PID, UUID or label, and then
create a UF2 device which can be used to flash firmware.
Note: We only read metadata from allow-listed IDs to avoid causing
regressions on non-UF2 volumes. To get the UUID and label you can
use commands like:
udisksctl info -b /dev/sda1
We now have 9 different plugins all using this functionality, and we're
about to add one more. Move this into common code so that all the
plugins are using the same endian and bufsz-safe versions.
The CRC32 and CRC16 algorithms have "full" functions that allow callers to
provide their own polynomial and initial CRC value. Provide the same ability
to users of the CRC8 algorithm.
Additionally, if the client does not set the feature flag `fde-warning`,
add an extra paragraph into the update description.
Fixes https://github.com/fwupd/fwupd/issues/3829
This moves the cached metadata location from /var/lib/fwupd/remotes.d
to /var/lib/fwupd/metadata
The former was a bad name as it wasn't a list of remotes, and .d is the
suffix for directories the user can install files into, rather than for
binary content managed entirely by the daemon.
Using fu_common_strnsplit() has the drawback that a malicious user (or
a fuzzer!) could create a file with 5,000,000 newlines, and then pass
that into any parser that tokenizes into lines. This causes millions of
tiny allocations and quickly dirties hundreds of megabytes of RSS due
to heap overheads.
Rather than splitting a huge array and then processing each line, set
up a callback to process each line and only allocate the next string if
the token was parsed correctly. This means that we don't even dup the
buffer before we start parsing, rather than allocating everything and
then failing at the first hurdle.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=38696
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.
