Bug#916036: Install fwupd on a default installation

[Philipp Kern]

Hi Mario,

first of all thanks for your pointers!

On 27/12/2018 20:28, Mario.Limonciello at dell.com wrote:
>> Just the fact that the update claims that the hardware only accepts
>> signed updates or something else? :)
> 
> At a minimum a claim.
> 
>> I will note - although slightly off-topic to the discussion at hand -
>> that it would be useful to people to be able to run their own repository
>> of updates and control the rollouts (and staging percentages)
>> themselves. I'm not actually suggesting that Debian would need to run
>> their own, but it'd be a useful service to the users who don't want to
>> send telemetry to the Linux Foundation - and furthermore have a
>> significant deployment where it's worth canarying the updates.
> 
> Entirely doable.  LVFS can be set up locally with the firmware that is interesting
> uploaded to that "instance".  This will mean setting up a GPG key pair and signing
> the firmware with that instance as well.
> 
> On fwupd clients a "remote" needs to be registered for that instance with the public
> key and instance location.

So I suppose mirroring would entail fetching the firmware.xml.gz from 
LVFS' CDN and then downloading and rewriting the release locations - 
plus dealing with signing the metadata. That seems fairly straightforward.

If there would be a way to check the provenance of an updater package 
(i.e. not just rely on arbitrary vendor authentication on the backend), 
that'd still be nice.

(Plus percentage-based rollouts, but that's just yet another feature 
request. :)

> FYI: Telemetry related to the update is entirely optional and "opt-in" after you've
> performed an update.
Thanks, I found a note on [1] and if it's indeed per remote, it should 
be fairly easy to manage.

>> Fair enough. Do you have a pointer for examples of such updates?
>> Unfortunately I updated my own Dell dock recently from Windows, so I
>> can't easily check. Mostly I'm interested if it's a proprietary binary
>> run on the host. That's its own can of worms. (Which technically is true
>> for the EFI update too, but it's staged from outside of Linux on
>> boot-up.)
> 
> Executing proprietary binaries distributed in the CAB file is against fwupd
> philosophy and prohibited.  All code for the plugin that executes in Linux and
> is distributed with fwupd must be open source.
> 
> fwupd only pulls "payloads" from the CAB files.
> 
> Regarding the examples I called out:
> You can review the fwupd tree in the plugins/ directory to see the
> * thunderbolt/ plugin which uses the kernel Thunderbolt interface
> * dell-dock/ plugin which uses kernel USB interfaces
> * dell/ plugin which uses a EFI binary for TPM and dock updates
> * ebitdo/ plugin which uses kernel USB interfaces
> * rts54hid/ rts54hub/ plugins which use kernel USB interfaces
> 
> There are many more, you can look more closely at your leisure.
> 
> The matching binaries that are on LVFS.
> Here's some examples:
> Thunderbolt: https://fwupd.org/lvfs/device/4eeb9d07-a96c-56d6-92d3-4a23ee7a6e4a
> MST: https://fwupd.org/lvfs/device/be025b25-ca5c-546c-97c6-ee2160ba489d
> 8bitdo: https://fwupd.org/lvfs/device/8baed357-638e-5b54-b582-0476bf7d6348
> TPM: https://fwupd.org/lvfs/device/e58a5f6d-ba78-5f0f-a35f-612f97ca8c9a

I cannot tell you how happy this makes me. This is awesome. Thank you 
(and everyone else who contributed to this effort) for doing the right 
thing! And obviously kudos to Dell for staffing this.

The plugin library seems to be on [2] and there's a sizable set of them. 
Even an AMT updater. :o

Kind regards and thanks
Philipp Kern

[1] 
https://blogs.gnome.org/hughsie/2018/01/10/phoning-home-after-updating-firmware/
[2] https://github.com/hughsie/fwupd/tree/master/plugins