Until gi-docgen is declared stable support either of them.
This effectively means that hand builds and CI builds will use
gi-docgen, but distro builds use gtk-doc-tools.
When this is done, include:
* Including the hash
* Including anything that is not ABI stable in plugins yet
Suggested-by: Simon McVittie <smcv@debian.org>
The logic here is that the attestation is more than just the PCR0 value, and
multiple device firmware (such as EC, ME, etc.) needs to be included to validate
the system.
By the same logic, updates for the system firmware do not tell the whole story,
and confuse HSI as a specification. Remove them.
At the moment at startup we're calculating the attrs so we can export the HSI
string property on the D-Bus interface. Running `fwupdtool security` actually
gets all the security attributes at least twice!
To do this, rely on the AppStream ID to map to a translated string (providing a
fallback for clients that do not care) and switch the free-form result string
into a set of enumerated values that can be translated.
This fixes some of the problems where some things have to be enabled to "pass"
and other attributes have to be some other state. For cases where we want the
user to "do" something, provide a URL to a wiki page that we update out-of-band
of fwupd releases.
This exports FuSecurityAttrs into libfwupdplugin so that we can pass the plugins
this object rather than a 'bare' GPtrArray. This greatly simplifies the object
ownership, and also allows us to check the object type before adding.
In the future we could also check for duplicate appstream IDs or missing
properties at insertion time.
This change also changes the fu_plugin_add_security_attrs() to not return an
error. This forces the plugin to handle the error, storing the failure in the
attribute itself.
Only the plugin know if a missing file it needs to read indicates a runtime
problem or a simple failure to obtain a specific HSI level.
