The test is run if a physical TPM is available or if the environment
variable "TPM_SERVER_RUNNING" is set. In the latter case, the user is
expected to start a TPM simulator on their own, like we do in the Arch
Linux CI script here.
Using the library instead of the command line tools provides a more
stable interface. This implementation only fetches PCR 0 for all
available hash algorithms since this is the only PCR that is actually
used in fwupd.
This allows plugins to rescan hardware based on uevents of any device class
registered with fu_plugin_add_udev_subsystem().
Additionally, the events are rate limited to avoid causing lots of extra plugin
processing when replugging hardware.
tpm2_pcrlist has been renamed to tpm2_pcrread in
aedb0291d2
and the output format has changed slightly to include a leading "0x" in
9374bd70f4
Also add an example of the new output format to the self test.
Since https://fwupd.github.io is now a thing, people can be directed there
rather than relying upon locally built documentation by default.
Also this will mean one less dependency to install for people who build
from source.
Lastly this finally means that I can do this set of actions without failure:
```
meson build
ninja -C build
ninja -C build install (PK prompts for password)
rm -rf build
```
Previously gtkdoc stuff was built as root due to the PK prompt and removing
it would lead to stuff like this:
```
rm: cannot remove 'build/docs/libfwupd/html/libfwupd-FwupdClient.html': Permission denied
```
For now this is happening on every master build, but in the future
after it's working reliably it should be restricted to only tagged
builds.
To accomplish this, swap a build from circlei and travisci that
will save docs to publish.
Fixes Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921820
Introduce a new --log option to fwupdmgr that will log stdout to an argument.
If run under systemd, prefix that argument with $RUNTIME_DIRECTORY.
Add a new systemd unit and associated timer to regularly refresh metadata.
After the metadata refresh is complete, save the output to the motd location.
The timer and service are disabled by default and can be enabled by an admin.
Normally the flag 'supported' is used to indicate that devices can
update from a remote such as LVFS.
Running `#fwupdmgr get-updates` in this situation will show a message
for each device that is already up to date as well as messages for
devices that have updates available.
If no devices contain the supported flag, `# fwupdmgr get-updates`
will show no output, which is confusing to some people.
Show "No updatable devices" instead for those situations.
This controller isn't flashable in fwupd, but fwupd can display information
about it.
* Use a generic device ID (similar to safemode)
* Build device name attribute from DMI data
This allows us to set the subsystem and device file during construction, which
means we can create FuUdevDevice objects not backed by physical devices.
This was previously used when the plugin was only run on Dell devices.
The plugin was already adjusted to run on other vendor's firmware
but this definition was not removed.
There are several subtle bugs in various places in fwupd caused by not treating
user-provided offsets into buffers as unsafe. As fwupd runs as root we have to
assume that all user firmware is evil, and also that devices cannot be trusted.
Make a helper to put all the logic into one place and convert all users.
In many plugins we've wanted to use ->prepare_firmware() to parse the firmware
ahead of ->detach() and ->write_firmware() but this has the limitation that it
can only return a single blob of data.
For many devices, multiple binary blobs are required from one parsed image,
for instance providing signatures, config and data blobs that have to be pushed
to the device in different way.
This also means we parse the firmware *before* we ask the user to detach.
Break the internal FuDevice API to support these firmware types as they become
more popular.
This also allows us to move the Intel HEX and SREC parsing out of the dfu plugin
as they are used by a few plugins now, and resolving symbols between plugins
isn't exactly awesome.
The DW5821e in modem mode uses the 0x81D7 PID, but when it boots in
fastboot mode it uses the 0x81D6 PID. The upgrade procedure was able
to automatically match these two devices because they both shared the
very generic per-VID (0x413C) GUID, but this is no longer operational
since commit 8ef139faba, as the very generic GUIDs have been removed
for matching purposes.
So, define a quirk for the DW5821e, in order to add a counterpart
GUID to make device matching work properly again.
Fixes https://github.com/hughsie/fwupd/issues/1271
If we add or remove a quirk from a machine using the uefi plugin then the new
setting is not used until the BootXXXX EFI key is manually removed. Rather than
just writing the contents of the found key back to the key (doh) just write the
new DP buffer contents if it is different from the previous buffer.
