This moves more functionality out of the engine, and will allow us to add some
cleverness to the device list to allow the FuDevice to be shared between
different plugins.
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 us to do two things:
* Attach after a failed update, so the user isn't left with 'dead' hardware
* Split the detach and attach actions into different plugins in the future
This also allows us to have a separate vfunc to get the new version number
after flashing the firmware, as this may be handled in a different plugin to
the detach phase.
In the latest version of the LVFS you can restrict the firmware to a specific
machine type, for instance a specific baseboard vendor. This is the same as
done in Microsoft Update using the CHID mechanism.
This commit adds support for the <hardware> requires type, although it needs to
be built against appstream-glib 0.7.4 to be supported and/or tested.
When fwupd is installed in long-term support distros it's very hard to backport
new versions as new hardware is released.
There are several reasons why we can't just include the mapping and quirk
information in the AppStream metadata:
* The extra data is hugely specific to the installed fwupd plugin versions
* The device-id is per-device, and the mapping is usually per-plugin
* Often the information is needed before the FuDevice is created
* There are security implications in allowing plugins to handle new devices
The idea with quirks is that the end user can drop an additional (or replace
an existing) file in a .d director with a simple format and the hardware will
magically start working. This assumes no new quirks are required, as this would
obviously need code changes, but allows us to get most existing devices working
in an easy way without the user compiling anything.
This allows us to fix issues like https://github.com/hughsie/fwupd/issues/265
This allows a plugin to see if a GUID is supported in the AppStream metadata of
configured remotes. It allows plugins to skip devices that are not supported
and that do bad things when probed.
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 latter, as you could have a .cab file with multiple versions of the
firmware and only the first being signed.
For a few months the lvfs-testing remote has not included firmware already
present in the stable lvfs remote. This means if you enable the testing remote
then components in the stable remote are not available to fwupd.
Instead of a simplistic check on the component ID, add the missing releases
no matter the ordering of the remotes.
This was only ever added for gnome-software, and is too inflexible for anything
else. It turns out we don't even need it in GNOME, as we can construct a
suitable ID ourselves using the existing values.
It was also ambiguous whether the unique ID was in reference to the device
or release -- and for gnome-software we need both.
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.
Over the months the original meaning of ALLOW_OFFLINE and ALLOW_ONLINE have be
lost, and there is now a confusing mixture of uses in the source tree. With this
commit we make it clear the UPDATABLE flag is used to specify when the device is
updatable (e.g. from the desktop live session, or from the systemd offline
updates mode, or both) and the NEEDS_REBOOT flag lets us know when the update
is actually going to be done.
For instance, a UEFI UpdateCapsule can be *scheduled* from either the desktop
or from the update mode (but the latter would be a bit weird), but does require
a reboot. Some devices might only be updatable outside the live session, for
instance a hard drive update or a GPU update -- there's just too much going on
with a live session and we want to tightly control what's running during the
firmware flash.
This also means we don't have to "retry" the update when scheduling an update
that really can be scheduled whenever, but just requires a reboot to apply.
This could be used, for instance, to set a property on ThunderBolt controllers
inside Dell computers saying that they support forcing the power level during
coldplug. It could also be used to set the dock type for the synapticsmst hub.
Adding this level of complexity allows us to avoid the creep of HAVE_DELL and
HAVE_LENOVO into seemingly unrelated plugins, and also allows us to have
multiple vendor plugins providing the same end result with two different
vendor-specific mechanisms.
This means we return an error when encountering a rollback attack. This can
currently be performed by providing the old metadata and old signature when
calling into UpdateMetadata.
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.
This avoids open()ing and close()ing multiple times on hotplug -- which in
itself isn't a huge problem as the requests are refcounted in libusb, but it
matters hugely when a plugin accidentally closes a device that was not opened.
As all the devices are going to be opened anyway (to read the vendor strings)
and the cost of keeping the device is open is tiny, just get libgusb to
auto-open *all* devices and keep them open for the duration.
Fixes: https://github.com/hughsie/fwupd/issues/155
When reading with g_dir_read_name() the returned files do not have to be sorted
in any particular order and could even change between invokation. This patch
makes debugging the interactions between plugins much easier.
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.
We used to do this dance to avoid reading the Option ROM on hardware by default
(some faulty hardware would crash...) but now we're doing the verify update in
the daemon there's no need to split this into two steps.
Fixes: https://github.com/hughsie/fwupd/issues/149
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.
