Bug#916036: Install fwupd on a default installation

[Mario.Limonciello at dell.com]

Something I think worth mentioning is that LVFS is being transitioned to being run
and managed by the Linux Foundation.

>Interestingly enough the vendor signs a blob (CAB file) and LVFS throws
> it away and re-signs the blob with its own key. But then again I think
> the base assumption is that the contained firmware images are themselves
> signed as well and the BIOS does a check before ingesting them.

Speaking on behalf of one of the biggest distributors of firmware on LVFS (Dell)
I can say that all of the firmware images are signed by Dell PKI infrastructure and
will not flash on the system if modified.

LVFS is currently in the process of plumbing this information through to the U/I
as well.

> Obviously you end up with the usual concerns like the repository being
> able to hold back updates from certain clients. The website's code is
> supposedly available on https://github.com/hughsie/lvfs-website/ though
> and I suppose a transparency effort could solve that particular problem,
> too.

LVFS is able to prevent distributing updates in two situations:

1) when there are known bad SW combinations (say vendor knew bug existed in fwupd
1.0.x but was fixed in 1.1.x - set minimum version for the update to be 1.1.x).
or need to update device XYZ before device ABC.

2) rate limiting of updates
To stage rollouts and monitor optional feedback in the event of a problem.

> Oh yes. Not just that, also finding the right image to apply and then
> figuring out how the hell to apply it is a solved problem with EFI-based
> fwupdate.

Please keep in mind it's much much more than EFI updates now too.  There are updates
that can apply "in Debian" without a reboot for things like Thunderbolt controllers, docks, 
MST hubs, and various USB devices.