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.
Saving the quirks in the GResource section worked well, but it made the build
system very complicated and also meant the .data section was duplicated in
both `fwupd` and `fwupdtool` -- negating a lot of the hard-fought savings.
Simplify this feature so that we just `cat` all the quirk files together, then
gzip them into a single file. This means that at startup fwupd only needs to
check the mtime of one file, and weirdly it's actually faster to load a smaller
compressed file from disk that it is to load multiple uncompressed files.
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.
G_APPLICATION_FLAGS_NONE was deprecated, but we don't actually need the single
instance functionality, so just use a non-deprecated flag instead.
This fixes Debian CI.
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.
Dell and Lenovo use Enable or Enabled and Disable or Disabled which is confusing
to an end user.
Set up some heuristics to map positive values and negative values when passed
into the client.
Semantically it is the desire of the security attribute, not the bios
attribute, i.e. you could imagine that a specific attribute would have
to be *foo or bar or baz* for HSI-1 and *only foo* for HSI-2
Also make it easier to add possible BIOS attribute target values in
plugin code.
This identifier can be used by plugins or the daemon to disambiguate
behavior between two different drivers.
Set it up so that plugins don't NEED to use it, but optionally can
find attributes by either name or ID
Several of the string/integer/time functions are duplicated in multiple
source files for no discernable reason. Move them into fwupd-common
as private symbols instead.
