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.
This allows for proper locking between executions of fwupdtool in
Chromium OS minijail environment. It is needed after commit
9cf5f8f7ff was introduced.
Change-Id: I37b33c8d1fbe97ec9baddc5f77ea94e2f4ff1fa4
This allows plugins to set the battery power state of the *machine* which means
we can automatically inhibit devices with FWUPD_DEVICE_FLAG_REQUIRE_AC set.
It also allows to set the BatteryThreshold to 25% for Lenovo hardware, and we
can override other vendors with further quirks as required.
Fixes https://github.com/fwupd/fwupd/issues/3084
This makes a lot more sense; we can parse a firmware and export the same XML
we would use in a .builder.xml file. This allows us to two two things:
* Check we can round trip from XML -> binary -> XML
* Using a .builder.xml file we can check ->write() is endian safe
Keeping *internal* API and ABI compatibility makes working with an already
complex codebase more mentally demanding than it needs to be.
Remember: plugins should be in-tree and upstream! If your out of tree plugin
stops working then it should be upstream.
The public-facing libfwupd will remain API and ABI stable for obvious reasons.
It is impossible to choose a static default that is appropriate for both a tiny
ARM IoT device and a giant Xeon server.
Fixes https://github.com/fwupd/fwupd/issues/2760
This is a safer version of g_bytes_new_from_bytes() which returns a GError
if the offsets are invalid rather than emitting a critical warning.
This prevents a critical warning and potential crash when parsing invalid
bcm57xx firmware.
The GLib g_byte_array_set_size() function does not zero the contents if the
array size is larger, which leads to unpredictable output when using valgrind.
