The logic here is that we can use one central session for all client actions.
Also, set the user agent for the *runtime* version of fwupd -- it's the runtime
version we use when checking capabilities, rather than the built-against
version. This would also explain why there are so many very obsolete versions
of fwupd being recorded on the LVFS...
The returned ID is the result of the SHA1 hash of the actual device ID. This
does not match anything found by the client, and so the install fails.
The symbol is exported as I think the device ID is an important identifier and
used in various fwupd tools.
When backported to the stable branch the verification should just be a static
function in src/fu-engine.c rather than a new symbol.
Add various fixes to enable us to build a selection of useful USB plugins.
Also, skip tests that don't make sense on WIN32 or that will not work.
With much help from Mario Limonciello <mario.limonciello@dell.com> -- Thanks!
On some hardware the SHA1 checksum is not set and so we want to use the SHA256
hash value as well.
The LVFS doesn't currently read the ChecksumDevice value and so nothing will
explode serverside when changing this type from 'string' to 'array of strings'.
This also allows us to write mixed-endian structures and adds tests. As part of
this commit we've also changed the API of something that's not yet been in any
tarball release, so no pitchforks please.
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.
There are a lot of hacks here;
* Pulling newer libappstream-glib from Fedora
* Pulling a systemd backport
* Manually installing pillow and pygobject
* PKCS7 is turned off (gnutls is too old)
Although we supported other hashes than SHA1 (which is now moderately unsafe)
we had to switch the metadata provider and daemon on some kind of flag day to
using SHA256. Since that's somewhat impractical, just allow multiple checksums
to be set on objects and just try to match whatever is given in preference
order.
This also means we can easily transition to other hash types in the future.
The removed API was never present in a tarball release, so not an API break.
