We already had this as an inhibit, but this was not translated client-side.
We also need to propagate the problem to the bootloader device if the device
replugs during firmware update.
Some front end clients are going to be allow-listing updates based on what
the release was tested on, or by who the testing team was.
Export this data from each report when requested.
Recently we had an update that changed the system-defined Platform Key, and
we've certainly had updates in the past that changed the Boot#### variables.
Store some core ACPI and UEFI system integrity state from before and after the
update which can be used to mark (waivable) test failures on the LVFS.
If a specific plugin calls fu_plugin_set_secure_config_value() and then
fu_plugin_set_config_value() then we'll save the file with the world-readable
permissions.
Set a plugin flag to say that 'this plugin is storing sensitive details' which
allows us to use the same entrypoint and also fix up any files at startup that
do not have the correct permissions.
These are currently used interchangeably since there was indecisiveness
which to use as the feature was being developed.
As outward facing it will be named with "settings", change all uses
in the code to match this.
The only information that is secret is the `current_value`.
Augment the d-bus call to determine whether the caller needs this
information.
* If `fwupdmgr` is launched as root it will be provided.
* If `fwupdmgr` is launched with `--authenticate` it will be requested
and PK will be engaged.
This allows us to load sets of different host security attributes
for testing the various front end tools we have now. e.g.
sudo FWUPD_HOST_EMULATE=thinkpad-p1-iommu.json.gz fwupd
or, using a non-compressed absolute path:
sudo FWUPD_HOST_EMULATE=/tmp/test/thinkpad-p1-iommu.json fwupd
Data can be created with `./contrib/generate-emulation.py file.json`
and then can be manually modified if required. Running the script on
a file that already exists will just strip out any unneeded data, as
well as piping content into it using stdin.
As a precaution, the org.fwupd.hsi.HostEmulation attribute is added
so we do not ask the user to upload the HSI report. It also allows
the LVFS to ignore any HSI reports with this attribute for clients
that upload HSI reports regardless.
See https://github.com/fwupd/fwupd/discussions/4832
This allows us to make smarter policy decisions in the future on when
to show unavailable updates. It also means we can show translated
text in the frond-end clients.
Only problems the user can "fix" are enumerated. For example, opening
the laptop lid, or charging the device battery.
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.
Note that g_assert() should not be used in unit tests, since it is a
no-op when compiling with G_DISABLE_ASSERT. Use g_assert() in production
code, and g_assert_true() in unit tests.
See https://github.com/fwupd/fwupd/issues/3790
The "return error and hope the client resubmits the firmware again"
pattern is clunky. There are two plugins doing this now, and about to
be one more.
This adds FwupdRequest which provides a structured way of asking the
user to perform an action, e.g. to replug the device or to press a
special key or button.
This replaces much of the UpdateMessage and UpdateImage API although
it is still used internally. Clients capable of processing the new
DeviceRequest signal should add REQUESTS to their feature flags.
Also, this allows us go back to the old meaning of _NEEDS_BOOTLOADER,
which was "needs rebooting into a bootloader mode" rather than the
slightly weird "user needs to do something and resubmit request".
Add a suffix to any GUIDs that are currently unconverted InstanceIDs.
This makes plugin development much easier as you can now see why GUID
quirks in the subclassed ->setup() are not matching.
