The idea here is that we move a lot of the 'meat' out of fu-main into the
engine. This also lets us simplify a lot of things and ensures the user
authentication is simple and easy to audit.
If something changes the cache behind our back (e.g. deleting or updating the
file) we need to reload the list of remotes so that the age is correctly shown.
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.
The list of verification hashes is certainly not a cache, it's important data
that needs to be kept for a long time somewhere important.
Move it from /var/cache/app-info/xmls to /var/lib/fwupd and delete the old file
as it may have now-incorrect contents.
When processing the file handles it seems g_variant_get() actually wants to
write the fd integer. This bug does not happen every time, and seems to vanish
every time under valgrind.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1460429
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.
If this is not done the origin from the last file that was read (which might be
from Fedora, for instance) will be used. This isn't hugely important but can
give misleading and confusing unique-id's in gnome-software.
Poll each plugin, and only register the service when all the delayed coldplug
devices have been added to the device list. This prevents returning an error
when calling "fwupdmgr get-devices" for the very first time.
Resolves: https://github.com/hughsie/fwupd/issues/82
This allows a plugin to signal the daemon that something has happened and that
all plugins should wake up connected devices, re-add them all and then put the
devices back to powersave mode. Any duplicate devices will be ignored.
This functionality is required so that AppStream metadata can check the fwupd
version, the firmware version, bootloader version or a combination of all three.
This allows us to have new markup specified in the MetaInfo or AppStream XML:
<requires>
<id compare="ge" version="0.8.1">org.freedesktop.fwupd</id>
<firmware compare="ge" version="0.1.2"/>
</requires>
This means that only updates that match these versions will be shown.
The user will not be notified about firmware security updates all the time they
are on battery power. It's better to handle this in the client prompting the
user to connect the AC power source.
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 means we don't have more that one thread just watching for the USB
hotplug events. To achieve this split up the coldplug into setup and coldplug
phases and run the enumerate just once in the daemon.
ifdef cannot be used to determine if a C symbol is defined, as it’s
evaluated by the preprocessor, before symbols are parsed. Instead, try
to detect whether polkit.h is suitably recent enough to define its own
auto-cleanup functions.
Signed-off-by: Richard Hughes <richard@hughsie.com>
Providers that have both online and offline update methods don't
do verification that the device actually supports that mode.
This caused problems for Dell TPM devices where if you called
$ fwupdmgr install tpm.cab
It would attempt to use the online stub added in 1d97c8b5.
This would of course fall over requiring you to call with
$ fwupdmgr install tpm.cab --allow-offline
This fix will guarantee that the current install fallback
logic takes into account both device and provider support
for online/offline.
This means we have a different cache-id for locally modified .cab files.
This allows us to update the text in the metadata without reloading the client.
This provider will provide support for items that can be flashed
as capsules but aren't present in the ESRT table.
The MST hub and TBT NVM are not yet updatable, but GUIDs are
created to represent them when they are.
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.
