This prevents problems when cross compiling. Using help2man is now also of
limited use; if we can just tell the user to use --help we do not need to keep
the manual in sync.
It also allows us to drop the several other supporting files that we use when
the help2man output isn't actually that useful.
Fixes https://github.com/fwupd/fwupd/issues/3025
Commit 13524af202 broke the ABI checker.
This is because it runs on the last released version, which still has
a dependency on python3-pil.
This commit can be dropped after the 1.6.x release.
Keeping *internal* API and ABI compatibility makes working with an already
complex codebase more mentally demanding than it needs to be.
Remember: plugins should be in-tree and upstream! If your out of tree plugin
stops working then it should be upstream.
The public-facing libfwupd will remain API and ABI stable for obvious reasons.
This patch is adding the fwupd wrapper for Qubes.
The wrapper provides fwupd functionalities for Qubes R4.1.
It creates three packages (two RPMs and one Debian package):
fwupd-qubes-dom0 (RPM)
fwupd-qubes-vm (RPM)
fwupd-qubes-vm-whonix (deb)
More information about the wrapper could be found in the
contrib/qubes/README.md
Signed-off-by: Norbert Kamiński <norbert.kaminski@3mdeb.com>
It is far too easy to forget to set FWUPD_DEVICE_FLAG_NO_GUID_MATCHING for new
plugins, and without it it all works really well *until* a user has two devices
of the same type installed at the same time and then one 'disappears' for hard
to explain reasons. Typically we only need it for replug anyway!
Explicitly opt-in to this rarely-required behaviour, with the default to just
use the physical and logical IDs. Also document the update behavior for each
plugin to explain why the flag is being used.
This allows you to have two identical Unifying plugged in without one of them
being hidden from the user, at the same time allowing a HIDRAW<->USB transition
when going to and from bootloader and runtime modes.
This removes the workaround added in 99eb3f06b6.
Fixes https://github.com/fwupd/fwupd/issues/2915
Also split out the firmware parsing to an object so we can check the firmware
using firmware-parse and also fuzz it.
See also: https://github.com/fwupd/fwupd/issues/1665
Two reasons:
* It seems a bit antisocial to hard-require all this data without fair warning
* The aarch64 pesign crashes when trying to sign the binary with SBAT metadata
We happily fallback with an unset -Defi_os_dir and it gets confusing explaining
why the EFI dir needs to be set on a non-supported system.
In practice they'll probably have the same eventual value on most supported
distributions.
Fixes https://github.com/fwupd/fwupd/issues/2873
The Secure Boot Advanced Targeting (SBAT) [0] is a Generation Number Based
Revocation mechanism that is meant to replace the DBX revocation file list.
Binaries must contain a .sbat data section that has a set entries, each of
them consisting of UTF-8 strings as comma separated values. Allow to embed
this information into the fwupd EFI binary at build time.
The SBAT metadata must contain at least two entries. One that defines the
SBAT version used and another one that defines the component generation.
Downstream users can add additional entries if have changes that make them
diverge from the upstream code and potentially add other vulnerabilities.
[0]: https://github.com/rhboot/shim/blob/sbat/SBAT.md
