This adds support for optionally using a UNIX domain socket where a
D-Bus daemon may not be running.
To use this, launch the daemon and clients with something like
`FWUPD_DBUS_SOCKET=/var/run/fwupd.sock fwupdmgr get-devices`
This makes it easier to test the fwupd in the installed tests:
sudo gdbus call --system \
--dest org.freedesktop.fwupd \
--object-path / \
--method org.freedesktop.fwupd.Quit
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.
Proxying the values is firstly inefficient, in that there were only
three functions in fu-engine.c that did not already have FuProgress
objects passed to them.
Secondly, processing the 'status' values from the engine meant that we
reset the percentage value to 0 for a split second, which made the
progress bar jump back to zero for one frame making it flicker.
Just make it all simpler and use FuProgress directly.
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.
99.9999% of users are consuming firmware updates from the LVFS or
another trusted remote. It's far too easy to get a user to enter the
password to install an untrusted firmware, where the security
consequences are pretty dire.
Provide an escape-hatch for firmware engineers, but it does mean
editing a file in /etc as root. This seems like an acceptable level of
inconvenience.
This functionality broke a number of releases ago as part of
implementing device inhibition and was just noticed now.
Instead of fixing it, the preference seems to be to remove the
functionality as it exists today as inhibitions can happen for
a number of reasons.
To still allow people to override these power warnings (such as during
development) add a new daemon configuration item that can be used.
Fixes: #3778
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".
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.
