Only build libfwupdplugin source files once; we were only using one
non-exported symbol and so move that to the exported map so we can just link
the library in the self tests.
The SREC parser attempts to fill 1Mb of data when parsing corrupt data sections
-- which in the static fuzz targets takes a long time. Correctly check that the
data exists to mitigate.
Fixes https://oss-fuzz.com/testcase-detail/6102934106013696
This adds 7 pointer-size blocks of wasted space for each modular plugin, and
three pointers for builtin plugins, but allows us to use the exact same vfuncs
when building plugins in either mode.
This will allow us to convert nearly all the plugins to being builtin.
This drops the requirement on us being so strict on a particular ABI version,
and also more strongly discourages out of tree plugin development.
We should still strive to keep API stable, and as such keep a symbol map still.
Use rpath instead for the static plugins, and set the plugin install directory
to just fwupd-$ABI$ as we're storing more than just plugins here now.
Saving the quirks in the GResource section worked well, but it made the build
system very complicated and also meant the .data section was duplicated in
both `fwupd` and `fwupdtool` -- negating a lot of the hard-fought savings.
Simplify this feature so that we just `cat` all the quirk files together, then
gzip them into a single file. This means that at startup fwupd only needs to
check the mtime of one file, and weirdly it's actually faster to load a smaller
compressed file from disk that it is to load multiple uncompressed files.
In case no version is found, android-boot plugin uses a fall back
version (0.0.0) but no version format is set. Therefore, fwupd uses
format 'plain' as default which is not correct as 0.0.0 is a triplet.
We want /usr/share/docs/fwupd/libfwupd for the docs that can be referenced from
index.html, and a symlink of /usr/share/docs/libfwupd for devhelp.
This fixes the rpmbuild warning:
# absolute symlink: /usr/share/doc/fwupd/libfwupd -> /usr/share/doc/libfwupd
# absolute symlink: /usr/share/doc/fwupd/libfwupdplugin -> /usr/share/doc/libfwupdplugin
If a specific plugin calls fu_plugin_set_secure_config_value() and then
fu_plugin_set_config_value() then we'll save the file with the world-readable
permissions.
Set a plugin flag to say that 'this plugin is storing sensitive details' which
allows us to use the same entrypoint and also fix up any files at startup that
do not have the correct permissions.
When the redfish plugin automatically creates an OPERATOR user account on the
BMC we save the autogenerated password to /etc/fwupd/redfish.conf, ensuring it
is chmod'ed to 0660 before writing the file with g_key_file_save_to_file().
Under the covers, g_key_file_save_to_file() calls g_file_set_contents() with
the keyfile string data.
I was under the impression that G_FILE_CREATE_REPLACE_DESTINATION was being
used to copy permissions, but alas not.
GLib instead calls g_file_set_contents_full() with the mode hardcoded to 0666,
which undoes the previous chmod().
Use g_file_set_contents_full() with the correct mode for newer GLib versions,
and provide a fallback with the same semantics for older versions.
We now have two plugins getting the ESP values, and we only allow hardcoding
the ESP in uefi_capsule.conf.
Make all this a lot simpler by moving the ESP+BDP code to `FuContext`, which
also means we can handle the override (via the config file) in the engine,
and the override (in the command line tools) using the same mechanism.
Also, automate the migration of the `OverrideESPMountPoint` -> `EspLocation`
when loading the engine.
Fixes https://github.com/fwupd/fwupd/issues/5042
