The idea is that if the user should know something about the device update
"after" it's succesfully completed then the plugin can set `UpdateMessage`
for the device and a client can show it.
An example would be a device that doesn't reboot on its own and the user
needs to power cycle it manually.
Now that there is actually support to load non-static information
(at least from fwupd perspective) it makes sense to support this
command in both tools.
The source URL allows us to comply with our various obligations when shipping
firmware built from GPL licensed sources. The details URL allows vendors to
include a link to a full HTML details page about the specific release.
It's currently a hodge podge of commands that can install files not
always invoking a reboot or shutdown.
Move the actual code into `fu-util-common.c` and make sure that all
`install` and `update` functions call it now.
If the device is rebooted into a different shape, the plugin managing
the device may also be different.
This would be the case for plugins that just subclass the update_detach()
method, and leave to other plugins the actual required update procedure.
This will perform updates with all currently present metadata.
It is "intended" for usage with local metadata repositories referring
to local files.
fwupdtool however does also support fetching a file from the web
and if the metadata refers to the file on the web it should also work
for that.
I forgot to include the protocol column when migrating to v3, so create a v4
which ignores the sqlite error if the column already exists.
Fixes https://github.com/hughsie/fwupd/issues/909
It seems uuid_parse() doesn't check the string length before unwrapping the
string into a struct. Fixes:
Conditional jump or move depends on uninitialised value(s)
at 0x4E0C358: uuid_is_null (isnull.c:44)
Some firmware has a different on-device checksum to the hash of the firmware
file itself. This may be because:
* The content is not a binary file, e.g. Intel HEX or SREC
* Only part of the firmware is flashed, e.g. ignoring the bootloader section
* The device checksum is calculated using another method entirely, e.g. PCR0
It's also made complicated as there may be more than one 'correct' device
checksum in some cases, but nothing that a union query can't solve.
We can't actually access the UEFI ROM from userspace, but the PCR0 is a hash
built from the ROM itself. We could use this value to ensure the firmware has
been written correctly, and that the PCR0 matches the expected value specified
in the metadata.
Future metadata from the LVFS will set the protocol the firmware is expected to
use. As vendors love to re-use common terms like DFU for incompatible protocols,
namespace them with the controlling company ID with an approximate reverse DNS
namespace.
This also allows more than one plugin to define support for the same protocol,
for instance rts54hid+rts54hub and synapticsmst+dell-dock.
The LVFS has always sent components with the old-style '<metadata>' section
rather than the new-style '<custom>' section, and when using appstream-glib
we just accepted either element name. Although the LVFS has just been fixed to
use the new name, old metadata might be present on the system already.
When all clients have downloaded new metadata we can revert this, perhaps in a
couple of weeks time. Until then, the belt-and-braces approach is probably a
good idea.
Fixes https://github.com/hughsie/fwupd/issues/874
