Although glibc calls this when memory gets low automatically, we can invoke it
manually when we've loaded all plugins and coldplugged all devices.
This has no effect when using proper heap benchmarks like massif, but random
Reddit users just looking at the RSS column in an 'easy-to-use memory profiler'
will see a much lower numbers.
Where this feature might actually be useful is after a libxmlb metadata rebuild
where we dirtied a lot of heap just parsing XML.
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.
This would allow us to add other component types in the future, for instance a
'generic' type that adds information to the composite device.
Any generic components would need to have a requirement of 1.5.2 to avoid
showing a runtime warning when trying to get the local file details.
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
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 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.
At the moment we just blindly assume the capabilities of the front-end client
when installing firmware. We can somewhat work around by requiring a new enough
fwupd daemon version, but the client software may be older or just incomplete.
This would allow, for instance, the firmware to specify that it requries the
client to be able to show a detach image. This would not be set by a command
line tool using FwupdClient, but would be set by a GUI client that is capable
of downloading a URL and showing a PNG image.
Clients that do not register features are assumed to be dumb.
This allows the client to easily query metadata to upload with the report,
without exporting rarely used attributes as D-Bus properties on the interface.
It also allows us to add extra metadata values in the future without changing
the public API.
This exports FuSecurityAttrs into libfwupdplugin so that we can pass the plugins
this object rather than a 'bare' GPtrArray. This greatly simplifies the object
ownership, and also allows us to check the object type before adding.
In the future we could also check for duplicate appstream IDs or missing
properties at insertion time.
This change also changes the fu_plugin_add_security_attrs() to not return an
error. This forces the plugin to handle the error, storing the failure in the
attribute itself.
Only the plugin know if a missing file it needs to read indicates a runtime
problem or a simple failure to obtain a specific HSI level.
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
A Jcat file can be used to store GPG, PKCS-7 and SHA-256 checksums for multiple
files. This allows us to sign a firmware or metadata multiple times (perhaps
by the OEM and also then the LVFS) which further decentralizes the trust model
of the LVFS.
The Jcat format was chosen as the Microsoft catalog format is nonfree and not
documented. We also don't want to modify an existing .cat file created from WU
as this may make it unsuitable to use on Windows.
More information can be found here: https://github.com/hughsie/libjcat
Resolves installation for local CAB files that have `VersionFormat`
set but not yet also set from metadata.
In the first pass ignore the version format. This will rule out all
other checks such as GUID and protocol.
Then apply version format to the device if specified in the CAB.
Lastly do a second pass with all requirements set.
This allows several things, for instance:
* Adding or removing blacklisted plugins or devices
* Changing the idle timeout where allowed
...without a user needing to manually modify a configuration file.
If we update fwupd 'live' rather than from an ostree or offline update then
kill the running instance unless a firmware update is ongoing.
When users update fwupd at runtime they often forget to restart the fwupd daemon
and say that the update didn't fix it when actually they using the the old code.
This is intended for devices that it is not safe to immediately activate
the firmware. It may be called at a more convenient time instead.
Both fwupdmgr and fwupdtool support the feature.
- if called at runtime with fwupdmgr it uses the daemon
- during shutdown fwupdtool uses the pending.db to perform this feature.
