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 show in the tools if a device is currently affected
by a specific CVE. For instance, we could inform the user that a device
requires a critical firmware update that is being actively exploited.
Note, this also means we can show the user a firmware update is now
required, even though the firmware may not be available on the LVFS.
Also show the issue in the `fwupdmgr security` output, e.g.
There are devices with issues:
Samsung — MZVLB2T0HALB-000L7:
• CVE-2022-12345
• CVE-2022-54321
Install or downgrade firmware on all devices to make the system match
a well known set. This allows two things:
* Factory recovery where a device in the field has been upgraded
* Ensuring a consistent set of tested firmware for a specific workload
A tag is assigned either during upload or added post-upload on the LVFS
which is included in the metadata. A single firmware can be marked with
multiple tags, and tags can be duplicated for different firmwares.
Send the users locale to the daemon so that it can be used to prefer
the localized update text over the default en_US version.
$ LANG=fr_FR.UTF8 fwupdmgr get-details test.cab
...
└─ACME Plan 9:
Nouvelle version: 0.0.5
Licence: Propriétaire
Urgence: Faible
Fournisseur: ACME Ltd.
Description: Cette version stable corrige des bugs.
I decided to send the locale to the daemon rather than change the
`Description` to return GVariant to `a{ss}` as we also probably want
to support things like localized summary and URLs too in the future.
This indicates the GUID in some way contributed to the result decided.
It also allows us to match the submitted HSI results back to a firmware
stream on the LVFS, which allows us to allow vendors to see a subset of
results for uploaded devices.
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".
Devices may want to support more than one protocol, and for some devices
(e.g. Unifying peripherals stuck in bootloader mode) you might not even be able
to query for the correct protocol anyway.
We forgot to include FwupdClientDownloadFlags when adding the original method
fwupd_client_install_release() -- and we want to use additional download flags
for operations in the future.
The metadata might want to pass more than one location URI to the client, for
instance if the file is available from more than one HTTP mirror.
Use the noun of location to match the AppStream <artifact> naming; this is the
last place where LVFS AppStream diverges from the official specification and
it would be good to bring fwupd back into line -- although the LVFS will have
to write both elements for a very long time.
See https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html
Also: we're not changing the format of the `Uri` GVariant key to preserve both
forward and backwards compatibility of the library. We can remove it when we
next break API.
Asking the user for the UID mapping isn't working very well, as it requires lots
of manual handholding. It also doesn't work very well when the device vendor
does not actually have a PCI ID or if the vendor has split into two entities.
Just use the OUI address as an additional VendorID and match any of the device
IDs against any of the metadata-supplied values.
Use the 'default' main context by default so that we still get the signals
delivered via g_object_notify() but allow the library user to specify an
alternate GMainContext as required.
Using g_main_context_push_thread_default() works for PackageKit as signals are
returned using g_signal_emit() which is synchronous, and so doesn't use the
main context at all.
Use the same style of API which we did for libgusb all those years ago instead.
We can't do this in the library as Ubuntu want to ship a new libfwupd with an
old daemon. The new daemon only understands jcat and does not know how to
determine the age of an .asc file.
I'm porting gnome-software to use this new API and this would be a very useful
thing to provide. No async API as we want to avoid writing temp files in most
cases -- this is just for legacy apps.
The FuDevice derives from FwupdDevice, and yet both objects have a (potentially
different) parent and set of children. This is super confusing, and just not
required.
Removing the duplication also removes a sizable memory leak when hotplugging
composite devices as the parent was ref'd by the child and the child was ref'd
by the parent in different objects... Fun to debug...
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
This allows a device to identify with different streams, for instance a Lenovo
laptop could have a coreboot firmware or a AMI firmware. The GUIDs would be the
same, but switching firmware would only be done rarely and very carefully.
Another example would be switching the Broadcom BCM57xx nework adaptors from the
vendor nonfree firmware with a signed PXE image, to the free software reverse
engineered driver with no PXE support (and thus no signed DXE) at all.
It is expected firmware would have additional metadata something like this:
...
<branch>sdcc</branch>
<description>
<p>
This is an alternate firmware built by the community using only free
software tools.
</p>
</description>
<requires>
<id compare="ge" version="1.5.0">org.freedesktop.fwupd</id>
<client>switch-branch</client>
</requires>
...
Additionally, alternate branch firmware will not be returned for clients not
setting the FWUPD_FEATURE_FLAG_SWITCH_BRANCH before the GetReleases request.
This is required when the calling application needs the low-level soup-session
with the user agent set correctly rather than using the helper methods like
fwupd_client_download_bytes().
This is what GNOME Software needs to handle the GsApp progress completion.
This takes care of downloading the correct files and allows remotes to be
refreshed from other CLI and GUI tools without copying large chunks of code.
This also allows us to download the metadata without writing two temp files
to the users cache directory. Although not security sensitive, it's probably
not a good idea if we can avoid it.
