Comment 11 for bug 1536871

Hi Seth,

I'm the upstream of both fwupd and the LVFS. I wanted to point out a few things:

* We use a GPG detached signature of the firmware file itself to avoid being able to just C&P the signature between cab files
* I've reviewed (and fixed critical warning bugs) in libgcab, and have also fuzz tested it (afl) over several days so I'm fairly sure there isn't any exploit here. You want libgcab >= 0.7 for these fixes.
* The metadata also has to be signed by the LVFS GPG key (or another key in your keyring) before it will be parsed by fwupd.
* We require a higher PolicyKit authentication level for installing older versions of firmware than you have currently installed, and in UEFI vendors can set the `version_lowest` key if they also want to forbid this if for instance a on-flash index has been upgraded.
* The checksum is more of a test of a correct download and isn't actually used for the trust calculation. It could be entirely omitted and remain secure, although it does provide a better UX in that we can say "the firmware download was corrupted" rather than "the firmware signature wasn't correct".

Also, the download of files from the LVFS comes over SSL (to avoid MITM), although we don't actually require that before parsing things in the daemon as we just pass down from the client to the server a blob. Even if you were MITMd the files would have to be resigned with a GPG key in your keyring, and if an attacker has that there are easier ways to attack your system :)

I can look at moving from SHA1 to SHA256, but I don't really think this is a reason to block the package for the reasons I gave above. I'm happy to answer any questions you've got, and am also happy to have a call (GMTish timezone) if you'd like me to give you a high level overview of the system, or for a deep-dive into the code.

RIchard