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.
If another offline update task is run at the same time, e.g. pk-offline-update
from PackageKit then we might corrupt the package database when the client
D-Bus request times out.
Copy the fixes from PackageKit so that the offline updates work together.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1685471
This currently just outputs the current list of devices with releases and makes
it possible to integrate firmware version reporting with other tools like mgmt.
This feature is turned on with the new fwupdtool option `--enable-json-state`
The intended use case is for ChromeOS to be able to save information about
devices on the system when `fwupdtool update` was run to display in the UX at
a later time.
The following warnings were displayed by Debian appstream metadata
validation.
```
metainfo-validation-issue
Validation of the metainfo file found a problem: Found empty 'url' tag.
metainfo-validation-issue
Validation of the metainfo file found a problem: Type 'console-application' component, but no information about binaries in $PATH was provided via a provides/binary tag.
metainfo-validation-issue
Validation of the metainfo file found a problem: Found empty 'url' tag.
```
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.
For this we need to register as a console application (which fwupdtool is, I
suppose) and also supply a usable icon.
I've used the new GNOME icon theme guidelines so please add a drop shadow
before using: https://gitlab.gnome.org/GNOME/Initiatives/issues/2
Two new arguments added to fwupdtool: `--prepare` and `--cleanup`
They are used only with the `install-blob` command
This makes sure that devices can get rebooted in dell-dock even if using
fwupdtool to install a single blob.
Signed-off-by: Richard Hughes <richard@hughsie.com>
Now that there is actually support to load non-static information
(at least from fwupd perspective) it makes sense to support this
command in both tools.
This will perform updates with all currently present metadata.
It is "intended" for usage with local metadata repositories referring
to local files.
fwupdtool however does also support fetching a file from the web
and if the metadata refers to the file on the web it should also work
for that.
Plugins are allowed to 'opt-out' of this behaviour using _RULE_INHIBITS_IDLE.
This should be used where waking up the hardware to coldplug is expensive,
either from a power consumption point of view, or if other artifacts are going
to be seem -- for instance if the screen flickers when probing display devices.
This functionality is also inhibited when the actual upgrade is happening,
for obvious reasons.
Admins can turn off this auto-sleep behaviour by editing the daemon.conf file.
Fixes https://github.com/hughsie/fwupd/issues/417
This matches what a lot of other projects do, and means we can easily format
the release notes back into NEWS format, but also into HTML and Markdown.
This also means we can show the correct update description in gnome-software
when building a flatpak, rather than falling back to the generic project
description.
This allows us to match non-DeviceID GUIDs, and also GUIDs we don't know how to
generate.
To make this fully useful, search for device quirks when GUIDs are added.
/boot is a special cased directory when using ProtectSystem=full
Due to this, it's marked read only even if it's listed in ReadWritePaths.
Allow folks to use this for their ESP, but they need to create /boot/EFI
in advance of starting fwupd.
Check across a list of common EFI system partition locations for a mounted
location before starting fwupd.
This also will cause the plugin to not initialize if the EFI system partition
is not mounted.
This pivots the data storage so that the group is used as the preconditon
and the key name is used as the parameter to change. This allows a more natural
data flow, where a new device needs one new group and a few few keys, rather
than multiple groups, each with one key.
This also allows us to remove the key globbing when matching the version format
which is often a source of confusion.
Whilst changing all the quirk files, change the key prefixes to be more familiar
to Windows users (e.g. Hwid -> Smbios, and FuUsbDevice -> DeviceInstanceId)
who have to use the same IDs in Windows Update.
This also allows us to pre-match the desired plugin, rather than calling the
probe() function on each plugin.
Requiring colord to be built before fwupd makes it hard to build packages.
The HID-based flashing protocol is stable and documented, so there's no need
to use an external library for this now.
When developing code it's really convenient to only run the new plugin. This
means you don't have to wait for the other hardware to initialize and there
are no side-effects from other plugins when installing firmware.
You can specify multiple plugins as globs, for instance:
fwupdtool get-devices \
--plugin-whitelist wacom \
--plugin-whitelist "thunderbolt*"
In the future the Linux Foundation will be running the LVFS server.
To make this possible, include the Linux Foundation public keys by default as
we already trust them. Obviously the keys need to be available long before
vendors move, so nobody should get too worried at this point.
This means we can avoid loading a ton of non-fwupd files, and reduces our
running RSS from 5.4Mb to 2.8Mb. Old versions of appstream-glib caches a lot of
the localization string data which we just don't care about for firmware files.
The current CDN (~$100/month) is kindly sponsored by Amazon, but that won't
last forever. In the future we can switch to a 'dumb' provider like BunnyCDN
for 1/10th of the cost.
Use a CNAME we control to make switching CDN providers easy in the future.
If this happens:
1.2.3 -> 1.2.4 = failure
1.2.3 -> 1.2.5 = success
...we want to preserve both in the history database so they can both be shared
with the LVFS. Use the device ID and the new and old firmware versions when
modifying and deleting entries.
This fix is made slightly more tricky as we have to drop the PRIMARY KEY
attribute on the device_id, and due to a limitation in SQLite, it means copying
the old history into a new table.
The previous fix (db6ed9ede3) didn't
do a good enough job and autopkgtest was still failing on another
individual test.
This makes sure that stderr will never conflict with autopkgtest
in the future.
The autopkgtest test cases in Debian and Ubuntu are failing due to
output present in stderr.
fwupdmgr behavior however is that it's expected that this test should
show output on stderr for this item.
Rename FuPending to FuHistory to better represent what the object is now doing.
Also, while we're here, switch to using SQLite prepared statements to avoid a
possible invalid read on i386 hardware.
If a remote like LVFS outputs <location>foo.cab</location> without a prepended
hostname and path then we should use the metadata URI hostname and path instead.
This allows us to trivially mirror a firmware repository, although clients using
older versions of libfwupd will not work without this patch. We should encourage
people to use `FirmwareBaseURI` for a long time yet.
Previously, the various install paths were obtained using get_option
as needed.
This patch unifies the directory selection inside the top-level meson
file as requested in https://github.com/hughsie/colord/pull/62.
This allows us to flash hardware like the Retrode and other devices using chips
like the AT90USB1287.
The test files can be re-generated using the sample code found here:
https://github.com/hughsie/fwupd-test-firmware and are designed
to be used on the AT90USBKEY2 development board.
In the latest version of the LVFS you can restrict the firmware to a specific
machine type, for instance a specific baseboard vendor. This is the same as
done in Microsoft Update using the CHID mechanism.
This commit adds support for the <hardware> requires type, although it needs to
be built against appstream-glib 0.7.4 to be supported and/or tested.
When fwupd is installed in long-term support distros it's very hard to backport
new versions as new hardware is released.
There are several reasons why we can't just include the mapping and quirk
information in the AppStream metadata:
* The extra data is hugely specific to the installed fwupd plugin versions
* The device-id is per-device, and the mapping is usually per-plugin
* Often the information is needed before the FuDevice is created
* There are security implications in allowing plugins to handle new devices
The idea with quirks is that the end user can drop an additional (or replace
an existing) file in a .d director with a simple format and the hardware will
magically start working. This assumes no new quirks are required, as this would
obviously need code changes, but allows us to get most existing devices working
in an easy way without the user compiling anything.
This allows us to fix issues like https://github.com/hughsie/fwupd/issues/265
The Linux DMI class still does not provide the information we need, and parsing
the blob directly also allows the Dell and Redfish plugins to get the raw data.
According to the crypto experts, path_len=1 makes things more secure for a CA
to prevent the Sub-CAs from issuing further Sub-Sub-CAs. I'll stick to code.
This also switches around the test for the self signed key to now fail, as the
generated certificate is no longer loaded into the trust list. This is a more
useful test as it more accurately represents what the fwupd daemon is doing.
As a side-note the detached signature from the derivate cannot be generated
using `--no-p7-include-cert` as only the main LVFS-CA certificate is shipped
with fwupd.
This means we return an error when encountering a rollback attack. This can
currently be performed by providing the old metadata and old signature when
calling into UpdateMetadata.
We can use this as an alternative for GPG. No PKCS7 certificates are currently
installed by fwupd and it's expected that the LVFS will still only provide GPG
detached signatures.
If an OEM distributor wants to sign firmware with a PKCS7 and the corresponding
certificate is provided then the firmware will be marked as valid.
Only firmware shipping with a .p7b file will use the PKCS7 functionality,
similarly remote metadata validation will default to GPG unless Keyring=pkcs7
is specified in the config file.
In this mode, both the metadata and firmware is stored on the local filesystem
and distributed using a distribution system like OSTree.
Fixes https://github.com/hughsie/fwupd/issues/162
Now we have multiple remotes that can be enabled or changed at runtime we need
to do several things better:
* Only load components from remotes that are enabled
* Only load a component if a higher priority remote has not already added it
Rather than just appending all recieved metadata into one big XML file, save
the original metadata .xml.gz files in /var/lib/fwupd/remotes.d and only load
them in the correct priority order if the remote is known and enabled.
Remove the old /var/cache/app-info/xmls/fwupd.xml file, also noting it wasn't
really a cache file at all but actually something quite important.
This also moves the tests into one file as gnome-desktop-testing-runner
intentionally randomizes the order and runs them in parallel where allowed.
Since tests like get-updates have to be run after the metadata injection simply
put these into one test that calls a simple script.
