Now devices can have multiple GUIDs and do not share platform IDs there is
really no point waiting to add the device.
This allows us to remove a whole lot of code for this now-unused functionality.
Now we can update multiple devices (in multiple plugins) using one firmware
archive we need a way to cleanup after all the plugins have been run.
Fixes https://github.com/hughsie/fwupd/issues/561
When using failed to open firmware.cab we pass in a device ID of '*' which
tells the daemon to update anything that matches. The current implementation
will fail in two ways:
* If duplicate hardware is installed (for instance two Unifying receivers) then
only the first matching device will be updated.
* If the firmware archive contains two different images then we only try and
upgrade the first device that matches. This means we're unable to update
composite devices using one firmware file.
To fix both issues, carefully build a list of tasks that can be processed using
the given firmware and installed devices, request authentication using all the
different action IDs, then upgrade all the devices one-at-a-time.
Based on a patch by Mario Limonciello <mario.limonciello@dell.com>, many thanks.
GLib creates two static inline functions for paramaters that may
not be used that set off warnings in clang but not gcc.
Ignore these on clang builds everywhere that
G_DEFINE_AUTOPTR_CLEANUP_FUNC is used.
It's actually less scary to see a SHA1 hash than it is to see a path like
/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.2. It's also way easier to
copy and paste into the various fwupdmgr command that require a device ID and
also means we can match a partial prefix much like git allows.
If we also move to a model where plugins can be changed during different stages
of the update (e.g. during detach) then the device might change connection type
and then the sysfs path not only becomes difficult to paste, but incorrect.
Session software doesn't care about the format of the device ID (it is supposed
to be an implementation detail) and so there's no API or ABI break here. A few
plugins also needed to be ported, but nothing too worrying.
This allows end-users testing a specific plugin to start fwupd with an extra
command line parameter, e.g. `--plugin-verbose=unifying` to output a lot of
debugging information to the console for that specific plugin.
This replaces a lot of ad-hoc environment variables with different naming
conventions.
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.
