[Lvfs-announce] Rewriting the firmware.metainfo.xml when signing firmware

Hi all,

One of the common tripping points for OEMs and ODMs is that the
uploaded firmware.metainfo.xml does not get rewritten if requirements
are added or other changes are made on the LVFS UI. For instance, if a
vendor QA user adds a requirement of =E2=80=9Cfwupd > 1.3.0=E2=80=9D to the=
 LVFS admin
panel, that stops the automated deployment to older fwupd versions,
but doesn=E2=80=99t stop the user downloading the .cab archive manually and
then doing `fwupdmgr install firmware.cab` on the command line =E2=80=93 as
the original unchanged firmware.metadata.xml is the one that remains
in the archive. This has been confusing for both hardware vendors and
end users, but fixing the issue without causing regressions depended
on lots of other smaller incremental fixes. By rewriting the metainfo
inside the archive every time the firmware is changed on the LVFS we
can ensure the two information sources match every time.

Rewriting the metainfo also allows us to automatically include the
SHA-256 checksum of the firmware blob itself, which unlocks other more
interesting functionality which I=E2=80=99ll explain in the future, once it=
=E2=80=99s
all finished.

Changing the archive does of course change the downloaded file
checksum, but this is not being served by the CDN so is not a huge
concern. It=E2=80=99s also not possible to change the archive when the
firmware is in =E2=80=9Ctesting=E2=80=9D or =E2=80=9Cstable=E2=80=9D. I=E2=
=80=99ve deployed this and enabled
the rewriting for any new firmware uploaded to the LVFS, but the
existing files remain unchanged. I=E2=80=99ve been testing this for a few d=
ays
and I=E2=80=99ve spotted no regressions and an awful lot of fixes. If you w=
ant
to opt-in and =E2=80=9Csync=E2=80=9D a specific firmware which you know is =
affected by
this de-sync issue, please let me know. I=E2=80=99ll be keeping an eye on t=
he
server for the next few days to make sure the metainfo.xml re-writes
continue to operate correctly.

For instance, these are two examples I've seen:

 <?xml version=3D"1.0" encoding=3D"UTF-8"?>
 <component type=3D"firmware">
   <id>com.logitech.Unifying.RQR24.signed.firmware</id>
   <name>Unifying Receiver</name>
+  <name_variant_suffix>Signed RQR24</name_variant_suffix>
   <summary>Firmware for the Logitech Unifying Receiver (RQR24.xx)</summary=
>
   <description>

and

   <developer_name>Hughski Limited</developer_name>
+  <categories>
+    <category>X-Device</category>
+  </categories>
+  <custom>
+    <value key=3D"LVFS::VersionFormat">triplet</value>
+    <value key=3D"LVFS::UpdateProtocol">com.hughski.colorhug</value>
+  </custom>
   <releases>

It should all "just work" like before, but questions welcome off list pleas=
e.

Richard.