Over the months the original meaning of ALLOW_OFFLINE and ALLOW_ONLINE have be
lost, and there is now a confusing mixture of uses in the source tree. With this
commit we make it clear the UPDATABLE flag is used to specify when the device is
updatable (e.g. from the desktop live session, or from the systemd offline
updates mode, or both) and the NEEDS_REBOOT flag lets us know when the update
is actually going to be done.
For instance, a UEFI UpdateCapsule can be *scheduled* from either the desktop
or from the update mode (but the latter would be a bit weird), but does require
a reboot. Some devices might only be updatable outside the live session, for
instance a hard drive update or a GPU update -- there's just too much going on
with a live session and we want to tightly control what's running during the
firmware flash.
This also means we don't have to "retry" the update when scheduling an update
that really can be scheduled whenever, but just requires a reboot to apply.
Handling this in one place prevents plugins setting different values for
non-string values like TRUE/false or with different ways to represent integers.
This could be used, for instance, to set a property on ThunderBolt controllers
inside Dell computers saying that they support forcing the power level during
coldplug. It could also be used to set the dock type for the synapticsmst hub.
Adding this level of complexity allows us to avoid the creep of HAVE_DELL and
HAVE_LENOVO into seemingly unrelated plugins, and also allows us to have
multiple vendor plugins providing the same end result with two different
vendor-specific mechanisms.
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.
Fixes the meson error:
Meson encountered an error in file meson.build, line 207, column 2:
Unknown variable "systemd".
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Thunderbolt has a new kernel interface starting from version 4.13,
which simplifies updating the host controller and devices: the
kernel now exposes a sysfs interface for the non-volatile memory
as a device node. This can be used to write the new firmware blob.
Updates are then triggered also via a simple write to a sysfs
file (nvm_authenticate), which in turn is also used for error
reporting.
The plugin should be functionally, but a few items are missing:
- image verification
- safe mode handling
According to some best practices this is a good idea, but in this specific case
the certificate will have been installed by the admin or package manager and
so is less important.
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.
By echoing the commands it is way easier to spot what the CI was doing
when a command failed. Setting fail-on-error mode explicitly makes sure
we always run with it, even if someone invokes the script with `bash
<scriptname>`
