In Fedora the only user of libfwupdate is fwupd and the fwupdate command line
tool. It makes sense to absorb the libfwupdate library interface into the
uefi plugin in fwupd. Benefits I can see include:
* fwupd and fwupdate are very similar names; a lot of OEMs are confused
* fwupd already depends on efivar for other things
* We are maintaining an artificial library interface
* The CI and translation hooks are already in place for fwupd
* We don't need to check for features or versions in fwupd, we can just develop
the feature (e.g. BGRT) all in one place.
This is designed to be run as root accessing the hardware directly rather than
using the daemon. This would allow a snap or flatpak package to write firmware
even when the host fwupd daemon is too old.
Also, move the SMBIOS parsing code here as this is not needed in fwupdmgr.
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.
We need to show this agreement text in every fwupd frontend and exporting a
helper function allows us to do two things:
* Share the semi-complicated code (and fallback) to avoid copy and pasting
* Easily change the code in the future, for instance allowing merging Metainfo
and AppStream metadata without updating all the front ends with new logic.
This allows us to use PolicyKit, which means we will get prompted for
authorization if logged in as a user without permissions.
Fixes https://github.com/hughsie/fwupd/issues/455
As part of this ignore extra string arguments other than the device
ID for these methods.
This has two benefits:
1) No more copying and pasting device ID's for any of these methods
2) Bash completion can now show nicer output for these methods
This shares your history with a reporting server, typically the LVFS.
NOTE: no data is sent without the user opting-in, and the data sent is shown to
the user before upload.
Rename FuPending to FuHistory to better represent what the object is now doing.
Also, while we're here, switch to using SQLite prepared statements to avoid a
possible invalid read on i386 hardware.
Always set the AppStream app properties on the FwupdRelease. In some cases we
were returning FwupdRelease objects with no name or summary which gnome-software
was ignoring.
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.
This allows us to match up the AppStream data we've parsed in gnome-software and the firmware update we've got from fwupd. This means we can get access to some of the data that fwupd doesn't care about, for instance the how-to-upgrade screenshots.
readlink() man page says that applications must not rely on it returning
null-terminated links. This commit switches it to use g_file_read_link()
instead that has much nicer API and shields us from readlink() oddities.
The firmware may be more generic, and it also allows us to match the GUID then
doing 'verify' on a device with a different device PID than the firmware
actually declares.
This allows the text clients like fwupdmgr to convert to UTF-8 text, and
graphical clients can use the markdown target to ensure the links are made
clickable and paragraphs are presented in the right way.
This downloads the latest version of the firmware and applies it to any
matching hardware. e.g.
$ fwupdmgr update
Downloading 1.2.3 for ColorHug...
Updating 1.2.3 on ColorHug...
* Loading firmware
* Decompressing firmware
* Restarting device
* Writing firmware to device
* Verifying firmware from device
* Restarting device
Done!
The way this works is we try with the user settings, and if this fails with
NotSupported and the offline flag is unset then we retry the action with a
warning and the flag manually set.
I chose to do this in the client rather than the daemon as I don't want to
encode too many magic rules when we don't know the kind of devices that will
appear in the future.
Fixes the other half of https://github.com/hughsie/fwupd/pull/23
It seems a little odd to call it 'Update' when it's being used for downgrading
and reinstalling as well.
As we're making things simpler, just use a single 'install' action in fwupdmgr
rather than 'install', 'update-online', 'update-offline'. We can use the flags
and fallbacks to do the right thing in all cases, and make the typical case
(installing a local file to any matching hardware) simple.
Fixes half of https://github.com/hughsie/fwupd/pull/23
This only returns the latest version, if you actually need to know details
about all versions including downgrades then you still need to load the
AppStream metadata and match devices manually.
