This allows us to override the location we load data files from, which
allows us to do more kinds of installed tests in the future.
Also, move the global data/tests content into the place that it is used
as it was getting impossible to manage.
Now two plugins are using hardcoded SPI constants for various CFI chips,
and it makes sense to have some common quirk data that can be used by
both.
Add a FuSpiChip helper object that can be used by FuDevice subclasses
to get the specific SPI commands to use for each flash ID.
This has not worked well in some time, and nobody noticed. The
alternative Google clusterfuzz support is better in every way and gets
run as part of CI.
In reality these are not super interesting as they only happen on
`->write()` and not `->parse()`.
In other news, the fuzzer now appreciates how critical the alignment
is, which is probably a good thing generally.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40088
This allows us to do the right thing if given an XML file with leading
or trailing space in the entry, e.g.
<value key=LVFS::UpdateProtocol> org.uefi.capsule </value>
This regressed in 1.5.5 when we migrated FWUPD_DEVICE_FLAG_MD_SET_VERFMT
into FU_DEVICE_INTERNAL_FLAG_MD_SET_VERFMT and forgot to copy the system
device internal flags.
There's no actual hardware to test this against yet, but this is how I
would lay out a plugin if there was.
We still need to work out a generic encapsulation for the offer and
payload (for each component and bank) so this can work with LVFS and
fwupd.
99.9999% of users are consuming firmware updates from the LVFS or
another trusted remote. It's far too easy to get a user to enter the
password to install an untrusted firmware, where the security
consequences are pretty dire.
Provide an escape-hatch for firmware engineers, but it does mean
editing a file in /etc as root. This seems like an acceptable level of
inconvenience.
This avoids clashing with real-world devices that have the same VID/PID.
Many thanks to Ricky WU <ricky_wu@realtek.com> for all the help.
Fixes: https://github.com/fwupd/fwupd/issues/3835
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
When coldplugging expensive servers with a huge number of Redfish
devices it takes about 30 seconds to start fwupd while we wait for the
BMC to return results.
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.
