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.
