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.
When the redfish plugin automatically creates an OPERATOR user account on the
BMC we save the autogenerated password to /etc/fwupd/redfish.conf, ensuring it
is chmod'ed to 0660 before writing the file with g_key_file_save_to_file().
Under the covers, g_key_file_save_to_file() calls g_file_set_contents() with
the keyfile string data.
I was under the impression that G_FILE_CREATE_REPLACE_DESTINATION was being
used to copy permissions, but alas not.
GLib instead calls g_file_set_contents_full() with the mode hardcoded to 0666,
which undoes the previous chmod().
Use g_file_set_contents_full() with the correct mode for newer GLib versions,
and provide a fallback with the same semantics for older versions.
This allows the backend to identify the specific device for a specific phase.
For instance, there might be a pre-update runtime, a bootloader and a
post-update runtime and allowing tags to be saved to the backend object allows
us to identify each version of the same physical device.
This takes us one step closer to emulating a complete byte-perfect end-to-end
update without actual hardware installed.
This is being used for other products, e.g. USB4 docks.
If non-Intel firmware is being used (e.g. ASMedia) then the explicit
calls to `fu_intel_thunderbolt_nvm_new()` can be changed to something
like `fu_firmware_new_from_gtypes()` with all the formats listed.
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 firmware from both Dell and Lenovo actually blocks this, but the
error message is pretty confusing.
```
$ sudo fwupdtool set-bios-setting SecureBoot Disable
17:39:40:0249 FuBiosAttrs KERNEL BUG: thinklmi doesn't export a 'type' attribute
Loading… [- ]
failed to write 7 bytes to 17: Invalid argument
```
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
Some parsers are ignoring the magic when using _FLAG_IGNORE_CHECKSUM
(which is wrong; fuzzers have no problem with enforcing a static prefix)
and other either disregard the offset or check the magic in an unsafe
way. Also, use FWUPD_ERROR_INVALID_FILE consistently for magic failure.
Add a vfunc, and move all the clever code into one place.
Using `sudo FWUPD_PROFILE=10 ./src/fwupd --verbose` will print a
dump of startup times onto the console so that we can debug which
plugin is slowing down system startup. For example:
../src/fu-engine.c:5409:plugins-coldplug [108.55ms]:
../plugins/amt/fu-plugin-amt.c:437:amt [27.14ms]:
:create-context [12.66ms]
:get-version [8.44ms]
:add-device [3.95ms]
To a user there is no point to explicitly showing two failures for
encrypted RAM if the system supports SME and TSME both.
To show them a single failure, de-duplicate the attributes by appstream
ID during depsolve.
If the plugin didn't explicitly set obsoletes and two attributes are both
failures and both share the same appstream ID obsolete one of them.
