The former drags on glib-networking and then gsettings-desktop-schemas, which
add over 5Mb to the minimal IoT and CoreOS composes. Everything already uses
libcurl (even NetworkManager!) and so this is an easy way to reduce image size.
The logic here is that the attestation is more than just the PCR0 value, and
multiple device firmware (such as EC, ME, etc.) needs to be included to validate
the system.
By the same logic, updates for the system firmware do not tell the whole story,
and confuse HSI as a specification. Remove them.
The idea for a missing vendor-id would be that the LVFS sets the value
`NEVER_GOING_TO_MATCH` which is shown (along with the correct value) when the
user tries to **install** the firmware.
In 1.5.0 we correctly switched to filtering the devices by GUID and *then*
checking requirements before showing to the user.
In the missing vendor-id case the the poor ODM does not know why the device is
not showing up until they run the daemon in --verbose mode.
Relax the vendor-id checks when adding releases to devices, but of course leave
them in place for installing firmware. The ignore-vid-pid flag is not added
from `Install(a{sv})` and so this stays the same as before.
The authentication happens earlier in `fu_main_install_with_helper`
so no need to make recursive calls from `fu_main_authorize_install_cb`
into `fu_main_authorize_install_queue`.
Just simplify the code in the non-polkit case.
Checking this requirement at daemon startup meant that trust was
evaluated before releases could actually be checked.
It's only important to check at install time.
Loosen the requirement of the user ID to match root for the following
actions:
* Install release
* Activate firmware
For install release action, reject CAB files not signed by LVFS
```
$ sudo mv /usr/lib/x86_64-linux-gnu/libtss2-esys.so.0.0.0 /usr/lib/x86_64-linux-gnu/libtss2-esys.so.0.0.0.renamed
$ sudo fwupdtool get-devices --plugins=uefi
14:15:48:0735 FuEngine cannot load: failed to open plugin /usr/local/lib/x86_64-linux-gnu/fwupd-plugins-3/libfu_plugin_uefi.so: libtss2-esys.so.0: cannot open shared object file: No such file or directory
Loading… [- ]14:15:48:0753 FuEngine failed to update history database: device ID b6c08fb9e5384d9d101853cc1ca20cf0ce2df2e2 was not found
Loading… [***************************************]
WARNING: Plugin depdendencies missing
No detected devices
```
Rather than using a recursive GMainLoop, just run a single iteration of the
mainloop every 1ms while we're waiting.
This simplifies the device lifecycle dramatically as we don't have to worry
about reentrant removals. It's also a lot simpler to debug as we know the only
way to return is the timeout elapsing or FWUPD_DEVICE_FLAG_WAIT_FOR_REPLUG being
unset.
If multiple devices got removed and we're waiting for one to re-appear, also
wait for all devices to come back before returning to the main loop.
In the worst case, this causes the device list to wait the full removal_delay
for the device rather than returning when the first device matches. This allows
us to simplify the hub update when we reboot the entire device and various
devices from different plugins come back in an unpredictable order.
Fixes the other half of https://github.com/fwupd/fwupd/issues/2376
For instance, we can tell the user that UEFI UpdateCapsule is disabled in the
system firmware, or that efivarfs is not mounted. This is much better than
creating "dummy" devices which are really just hacks around the problem because
no better API existed. THe dummy devices cause as many problems as they solve.
Plugins have to set FWUPD_PLUGIN_FLAG_USER_WARNING if a warning should be shown
to the user, and only one warning will be shown of each failure type.
It is expected that GUI clients like gnome-software and gnome-firmware would use
this API to notify the user the localized message for why firmware updates are
not being shown.
Fixes https://github.com/fwupd/fwupd/issues/2456
The clients don't need to know this, and exporting them means we paint-ourselves
into a corner if we want to change the 'namespace' or how HSI actually works.
The FWUPD_INSTALL_FLAG_FORCE flag has really unclear semantics, and ignoring a
file CRC, checksum or model ID should only be done when using fwupdtool actually
debugging a plugin or firmware parser.
Use the existing --force flag when we want a "gentle nudge" like reuploading
previously processed reports.
This allows us to handle this in the plugin, which might mean detaching the
*proxy* device. It's also very important as a few plugins reboot the device
in ->attach() to get the new firmware version, which isn't required for a dump.
This partially reverts a58510b246 and does the
detach and attach in the few plugins where actually required.
This is never set in the AppStream metadata, and means that every call to
fu_engine_ensure_device_supported() at startup does not generate 16x debugs.
For cab archives we know if the archive was unsigned as we show the flags in
the to_string() output.
