Comment 26 for bug 1536871

Mario, excellent detective work. I was going around in circles earlier
today trying to explain why Richard couldn't reproduce my failures and I
couldn't reproduce his successes.

Richard, thanks for describing the xtea use and md5 KDF. If this were an
important part of the project I'd be far more concerned. xtea is an
awkward cipher, xtea appears to be used in ECB mode, md5 kdf is far from
best practice, and the encryption isn't authenticated. It seems fair for
firmwares that are basically public anyway, and if they've got private
data at least it isn't cleartext on disk before a user can use gpg -c or
something.

Even though I personally had great trouble following the code flow
compared to similar tools such as apt:
- the code is clearly developed with discipline
- the upstream author is clearly responsive and careful.
- Mario's familiarity with the code shows that it's more about me than
  fwupd. :)

I'm afraid that I don't have the time to finish the usual MIR checklist
for this package. The important part is that the code looks sane, upstream
is friendly and helpful, and I'm now satisfied that a chain of trust is
followed from a GPG key to the firmware to be installed. (I haven't yet
seen it myself due to the bugs that Mario discovered but he seems well on
the way to having it fully functional.)

I'd very much like to see the firmware.xml.gz file using sha-256 or
sha-512 hashes before release -- 16.04 LTS is supported until 2021, and
SHA-1 looks funny now, I imagine in five years we'll be finding SHA-1
collisions while eating breakfast just to keep sharp in our old age.

Thank you both for your help.

Security team ACK for promoting fwupd to main on the condition that
gnupg2 2.1 is merged or workarounds for gpgme are developed.

Thanks