fwupd hits 1.0.0

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 :)

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

13 thoughts on “fwupd hits 1.0.0”

    1. 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.

      1. 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.

  4. 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. (:

  6. For bios/uefi updates, what is the different usage then flashrom? I am using for years flashrom to update my bios chips.

  7. 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.

Comments are closed.