We used the firmware builder functionality to either build or modify
firmware images on the end-user system, e.g. copying the MAC address
from the old system image to the new system image.
Unfortunately running fwupd on the command line (e.g. ./src/fwupd)
leaves the tty connected and thus bubblewrap doesn't protect us from
installing malicious signed firmware. The firmware would have to have
been uploaded to the LVFS by a trusted vendor and signed before being
installed, which further decreases the severity of this problem.
As there was only one vendor who asked for this functionality (who have
yet to upload a single firmware to the LVFS...) just rip out this
functionality to reduce our attack surface and completely fix the bug,
and any like it.
Many thanks to Aaron Janse <aaron@ajanse.me> for discovering and
disclosing this issue to us.
Several of the string/integer/time functions are duplicated in multiple
source files for no discernable reason. Move them into fwupd-common
as private symbols instead.
Busybox only supports the short option '-k'. (#4866)
Using this instead of '--keep' allows fwupd to be built on systems like Alpine Linux where /bin/gzip is supplied by Busybox.
By pre-commit getting setup early we were installing markdown and
meson into the virtual environment. This might not be a bad thing
if we encouraged virtual environments for development, but we don't.
`yu` was added in 014e5526ff to solve cache issues.
But since then several other invocations of pacman have been added and doing so constantly is pointless, as you are unlikely to see new upgrades while the CI is running (and it might not be desired either). It also breaks testing older versions of fwupd as seen in GH-4860. So upgrade only once at the beginning and keep installing from the same cache afterwards.
When support was added for falling back to SMBIOS data from the kernel
in /sys/class/dmi, we inadvertently stopped caring about the data parsed
directly from DMI tables as first priority. This caused a regression in
hwids from some OEMs that relied upon IDs that could only be properly built
from DMI tables, not the kernel /sys/class/dmi interface.
Link: https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1982103
Fixes: 464425fb5 ("SMBIOS: try reading from /sys/class/dmi if direct access fails")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
We want to allow all the device hotplug events to be processed before
marking the update as completed. Otherwise, we might have a situation
where we have a child device attached to a parent, where we want to
update the parent, then the child. e.g.
1. Add parent
2. Add child
3. Update parent
4. Attach parent
5. Wait for parent
...some time passes...
6. Parent re-appears
7. Update finishes, client indicates success
...child update is scheduled...
...which returns with failure as it does not exist...
8. Add child
The child should have been added *before* the update completed to avoid
the caller from needing an unspecified delay as a *workaround*.
