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.
This fixes a regression from 2f49da7f4e where we
tried to parse the GPG .asc file as a JcatFile even although the remote had
Keyring=gpg (which is the default for ODM accounts on the LVFS) which returned
the cryptic 'Invalid compressed data' message.
The workaround for 1.5.2 is to change the local remote.conf from 'Keyring=gpg'
to 'Keyring=jcat' and to save the file.
The snap-store intends to ship an updated libfwupd library but
to use it with whatever version daemon is on the host system.
This means that the library needs to still work with older metadata
signing types.
This fixes the following error in that scenario:
```Failed to update metadata for lvfs: Keyring kind jcat not supported```
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.
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.
Otherwise we could be left with a device that sets the expected verfmt in the
plugin _init(), but would not be inherited from the subclass. It would have:
Version: 0.2
VersionFormat: triplet
...which makes no sense.
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...
```
$ sudo mv /usr/lib/x86_64-linux-gnu/libtss2-esys.so.0.0.0 /usr/lib/x86_64-linux-gnu/libtss2-esys.so.0.0.0.renamed
$ sudo fwupdtool get-devices --plugins=uefi
14:15:48:0735 FuEngine cannot load: failed to open plugin /usr/local/lib/x86_64-linux-gnu/fwupd-plugins-3/libfu_plugin_uefi.so: libtss2-esys.so.0: cannot open shared object file: No such file or directory
Loading… [- ]14:15:48:0753 FuEngine failed to update history database: device ID b6c08fb9e5384d9d101853cc1ca20cf0ce2df2e2 was not found
Loading… [***************************************]
WARNING: Plugin depdendencies missing
No detected devices
```
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 clients don't need to know this, and exporting them means we paint-ourselves
into a corner if we want to change the 'namespace' or how HSI actually works.
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.
This would also help, for example, to go back to the nonfree firmware when the
alternate firmware did not work as well as hoped. It would also allow flashing
the firmware using an SPI programmer if everything went very wrong indeed.
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 changes allows for downloading firmware from a remote server
pointed from a local remote manifest.xml.gz file
Change-Id: Id00870f9c2817d48d6d301d2b6d229ba1ca6045a
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.
