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
Additionally, if the client does not set the feature flag `fde-warning`,
add an extra paragraph into the update description.
Fixes https://github.com/fwupd/fwupd/issues/3829
For some users typing 'fwupdmgr update' just deploys all updates to all hardware,
and that might come as a shock. Ask the user to confirm all actions explicitly
and show the update notes in a warning box rather than plain text on the console.
When this is done, include:
* Including the hash
* Including anything that is not ABI stable in plugins yet
Suggested-by: Simon McVittie <smcv@debian.org>
The end year is legally and functionally redundant, and more importantly causes
cherry-pick conflicts when trying to maintain old branches. Use git for history.
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.
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
Only use the history database to tell if activation should be run.
Instead query the connected devices to find the ones needing activation.
This should allow non-connected devices to not cause a failure (although
it might be a longer shutdown).
Also sort the devices, so that the order follows the defined order from
the daemon and they activate in the same order they install.
When one result is obsoleted by another, then do not show the old result by
default.
Additionally hide the HSI URLs as this was designed more for GUI clients like
gnome-firmware than CLI tools such as fwupdmgr.
The logic here is that we can use one central session for all client actions.
Also, set the user agent for the *runtime* version of fwupd -- it's the runtime
version we use when checking capabilities, rather than the built-against
version. This would also explain why there are so many very obsolete versions
of fwupd being recorded on the LVFS...
The HSI specification assigns a simple text ID to the current state of firmware
security. As new vulnerabilities are found, and as protection measures are
updated, new requirements will be added to the required firmware behaviours for
each HSI value.
The HSI specification is currently incomplete and in active development, and
so the --force flag is required in all command line tools. The current ID value
will probably change on a given platform so please do not start using the result
for any kind of compliance requirements.
This fixes the common problem encountered when developing plugins:
./src/fwupdmgr get-devices
Unsupported daemon version 1.4.0, client version is 1.4.0-179-gcf8095d5
As the motd timer may be activated to run on a system, ensure that
it hasn't actually stepped on the user running an update manually
or another client such as gnome-software refreshing metadtata.
Users can override this behavior with `--force`.
This is inspired by a change in flashrom to read the version string for meson
dynamically.
No need for "post release version bump", this happens automatically from git
now by there being a dirty commit.
This brings consistency to all fwupd output and allows stuff like
this:
```
No upgrades for Thunderbolt controller in Dell dock, current is 43.00: 40.00=older
No upgrades for Package level of Dell dock, current is 01.00.08.01: 01.00.04.01=older
No upgrades for RTS5413 in Dell dock, current is 01.21: 01.21=same
No upgrades for RTS5487 in Dell dock, current is 01.47: 01.47=same
No upgrades for VMM5331 in Dell dock, current is 05.04.00: 05.03.10=older
No upgrades for WD19TB, current is 01.00.00.02: 01.00.00.00=older
○
└─XPS 13 9380 System Firmware:
│ Device ID: 6c24a747f97668873b761558e322398a91dbf394
│ Current version: 0.1.6.0
│ Minimum Version: 0.1.6.0
│ Vendor: Dell Inc.
│ Flags: internal|updatable|require-ac|supported|registered|needs-reboot
│
└─XPS 13 9380 System Update:
Version: 0.1.7.0
Remote ID: lvfs
Summary: Firmware for the Dell XPS 13 9380
License: proprietary
Size: 0x1563d67
Vendor: Dell Inc.
Flags: is-upgrade
Description: This stable release fixes the following issues:
Fixed the issue where the Dell Power Manager displays an error when a 130W Type-C adapter is connected to the system.
new functionality has also been added:
Added a new feature to automatically suspend BitLocker before upgrading the firmware. After the firmware upgrade is complete, BitLocker is automatically enabled.
```
Unexpected behaviors can happen if:
* a snapped daemon is running with a packaged frontend
* a packaged daemon is running with a snapped frontend
This should make sure that if the snap is installed on top of a
packaged frontend that people don't try to mix and match as much.
The lines are almost impossible to read as they are not wrapped and not
delimited from the normal script output. Add a box around to make them stand out:
╔══════════════════════════════════════════════════════════════════════════════╗
║ The LVFS is a free service that operates as an independent legal entity and ║
║ has no connection with Fedora. Your distributor may not have verified any ║
║ of the firmware updates for compatibility with your system or connected ║
║ devices. All firmware is provided only by the original equipment ║
║ manufacturer. ║
║ ║
║ Enabling this functionality is done at your own risk, which means you have ║
║ to contact your original equipment manufacturer regarding any problems ║
║ caused by these updates. Only problems with the update process itself ║
║ should be filed at https://bugzilla.redhat.com/. ║
║ ║
╚══════════════════════════════════════════════════════════════════════════════╝
Agree and enable the remote? [Y|n]:
Some firmwares only update one part of the system, e.g. the EC or ME firmware.
Other updates include all the updates needed for the whole system, and vendors
have been doing different things with the component name due to this.
To fix, add an enumerated set of firmware 'categories' that can be set by the
uploader in the metainfo.xml file (or changed the LVFS) which automatically
set the name suffix.
Only append the translated version in the client when <categories> has
not been set, as the LVFS is still operating in compatibility mode and setting
the <name> with the prefix. Add the support to fwupd now so we can switch in
about 9 months time.
The offline updates environment is special, and we have to be careful to delete
the trigger before doing anything that can fail to avoid boot loops.
For this reason, split it out to a simple self-contained binary that is easy to
understand.
It's currently a hodge podge of commands that can install files not
always invoking a reboot or shutdown.
Move the actual code into `fu-util-common.c` and make sure that all
`install` and `update` functions call it now.
Previously if missing secure boot binaries, or invalid ESP was created the
plugin would just not load.
Now instead populate UpdateError and remove the updateble flag, but still show
the device in fwupdmgr and fwupdtool.
