Updates on/with "Linux Vendor Firmware Service" (LVFS)

[rugk]

Maybe some Linux users do not yet know the Linux Vendor Firmware Service. However, it’s a great combined effort (as per this whitepaper also on the freedesktop.org site) to be able to update flashable devices in your devices, without having to boot Windows/Mac OS or so.

Well… in any case, what matters is that you get firmware updates on many Linux distros. Here e.g. with GNOME:

Or KDE:

More information for end users are here. (screenshots also taken from there)

If it all works, this would prevent the burden for Linux users to fiddle with the command line for updates as it is currently the case (instructions at the bottom of linked site), and would enable a secure one-click update for your Nitrokey (Storage) devices.

---

To get to the technical details, this whole thing depends on Nitrokey, of course. And, good news, actually they are already included in the vendor list on the site!
Bad news: They have not yet submitted any stable firmware updates there (last red column) and their statement there says:

The Nitrokey storage device should be supported soon

“Soon”??

Note that actually one update for the “Nitrokey Storage” has been published (v0.50). However, there are some strange points about it:

1. On the site, it is listed as a “testing” update. Quote:

   Warning: This firmware is in the testing state and may not be suitable for production systems.

   However, the description of the update itself claims it is stable (highlighting by me):

   This stable release fixes the following issues: […]

2. The security info at the bottom shows: “Update is not cryptographically signed” and “Firmware cannot be verified after flashing”.
   This may not be a problem if the update is verified on the Nitrokey itself when applying. But an additional signature would not have been wrong. And it would have removed that pesky warning.

Even major other vendors like Dell are better at this and regularly upload firmware there. So I would have expected you to do better as a privacy-centric vendor, especially when you are being preferred by Linux users and even Linux kernel maintainers use your devices.

Note that 0.50 is also an outdated release as of the date when writing this post, so you should really get on that and deliver updates in this way.

[rugk]

BTW looked through some forum threads to see whether users have issues with the command-line way of updating on Linux, and yes, obviously they have. There are issues that users may not verify the update, or that they simply have typos and thus get errors.
Note this can be security-relevant, should such a firmware update published in the future, that fixes some vulnerability or so.

So I’ve also opened a GitHub issue for that problem here.

[rugk]

Actually as the author of fwupd writes in his blog, the security indication is about whether the hardware verifies the signature of the firmware. So, I guess, you have just selected the wrong checkbox or so, as (I hope) the Nitrokey does it, does not it?

The update tool can even detect corruptions of your firmware, so it is really the way to go!

[nitroalex]

Hi rugk,

thank you very much for the heads up! Indeed you convinced me in the very beginning, no need to bump every related post here

@rugk

Even major other vendors like Dell are better at this and regularly upload firmware there.

Please mind the difference in man-power and money I think you are totally right and thus we will work on it. I think this variant is much better than the dfu-programmer variant. Please give us some time to make this work!

@rugk

Actually as the author of fwupd writes in his blog, the security indication is about whether the hardware verifies the signature of the firmware. So, I guess, you have just selected the wrong checkbox or so, as (I hope) the Nitrokey does it, does not it?

We have no signature verfication built in (yet). The flashing is protected by a password and can be verified afterwards at least.

As I said we try to improve the workflow and I thank you for mentioning it!

Kind regards
Alex

[szszszsz]

@rugk

To get to the technical details, this whole thing depends on Nitrokey, of course. (…)
Bad news: They have not yet submitted any stable firmware updates there (last red column) and their statement there says:

The Nitrokey storage device should be supported soon

“Soon”??

Hi @rugk !
This is fwupd administrator’s comment, so I cannot add much. Most probably he meant the plugin for checking the firmware version, which is up for some time and seems to work (AFAIR in my testing). I cannot say this entirely depends on Nitrokey, since we do not develop the fwupd service, and could offer support for testing mostly. There is nothing about that on the vendors site as well.

I could not confirm the update process had worked ever on the Storage devices, so the firmware on fwupd never went out from the testing stage. This is though the same firmware one could download from the Github’s releases page (minus my signature).
The actual update process was never initiated by the fwupd last time I have tested. And I could not provoke it to run; it seems to be confused due to the device being missing, while switching to the update mode. I hope you understand I could not move the firmware to stable in such circumstances.

I have already sent a report about it last year, though could not pursue that further due to other coming work, hence the subject suspended.

You can see, that we started the support early, by looking at the commits from the fwupd firmware package building. Hopefully we will close the topic in the near future, especially now when the fwupd project has matured.
I have added a new package build instructions for the v0.53 firmware, uploaded a hidden/internal firmware for testing to the service, and we will see what can we do about it further.

@rugk

The security info at the bottom shows: “Update is not cryptographically signed” and “Firmware cannot be verified after flashing”.

I agree with the questions, though I cannot reply to them, but fwupd administrator.
From my POV: firmware is signed on the Github release page, and it is surely possible to verify that signature on the fwupd server. Secondly, this is the DFU protocol, and my dfu-programmer tool shows, that it can download back the firmware file from the device, so again fwupd can verify the flashing process. If by this it is meant to provide some checksum, I would like to see some API for that, so I could implement it.
Storage device does not verify the firmware’s signature, but user could do that (against detached GnuPG signatre) before the upload.

Let me know in case you would have any further questions. I plan to contact the fwupd’s administrator to establish further work schedule.

[rugk]

@nitroalex

The flashing is protected by a password and can be verified afterwards at least.

Note, however, that this “verification afterwards” can (and probably should) also be automated via fwupd. Actually it is one of the missing ticks, I’ve talked about before.

---

Thanks @szszszsz for the clarification and background info.

@szszszsz

I have already sent a report about it last year, though could not pursue that further due to other coming work, hence the subject suspended.

I guess this bug report is public, is not it? If so, can you give us a link? (We could at least upvote it and show this is needed.)

@szszszsz

I plan to contact the fwupd’s administrator to establish further work schedule.

Great. Note that I’ve already pinged him on the GitHub issue, but it’s possible he does not pay attention to that…