If the measurements are missing but it's a UEFI system, it's a good indication
that the user has secure boot turned off.
Notify the user on the UEFI device through a non-fatal `UpdateMessage`
To accomplish this, move fu-uefi-vars into the plugin library for other plugins to use
At the moment we're returning plain text for the embargo remotes and AppStream
markup for LVFS remotes. This fixes the warning on the console:
$ fwupdmgr enable-remote lenovo_thinkpad-embargo
failed to compile foo: Document must begin with an element (e.g. <book>)
In Chrome OS /etc/machine-id is not available on the sandbox
environment. Chrome OS specifically rotate it constantly and is
considered PII.
Change-Id: Ia4113affa68c5973b36d196a35278a3f6cee2898
Signed-off-by: Daniel Campello <campello@chromium.org>
Use xb_builder_source_add_simple_adapter instead
xb_builder_source_add_adapter to avoid sniffing MIME type for output xml
contents
Signed-off-by: Daniel Campello <campello@chromium.org>
Change-Id: I123c37339720b5844351f85a5aeb9cec4928785c
Replace fu_common_cab_build_silo() with an actual GObject that can hold parsing
state. This cleans up the code a lot, and means we can add additional
functionality in the future without breaking ABI or API.
The long term plan is to verify the metadata and payload signatures when
parsing FuCabinet, rather than much later in _check_requirements().
This of course requires passing in a keyring context (which we don't yet have)
and would mean we can stop setting the various confusing 'fwupd::ReleaseBlob'
XbNode extra data.
No logic changes for now, just a lot of moving things into sane places.
If we say that the version format should be the same for the `version_lowest`
and the `version_bootloader` then it does not always make sense to set it at
the same time.
Moving the `version_format` to a standalone first-class property also means it
can be typically be set in the custom device `_init()` function, which means we
don't need to worry about *changing* ther version format as set by the USB and
UDev superclass helpers.
This does 'bleed' the metadata contents into areas previously covered by quirks,
but in this case may be pragmatic and more up to date than a build-time
generated quirk file, which increases the user-friendliness of fwupdmgr.
Some Dell devices offer the exact same GUID in UEFI as well as in NVME
plugins. These devices can be flashed in either way, but the payload
for them is different.
The UEFI payload includes relevant headers and metadata to be acceptable
from a capsule. The NVME payload is raw data that the drive will process.
Since baa9e75ca8, fwupd should enforce that
the correct device is flashed with the correct protocol.
Some vendors want to ship updates for ATA hardware, but there are currently no
lock-down restrictions in place for these kind of devices.
There is the OUI from the WWN block which is supposed to identify the vendor,
but this is not always set and so we have to be a little creative. We can match
90% of hardware using the vendor name prefix, and the last 10% can be detected
with a heuristic that was the result of comparing over 900 drive models.
I'm not including very old drive models, media converters, raid controllers,
or external 'portable' drives as I don't think it is useful. Also, if the drive
contains a Dell vendor block just hardcode this as Dell rather than trying to
be clever.
Also ask the user to contribute OUI values if this data is found with no quirk
data as this is the only real sane way to manage this data long term.
The list of OUIs can be found here: http://standards-oui.ieee.org/oui.txt
In 1de7cc we checked the version format when checking for update, but there are
many other places that are doing verfmt-insensitive comparisons. For instance,
the predicates in <requires> all fail if the device version format is plain.
his breaks updating some NVMe drives where the `ne` requirements are not
semantic versions.
To avoid trying to catch all the bugs in different places, and in case we have
a future verfmt that should be treated another way, refactor this out in to a
common function and deprecate the old function.
