Introduction

This page provides a place for hardware vendors to submit packaged firmware updates, typically cab files. This fire-and-forget service allows vendors to submit firmware updates without generating and hosting metadata themselves.

Clients such as fwupd periodically check for updated metadata at this site and will offer the firmware to end users or be installed automatically depending on site policy.

NOTE: This service should only be used to distribute firmware that is flashed onto non-volatile memory. It is not designed for firmware that has to be uploaded to devices every time the device is used.

There is no charge to vendors for the hosting or distribution of content.

When files are submitted the following actions are performed:

The update metadata is checked for correctness.
The firmware capsule is signed with our GPG key.
The new cab file is moved to our infrastructure.
The metadata is added to our database.

Upload Firmware

It is imperative that updates have been verified to work correctly on all matching hardware.

Legal

By uploading a firmware file you must agree that:

You are legally permitted to submit the firmware.
The submitted firmware file is permitted to be mirrored by our site.
The firmware installation must complete without requiring user input.
Firmware must not engage in malicious activity (e.g. be viruses, worms, or exploit security issues).
Firmware can only be removed from this archive in exceptional cases.

Vendor Key:
Firmware:

Help With Submitting Firmware

If you are not using the UEFI capsule update method you need to write a plugin for fwupd to trigger the firmware update from userspace. At the moment there is just UEFI and ColorHug providers, but others are welcome.

As per the Microsoft guidelines package up your firmware into a cab file, with these files inside:

The actual cap file your engineers have created
The inf file describing the .cap file.
The optional asc file which is a detached GPG signature of the firmware file.
The optional metainfo.xml file with a long description and extra metadata

You can create a cab file using makecab.exe on Windows and gcab --create on Linux.

It is recommended you name the cab file with the hardware name and the version number, e.g. colorhug-als-1.2.3.cab. It's mandatory that the files inside the cab file have the same basename, for example this is would be valid:

    colorhug2-1.2.3.cab
     |- firmware.inf
     |- firmware.bin
     |- firmware.bin.asc
     \- firmware.metainfo.xml

An example inf file looks like this:

[Version]
Class=Firmware
ClassGuid={f2e7dd72-6468-4e36-b6f1-6488f42c1b52}
DriverVer=03/03/2015,3.0.2

[Firmware_CopyFiles]
firmware.bin

[Firmware_AddReg]
HKR,,FirmwareId,,{84f40464-9272-4ef7-9399-cd95f12da696}
HKR,,FirmwareVersion,%REG_DWORD%,0x0000000
HKR,,FirmwareFilename,,firmware.bin

An example metainfo.xml file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Copyright 2015 Richard Hughes  -->
<component type="firmware">
  <id>84f40464-9272-4ef7-9399-cd95f12da696</id>
  <name>ColorHugALS Firmware</name>
  <summary>Firmware for the ColorHugALS Ambient Light Sensor</summary>
  <description>
    <p>
      Updating the firmware on your ColorHugALS device improves performance and
      adds new features.
    </p>
  </description>
  <url type="homepage">http://www.hughski.com/</url>
  <metadata_license>CC0-1.0</metadata_license>
  <project_license>GPL-2.0+</project_license>
  <developer_name>Hughski Limited</developer_name>
  <releases>
    <release version="3.0.2" timestamp="1424116753">
      <location>http://www.hughski.com/downloads/colorhug-als/firmware/colorhug-als-3.0.2.cab</location>
      <description>
        <p>This stable release fixes the following bugs:</p>
        <ul>
          <li>Fix the return code from GetHardwareVersion</li>
          <li>Scale the output of TakeReadingRaw by the datasheet values</li>
        </ul>
      </description>
    </release>
  </releases>
</component>

If the firmware is not free software you have to indicate it in the metainfo.xml file with <project_license>proprietary</project_license>.

Why does the LVFS project sign my firmware?

The Linux Vendor Firmware Project signs the firmware image and repacks the files into a new cabinet file for several reasons:

Only trusted vendors have access to the LVFS service, so we can be sure the firmware actually came from the vendor
Clients do not (yet) verify the signatures in the cat file
Not all software trusts the Microsoft WHQL certificate
We ensure that only required files are included in the cabinet file, typically making the download size much smaller

Validation

The best way to validate the metainfo file or firmware before submission is by using the appstream-util validate tool available from the appstream-glib project.

Go back to the main page