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.
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
This functionality broke a number of releases ago as part of
implementing device inhibition and was just noticed now.
Instead of fixing it, the preference seems to be to remove the
functionality as it exists today as inhibitions can happen for
a number of reasons.
To still allow people to override these power warnings (such as during
development) add a new daemon configuration item that can be used.
Fixes: #3778
This allows us to do a few things:
* Remove the runtime dep on Python 3, which is tricky for ChromeOS
* Test composite devices more efficiently, only writing once per test
* Automatically upload signed reports for successful device tests.
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.
We want to provide a lot more in JSON format in the future, and this
will reduce a lot of code duplication.
As various people are using this in the wild, the existing fwupdagent
binary just shims requests to fwupdmgr as required. We'll stop doing
this for 2.0.0 or something.
On Alterlake and newer hardware the Platform Health Assessment Record
data can be used by the IHV to debug why a specific capsule update
failed. Any custom firmware loaded by the OEM can be identified and
used to further debug the root cause.
This can be used like this:
fwupdtool firmware-sign firmware.cab rhughes_signed.pem rhughes.key
Test signing certificates can be generated using the example script here:
https://github.com/hughsie/libjcat/blob/master/contrib/build-certs.py although
these certificates should not be used for enterprise use.
