As it turns out, the major and minor BIOS version should also be
represented in hex format in the hash, but in contrast to the
enclosure type, always on 2 digits, padded if necessary. There is no
decimal value in any of the hashes, it seems.
The previous data, I tested with didn't include major/minor version
numbers bigger than 9, so the issue didn't materialize.
Handle the enclosure type as a hex value, not as a decimal.
This is mandated by the SMBios specification, where 0x10h (the value
16) is specifying the enclosure type of "lunch box", while 0x0ah (the
value 10) is "notebook".
They hash BIOS major and minor version with 2 digit padding using
leading zeros. We do the same from now on.
Signed-off-by: Richard Hughes <richard@hughsie.com>
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.
Using just the default GUID is fragile and might break if the GUIDs get added
in the 'wrong' order or if the GUID list is sorted.
Fixes https://github.com/hughsie/fwupd/issues/518
Several places in the UEFI plugin operate on the default GUID rather
than iterating a list of GUIDs. This is normally fine since UEFI
GUIDs are tied to the ESRT and normally one FuDevice shouldn't
have multiple GUIDs.
The alternate GUID was added to set parents accordingly but this
caused no CAB files to be able to install.
Fixes: cc664d7d (amt: Put the AMT device as a child under the system UEFI firmware)
