Today I released fwupd version 1.0.0, a version number most Open Source projects seldom reach. Unusually it bumps the soname so any applications that link against libfwupd will need to be rebuilt. The reason for bumping is that we removed a lot of the cruft we’ve picked up over the couple of years since we started the project, and also took the opportunity to rename some public interfaces that are now used differently to how they were envisaged. Since we started the project, we’ve basically re-architected the way the daemon works, re-imagined how the metadata is downloaded and managed, and changed core ways we’ve done the upgrades themselves. It’s no surprise that removing all that crufty code makes the core easier to understand and maintain. I’m intending to support the 0_9_X
branch for a long time, as that’s what’s going to stay in Fedora 26 and the upcoming Fedora 27.
Since we’ve started we now support 72 different kinds of hardware, with support for another dozen-or-so currently being worked on. Lots of vendors are now either using the LVFS to distribute firmware, or are testing with one or two devices in secret. Although we have 10 (!) different ways of applying firmware already, vendors are slowly either switching to a more standard mechanism for new products (UpdateCapsule/DFU/Redfish) or building custom plugins for fwupd to update existing hardware.
Every month 165,000+ devices get updated using fwupd using the firmware on the LVFS; possibly more as people using corporate mirrors and caching servers don’t show up in the stats. Since we started this project there are now at least 600,000 items of hardware with new firmware. Many people have updated firmware, fixing bugs and solving security issues without having to understand all the horrible details involved.
I guess I should say thanks; to all the people both uploading firmware, and the people using, testing, and reporting bugs. Dell have been a huge supporter since the very early days, and now smaller companies and giants like Logitech are also supporting the project. Red Hat have given me the time and resources that I need to build something as complicated and political as shared infrastructure like this. There is literally no other company on the planet that I would rather work for.
So, go build fwupd 1.0.0 in your distro development branch and report any problems. 1.0.1 will follow soon with fixes I’m sure, and hopefully we can make some more vendor announcements in the near future. There are a few big vendors working on things in secret that I’m sure you’ll all know :)
Fantastic work :-)
Inspired from this one? https://man.openbsd.org/fw_update
No, it’s a different thing entirely. The fwupd daemon installs persistent firmware on devices, not runtime-loaded firmware for drivers. I wasn’t aware of the BSD fw_update until today.
What could help to support Logitech keyboard K830?
You could file an issue on https://github.com/Logitech/fw_updates perhaps.
Thank you for the advise. I’ll do that. And thank you for all your work on fwupd. On a debian system I was already able to update four Logitech Unified USB receivers without a hassle.
Great work! I hope some day I can update my Dell Inspiron 7000 automagically without writing the update file on a FAT32 formatted USB stick and reboot to the BIOS Updater. But I think with your help soon this is will happen. (:
Can You update firmware for NES30 Pro (and SFC30 Pro) to newest package (4.01) – http://support.8bitdo.com/#tab2 This update is quite important for Nintendo Switch users.
I’ve just moved them to stable, they were in the testing remote.
For bios/uefi updates, what is the different usage then flashrom? I am using for years flashrom to update my bios chips.
It’s just a different mechanism — flashrom is also supported in fwupd for the purism laptop.
Is the security architecture documented and implementation being audited? Gnome, systemd, etc are enormous. Security is not their top priority, and it needs to be for persistent firmware. Firmware malware is permanent, as in, never coming back from, brick or pwn’d forever (in ways the operating system will never detect). Seeing such a large trusted compute base in a firmware updates, instinctively makes me uncomfortable. It’s functionality that really needs the smallest attack surface and greatest supply chain integrity. That includes all things it depends on (at build time and runtime) and they depend on; everything it touches and everything else running on the machine at the same time. I don’t even like the idea of doing it online with a kernel as enormous and open as Linux has. Should at least be booting into a minimal, isolated environment I would have thought.
Yes, we’ve have multiple audits from several different teams. Security is obviously a huge priority for the fwupd team.