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.
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...
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.
The idea here is that we can show the user both a string and an optional
line-art image when the update has completed. The line art is often more well
understood for non-English speakers.
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.
To do this, rely on the AppStream ID to map to a translated string (providing a
fallback for clients that do not care) and switch the free-form result string
into a set of enumerated values that can be translated.
This fixes some of the problems where some things have to be enabled to "pass"
and other attributes have to be some other state. For cases where we want the
user to "do" something, provide a URL to a wiki page that we update out-of-band
of fwupd releases.
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.
The returned ID is the result of the SHA1 hash of the actual device ID. This
does not match anything found by the client, and so the install fails.
The symbol is exported as I think the device ID is an important identifier and
used in various fwupd tools.
When backported to the stable branch the verification should just be a static
function in src/fu-engine.c rather than a new symbol.
Switch to downloading the signature first, which we can then load to get the
suffixed build-specific URL of the actual metadata file. You need to have
libjcat 0.1.1 installed and fwupd built against the new version for this to
work.
Fixes https://github.com/fwupd/fwupd/issues/391
