The data for these was just being generated internally based on the ID and the
basename of the original URI, and that's easy for the calling application to do
itself.
UEFI updates don't need to be retried since a785a1c. If the call to Install()
failed with NOT_SUPPORTED we can just show the error rather than doing the
little dance and involving the offline pending database for no reason.
Fixes some of https://github.com/hughsie/fwupd/issues/255
It only remained on FwupdResult because I couldn't make up my mind about whether
it was a property of the device, or the firmware release. It's more logically
the former, and that's how plugins are using it.
The Linux DMI class still does not provide the information we need, and parsing
the blob directly also allows the Dell and Redfish plugins to get the raw data.
We can use this as an alternative for GPG. No PKCS7 certificates are currently
installed by fwupd and it's expected that the LVFS will still only provide GPG
detached signatures.
If an OEM distributor wants to sign firmware with a PKCS7 and the corresponding
certificate is provided then the firmware will be marked as valid.
Only firmware shipping with a .p7b file will use the PKCS7 functionality,
similarly remote metadata validation will default to GPG unless Keyring=pkcs7
is specified in the config file.
In this mode, both the metadata and firmware is stored on the local filesystem
and distributed using a distribution system like OSTree.
Fixes https://github.com/hughsie/fwupd/issues/162
The items that 0.6.13 requires are now guarded by a version test.
This should allow running fwupd master on more distros that haven't
yet picked up appstream-glib 0.6.13.
Note: we have to transfer the mtime (not the age) when creating the GVariant,
as we want calls to fwupd_remote_get_age() to update the value without getting
the remote from the daemon each time.
Now we have multiple remotes that can be enabled or changed at runtime we need
to do several things better:
* Only load components from remotes that are enabled
* Only load a component if a higher priority remote has not already added it
Rather than just appending all recieved metadata into one big XML file, save
the original metadata .xml.gz files in /var/lib/fwupd/remotes.d and only load
them in the correct priority order if the remote is known and enabled.
Remove the old /var/cache/app-info/xmls/fwupd.xml file, also noting it wasn't
really a cache file at all but actually something quite important.
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.
This commit provides a new "hwids" subcommand for fwupdmgr that shows the
hardware GUIDs on the local system. It also provides API that plugins can use
to self-disable when a specific HWID does not match.
The GUIDs used in this implementation match that of ComputerHardwareIds.exe
This allows us to 'tag' the components with the correct remote ID value, which
then means we can tell where the firmware information has come from when saving
a composite store. It also allows us use the correct username and password in
the future when downloading the firmware blob itself.
Keep the old D-Bus method around to preserve API for existing clients.
Add the concept of 'remotes' that can dropped into /etc and used as firmware
metadata sources. This may be desirable when firmware is only accessable with
a valid support contract or from behind a VPN.
Make systemd and ConsoleKit support an optional compile time flag
with both enabled by default. If both are used, the ifdef/elif will
ensure only the systemd calls are used so there's no conflict.
This is a large commit that removes all the providers and turns them into
plugins. I think having both providers _and_ plugins was super confusing.
Plugins are loaded at runtime so you could in theory develop a new plugin
without putting it in the fwupd source tree, although there are no installed
headers or PC files as I'm not sure it's a good idea at this stage.
This commit moves all the per-provider docs, tests, notes, debug dumps and test
data to plugin-specific directories -- these also allows the plugin author to
"own" more of the source tree so we don't enforce fu- prefixes and the style
guide everywhere.
This allows us to run the same action on all the plugins in the future, so we
could have a prepare(FuPlugin, FuDevice) and cleanup(FuPlugin, FuDevice) run
on *all* plugins, so doing an update using one plugin would allow us to work
around hardware quirks in other plugins.
If I've broken your out-of-tree provider it's trivial to port to the new API
with sed and a fixed up build file. If you need help please let me know.
This allows us to return multiple results from one file, for instance where the
firmware.cab file contains multiple metainfo.xml files.
This allows us to show all the entries in the firmware file, rather than
searching for the installed device that matches and falling back to just the
first listed item.
Under some circumstances a provider may want to prevent a user from
performing a flash without additional user interaction.
Providers can opt into this behavior by checking for
FWUPD_INSTALL_FLAG_FORCE in the update routine.
