[hughsient]

> this is probably leaking information thru its comm channel

It's really not. The fwupd process doesn't have any internet access at all -- all communication is done through a socket over DBus. All the telemetry is done with the user explicitly opting in -- we even show the JSON in the terminal that is going to be sent.

> Does anyone know why this is running 24/7

We auto-quit on idle or for low memory conditions -- unless you have hardware that's expensive (either in terms of power, or time) like thunderbolt and synaptics MST. The resident RSS is tiny as we mmap all the data files which can be paged out by the kernel -- we can even run fwupd on the tiny BMC processor as well. I'd be interested in what OpenSnitch says, but the D-Bus interface is the only way in and out. Interesting, the daemon doesn't actually do any policy actions itself; all actions have to be initiated by the front end -- which includes downloading new firmware metadata.

[mixmastamyk]

Good to know. Why is it a root daemon and not a command/library if other tools are directing it? If I had to guess, so the end user does not have to elevate to superuser to initiate actions?

[hughsient]

Yes, mostly that. Depending on local policy, it might be possible to upgrade [only] signed firmware from the correct vendor without authenticating. Downgrade always requires authentication for obvious reasons. Most firmware requires you to be root (some even CAP_SYS_ADMIN) to just enumerate the hardware and read the firmware version.

The other main reasons is that some hardware is really, really slow (like 8 seconds to query a dock PD version, or 12 seconds to query a thunderbolt retimer version) and you can't really build a GUI that can do firmware update operations with potentially minutes of delay for each action. Also, cache invalidation is hard if you can't see the device uevents and usb hotplug events.