[MIR] fwupd

[Robert Ancell]

[Availability]
In Universe

[Rationale]
Required for GNOME Software (MIR in bug 1536870). Firmware updating functionality is very desirable for OEMs / users.

[Security]
No known issues.

[Quality assurance]
No bugs in Debian or Ubuntu.

[Dependencies]
All dependencies in main except fwupdate (bug 1508926) and gcab (bug 1475021).

[Standards compliance]
Follows GNOME standards.

[Maintenance]
Will be maintained in Debian.

[Mathieu Trudel-Lapierre (cyphermox)]

I'll review this MIR.

[Mathieu Trudel-Lapierre (cyphermox)]

There is still fwupdate and gcab not in universe.
There is no team subscribed to the bugs for the package on Launchpad.

There also appears to be some important bugs that could be fixed with the next upload for fwupd; in the Debian BTS.

Also, tests currently don't appear to be run, although an upstream commit suggests they are probably fixed now; this should be investigated and corrected if possible.

Finally, since this would be running a daemon as root on the system, and deals directly with hardware with the risk of breaking firmware (or causing a denial of service with an invalid firmware update, requesting a reboot, etc.), I think this warrants security review.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mario Limonciello (superm1)]

Just wanted to check in on this security review for MIR. Is it still going to be done?

[Tyler Hicks (tyhicks)]

On 2016-03-02 17:53:17, Mario Limonciello wrote:
> Just wanted to check in on this security review for MIR. Is it still
> going to be done?

It is scheduled to start after the fwupdate MIR security review, which
should begin today.

[Tyler Hicks (tyhicks)]

Seth has been working on this security review.

[Mario Limonciello (superm1)]

Any more updates on this?

[Seth Arnold (seth-arnold)]

Mario, this review is in progress. One point that worries me greatly is that fwupd appears to allow any hash to authenticate firmware files that are served over appstream and our appstream package appears to allow MD5 and SHA-1, neither of which are acceptable to authenticate firmware updates.

If I can't find any code that enforces a sha256 or better hashing algorithm to authenticate firmware downloads I'm going to have to NAK this package regardless of its other merits.

Thanks

[Mario Limonciello (superm1)]

Seth,

Thanks for raising that early concern. I don't believe there is currently any enforcement of sha256.
The LVFS metadata source that is configured by default (https://secure-lvfs.rhcloud.com/downloads/firmware.xml.gz) is also set to use sha1.

I'll talk to upstream about sorting out both enforcement of sha256 and changing the default metadata to sha256.

If you've got any other biggies, please let me know as they come up.

[Seth Arnold (seth-arnold)]

Thanks Mario, very helpful. I've found something else that worries me:

The Linux Vendor Firmware Service re-packs a cab with a firmware, a detached signature, and some metadata. An example is at [1].

I haven't yet been able to find any chain of trust from a key to the cabfile to download. If the appstream data with firmware update information is published alongside e.g. the distribution's DEP-11 data, then APT will provide this via the /etc/apt/apt.conf.d/50appstream configuration file. (Or similar file.)

If the cabfile metadata comes from [2] then I haven't yet found a way to verify this file or its recentness.

The detached signature in the cab file is not sufficient:
- A malicious entity may find a bug in the cab extraction process and exploit the extraction phase, bypassing the signature entirely.
- A malicious entity may manipulate the metadata file at will.
- A malicious entity may copy-and-paste the signature and firmware files from cab to cab.
- A malicious entity could supply an old, known-problematic, but previously valid cab, unchanged.

I'll continue investigating but wanted to share my concerns before starting a long weekend.

Thanks

1: https://secure-lvfs.rhcloud.com/downloads/90bb8877b5e8a4e4a5a0ce56af37dc4be7cf0ae8-firmware_9550_5510.cab
2: https://secure-lvfs.rhcloud.com/downloads/firmware.xml.gz

[Richard Hughes (richard-hughes)]

Hi Seth,

I'm the upstream of both fwupd and the LVFS. I wanted to point out a few things:

* We use a GPG detached signature of the firmware file itself to avoid being able to just C&P the signature between cab files
* I've reviewed (and fixed critical warning bugs) in libgcab, and have also fuzz tested it (afl) over several days so I'm fairly sure there isn't any exploit here. You want libgcab >= 0.7 for these fixes.
* The metadata also has to be signed by the LVFS GPG key (or another key in your keyring) before it will be parsed by fwupd.
* We require a higher PolicyKit authentication level for installing older versions of firmware than you have currently installed, and in UEFI vendors can set the `version_lowest` key if they also want to forbid this if for instance a on-flash index has been upgraded.
* The checksum is more of a test of a correct download and isn't actually used for the trust calculation. It could be entirely omitted and remain secure, although it does provide a better UX in that we can say "the firmware download was corrupted" rather than "the firmware signature wasn't correct".

Also, the download of files from the LVFS comes over SSL (to avoid MITM), although we don't actually require that before parsing things in the daemon as we just pass down from the client to the server a blob. Even if you were MITMd the files would have to be resigned with a GPG key in your keyring, and if an attacker has that there are easier ways to attack your system :)

I can look at moving from SHA1 to SHA256, but I don't really think this is a reason to block the package for the reasons I gave above. I'm happy to answer any questions you've got, and am also happy to have a call (GMTish timezone) if you'd like me to give you a high level overview of the system, or for a deep-dive into the code.

RIchard

[Richard Hughes (richard-hughes)]

Also, if anyone wants a quick (well, 45 minute) overview of the whole thing my DevConf presentation was recorded: https://www.youtube.com/watch?v=7s2NhxEvwE0

[Seth Arnold (seth-arnold)]

Hi Richard, thanks for the reply.

This is quite unusual but the demands on our time are growing and it'd help me immensely if you could aim me towards the methods that:

- verifies the firmware.xml.gz file

- verifies the contents of firmware.inf and firmware.metainfo.xml files within the cab files

Please do also switch to SHA-256 or SHA-512, both in whatever explicit checks you're using and in the GnuPG signatures. (gpg --list-packets < foo.gpg.asc | grep digest -- 2 is SHA-1, 8 is SHA-256, 10 is SHA-512)

We recently switched APT to requiring SHA-512 signatures and I think firmware updates deserve parity with software updates.

Thanks

[Richard Hughes (richard-hughes)]

Hi Seth,

Verification of the firmware LVFS metadata: https://github.com/hughsie/fwupd/blob/master/src/fu-main.c#L947 which then uses https://github.com/hughsie/fwupd/blob/master/src/fu-keyring.c#L340

Verification of the cab file: https://github.com/hughsie/fwupd/blob/master/src/fu-main.c#L495 after the PolicyKit auth, then uses https://github.com/hughsie/fwupd/blob/master/src/fu-main.c#L323 to work out the trust status. We don't check the firmware.inf as we don't use that in fwupd, only in the LVFS for the version for display.

The digest is "digest algo 8" which is SHA-256 already.

Richard

[Mario Limonciello (superm1)]

Seth, anything else you're looking for to finish your assessments? Just as a friendly reminder we're blocked on turning on firmware support in gnome-software (FFe bug 1544376) from this MIR.

The FFe has been approved for turning on firmware support, but it would be highly desirable to bang on this for as much time as possible before final freeze and be certain it doesn't cause other unexpected gnome-software regressions.

[Seth Arnold (seth-arnold)]

Richard, Mario, thanks for the feedback, it's been helpful.

I'm not sure that everything's hooked up correctly though -- when I
replace both these files with my own GPG key and run fwupdmgr refresh I
get no errors:

/etc/pki/fwupd-metadata/GPG-KEY-Linux-Vendor-Firmware-Service
/etc/pki/fwupd/GPG-KEY-Linux-Vendor-Firmware-Service

/var/cache/app-info/xmls/fwupd.xml
is written and has a current timestamp.

Removing those key files also doesn't appear to change anything.

Removing the /usr/bin/gpg* executables didn't appear to change anything.

I also tried to change the downloaded /tmp/firmware.xml.gz or
/tmp/firmware.xml.gz.asc files to simulate corrupted or modified contents
but had trouble getting the inotify magic to work. Testing this case will
take more time than I've got at the moment but I suspect this error case
is also not properly handled.

Can these error conditions be properly handled before release? Is fwupd
currently "released" enough to justify getting CVEs assigned for these
unhandled error cases? Can they be programmatically tested to ensure they
don't return?

Thanks

[Mario Limonciello (superm1)]

Seth,

Just to confirm, when you replaced those files did you also restart the
fwupd process?

On Mon, Mar 28, 2016, 23:20 Seth Arnold <email address hidden> wrote:

> Richard, Mario, thanks for the feedback, it's been helpful.
>
> I'm not sure that everything's hooked up correctly though -- when I
> replace both these files with my own GPG key and run fwupdmgr refresh I
> get no errors:
>
> /etc/pki/fwupd-metadata/GPG-KEY-Linux-Vendor-Firmware-Service
> /etc/pki/fwupd/GPG-KEY-Linux-Vendor-Firmware-Service
>
> /var/cache/app-info/xmls/fwupd.xml
> is written and has a current timestamp.
>
> Removing those key files also doesn't appear to change anything.
>
> Removing the /usr/bin/gpg* executables didn't appear to change anything.
>
> I also tried to change the downloaded /tmp/firmware.xml.gz or
> /tmp/firmware.xml.gz.asc files to simulate corrupted or modified contents
> but had trouble getting the inotify magic to work. Testing this case will
> take more time than I've got at the moment but I suspect this error case
> is also not properly handled.
>
> Can these error conditions be properly handled before release? Is fwupd
> currently "released" enough to justify getting CVEs assigned for these
> unhandled error cases? Can they be programmatically tested to ensure they
> don't return?
>
> Thanks
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1536871
>
> Title:
> [MIR] fwupd
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1536871/+subscriptions
>

[Richard Hughes (richard-hughes)]

Yes, also further to Mario's comment (you do need to restart the daemon) you also need to clear the persistent gpg2 keyring. I perhaps wasn't clear we also using the persistent keyring store -- using commit https://github.com/hughsie/fwupd/commit/e4141f4f234d258424020069dadf8df39848a119 I see (using the defaults):

11:14:53 importing key 3FC6B804410ED0840D8F2F9748A6D80E4538BAC2 [0] Success
11:14:53 Using signature fingerprint 3FC6B804410ED0840D8F2F9748A6D80E4538BAC2

And then, if I replace the LVFS key in fwupd-metadata with another (e.g. RPM-GPG-KEY-rpmfusion-nonfree-fedora-25) and restart the daemon:

11:21:24 Adding public key /etc/pki/fwupd-metadata/RPM-GPG-KEY-rpmfusion-nonfree-fedora-25
11:21:24 importing key DD7525B6184B0512AA8CB1002E59159B96CA6280 [0] Success
11:21:24 Using signature fingerprint 3FC6B804410ED0840D8F2F9748A6D80E4538BAC2

So it is somewhat confusing that we're still using the "removed" LVFS key for verification success. I suppose it's a bug we're using the default persistent store (of root), which I supposed could be fixed using gpgme_ctx_set_engine_info() and setting the homedir to something like /usr/lib/fwupd -- although this might not be expected if you want to just import a key as a root user and then expect it just to work with fwupd.

So, certainly not a CVE, but somewhat non-obvious. I'd be open to changing the keyring to be fwupd-specific (and adding docs) if this would make things more obvious, although I'd have to check with the Red Hat security team again before doing so.

As for changing /tmp/firmware.xml.gz.asc I'm not exactly sure what you mean; there is of course no inotify watch there. We download the files and then open them, sending the file descriptors to the daemon rather than as a filename or data blob. The download check is being done on the large firmware files themselves, using the data from the metadata, so I'm a little confused what you're trying to do. If you want to test corrupting the metadata or signing files the best way to do this would be to edit fu-util.c and modify the data before it gets squirted to the daemon as a pair of file descriptors.

[Seth Arnold (seth-arnold)]

Thanks again for the rapid feedback. It's nice to know that I jumped to an unreasonable conclusion.

Now that I know to kill the fwupd process I've made more progress testing the failure modes but still find some lacking:

- Removing /etc/pki/fwupd or /etc/pki/fwupd-metadata results in nice error messages.

- Replacing /etc/pki/fwupd/GPG-KEY-Linux-Vendor-Firmware-Service and /etc/pki/fwupd-metadata/GPG-KEY-Linux-Vendor-Firmware-Service with my own GPG key immediately after installing the fwupd package but before running "fwupdmgr refresh" does not result in any kind of error message. /var/cache/app-info/xmls/fwupd.xml is downloaded and unpacked and I can't understand why this succeeds.

To reproduce:
start with a blank xenial vm
apt-get install fwupd
gpg --recv-keys 9D8D2E97 --keyserver keys.gnupg.net
gpg --export --armor 9D8D2E97 > /etc/pki/fwupd/GPG-KEY-Linux-Vendor-Firmware-Service
gpg --export --armor 9D8D2E97 > /etc/pki/fwupd-metadata/GPG-KEY-Linux-Vendor-Firmware-Service
ls -l /var/cache/app-info/xmls/fwupd.xml # confirm ENOENT
fwupdmgr refresh
ls -l /var/cache/app-info/xmls/fwupd.xml # confirm created -- why?

Thanks

[Seth Arnold (seth-arnold)]

Here's the other miscellaneous notes I've made so far:

- fu_keyring_setup() doesn't use gpgme_release() on gpg_set_protocol()
  failure
- fu_main_daemon_update_metadata() checks signature over an entire file
  but uses g_strndup() to copy it in memory; a file may use an embedded
  ASCII NUL to truncate the duplication early. There's probably no
  security issue here but it may be surprising.
- Hardcoded paths:
  - /etc/pki/fwupd-metadata
  - /var/cache/app-info/xmls/fwupd.xml
  - /tmp/firmware.xml.gz
  - /tmp/firmware.xml.gz.asc
- dfu encryption?
  - what problem is it solving? what is the threat model?
  - why xtea?
  - single-pass md5 is a poor KDF

Thanks

[Richard Hughes (richard-hughes)]

Hey,

 - gpgme_release() is called in finalize() unless you can see where we're not deallocating an object on error
 - as_store_from_xml() operates on a UTF-8 string, so any embedded NULs would be invalid anyway
 - /etc/pki/ is a cross-distro spec, no?
 - /var/cache/app-info/xmls is specified in the AppStream specification
 - I've switched away from using /tmp in https://github.com/hughsie/fwupd/commit/b8956d41ee00c03d83f42adcf787463443218d09
 - dfu encryption is where a vendor doesn't want to ship raw firmware that can be RE'd, and where the device has existing XTEA secret tokens
 - XTEA is used as USB devices do not have the CPU or SRAM capability for public/private key algorithms -- see my youtube talk for more information on this
 - Using single-pass MD5 as a KDF allows us to match the output from other proprietary flashing tools. I'd be open to adding a mode to use another KDF if this is an issue, although with XTEA you only get 128 bits of "private key" which I'm not sure is the right word at all as XTEA is just a simple block cipher.

[Richard Hughes (richard-hughes)]

With the gpg issue, log in as root and do:

killall fwupd
gpg2 --list-sigs

if you see the LVFS key, "gpg2 --delete-keys 4538BAC2" -- then remove or change /etc/pki/fwupd-metadata/GPG-KEY-Linux-Vendor-Firmware-Service

then restart fwupd and try a "fwupdmgr refresh" -- this should report:

failed to update metadata: Could not check signature '48A6D80E4538BAC2' as no public key

I can't get your reproducer to work on Fedora, as I'm using gpg2 throughout rather than gpg.

[Mario Limonciello (superm1)]

Seth,

I believe I've identified what's going on (and why Richard couldn't reproduce this on Fedora).

gpgme1.0 shells out to /usr/bin/gpg2 to perform actions. If you turn on it's debug flags verbose enough you can track down the various calls it's sending around.

I was noting the cert actually isn't getting properly enrolled in gnupg2 database in the first place.
In looking at the commands that happened for the import and noticed that gpgme uses "--pinentry=error" [1] but doesn't test to make sure that gpg2 actually supports this. The net result is that it sends this command to gpg2 which returns back on the pipe an error about an unsupported argument.

GPG2 added support for this argument in version 2.1. Ubuntu 16.04 isn't currently shipping 2.1, but Fedora (24) is.

So what's happening is the GPG key never gets enrolled in the GNUPG database.

So there's a few actions I notice out of this:
1) fwupd needs to test if the key import was actually successful
2) gpgme probably needs to test the version of GPG2 it's working with before building these arguments
3) Ubuntu 16.04's gnupg needs to be updated to 2.1 (this already happened in Debian) [2]

[1] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commit;h=61a0d92b679f248505f1bf16386bc41a5bf2ba1d
[2] https://tracker.debian.org/pkg/gnupg2

[Mario Limonciello (superm1)]

To address the various actions:
1) I created a bug to at least track that this is a problem in gpgme [0]
2) I uploaded a new gnupg2 to xenial-proposed. It's in unapproved. For now if you want to give this a try until it's accepted I also have it on a PPA [1]
3) I added a check to fwupd to check for this particular behavior happening during the attempt at import [2]. Once we have any other concerns sorted out he should be able to cut a new release.

[0] https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/1564234
[1] https://launchpad.net/~superm1/+archive/ubuntu/ppa/+packages
[2] https://github.com/hughsie/fwupd/commit/c5e8921dfd88d26eea5ea9c036ae2ff70b3165ca

[Mario Limonciello (superm1)]

Oh and lastly per the comments in https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1536871/comments/2 we should likely be able to turn the test suite back on once compiling with gnupg2.1 in build-depends.

Seth let us know if there is anything else that needs investigation or fixing from your perspective.

[Seth Arnold (seth-arnold)]

Mario, excellent detective work. I was going around in circles earlier
today trying to explain why Richard couldn't reproduce my failures and I
couldn't reproduce his successes.

Richard, thanks for describing the xtea use and md5 KDF. If this were an
important part of the project I'd be far more concerned. xtea is an
awkward cipher, xtea appears to be used in ECB mode, md5 kdf is far from
best practice, and the encryption isn't authenticated. It seems fair for
firmwares that are basically public anyway, and if they've got private
data at least it isn't cleartext on disk before a user can use gpg -c or
something.

Even though I personally had great trouble following the code flow
compared to similar tools such as apt:
- the code is clearly developed with discipline
- the upstream author is clearly responsive and careful.
- Mario's familiarity with the code shows that it's more about me than
  fwupd. :)

I'm afraid that I don't have the time to finish the usual MIR checklist
for this package. The important part is that the code looks sane, upstream
is friendly and helpful, and I'm now satisfied that a chain of trust is
followed from a GPG key to the firmware to be installed. (I haven't yet
seen it myself due to the bugs that Mario discovered but he seems well on
the way to having it fully functional.)

I'd very much like to see the firmware.xml.gz file using sha-256 or
sha-512 hashes before release -- 16.04 LTS is supported until 2021, and
SHA-1 looks funny now, I imagine in five years we'll be finding SHA-1
collisions while eating breakfast just to keep sharp in our old age.

Thank you both for your help.

Security team ACK for promoting fwupd to main on the condition that
gnupg2 2.1 is merged or workarounds for gpgme are developed.

Thanks

[Matthias Klose (doko)]

the merged gnupg2 needs a MIR for npth

[Michael Terry (mterry)]

fwupd:
- Can we get a team bug subscriber for Ubuntu? Some team that promises to look after this, with a bus factor bigger than 1 :)
- Tests are disabled, because of an old upstream bug (https://github.com/hughsie/fwupd/issues/14). That bug is fixed. But tests still don't work for me (pbuilder: libtool not found, locally: crash in test program). That should be investigated and tests re-enabled if possible.

[Michael Terry (mterry)]

I went ahead and looked at npth. It seems fine, but just needs a team bug subscriber as well.

[Mario Limonciello (superm1)]

@mterry:
I'd propose foundations bugs for both.

As for the tests being disabled, you need libtool-bin in xenial (and libtool in earlier releases).
This commit will handle it:
http://anonscm.debian.org/cgit/uefi/fwupd.git/commit/?h=ubuntu&id=4ea0dfe282ba0d26bebb9d47c311c24fea16de33

[Matthias Klose (doko)]

subscribed foundations.

Override component to main
npth 1.2-3 in xenial: universe/libdevel -> main
libnpth-mingw-w64-dev 1.2-3 in xenial amd64: universe/libdevel/extra/100% -> main
libnpth-mingw-w64-dev 1.2-3 in xenial arm64: universe/libdevel/extra/100% -> main
libnpth-mingw-w64-dev 1.2-3 in xenial armhf: universe/libdevel/extra/100% -> main
libnpth-mingw-w64-dev 1.2-3 in xenial i386: universe/libdevel/extra/100% -> main
libnpth-mingw-w64-dev 1.2-3 in xenial powerpc: universe/libdevel/extra/100% -> main
libnpth-mingw-w64-dev 1.2-3 in xenial ppc64el: universe/libdevel/extra/100% -> main
libnpth-mingw-w64-dev 1.2-3 in xenial s390x: universe/libdevel/extra/100% -> main
libnpth0 1.2-3 in xenial amd64: universe/libs/optional/100% -> main
libnpth0 1.2-3 in xenial arm64: universe/libs/optional/100% -> main
libnpth0 1.2-3 in xenial armhf: universe/libs/optional/100% -> main
libnpth0 1.2-3 in xenial i386: universe/libs/optional/100% -> main
libnpth0 1.2-3 in xenial powerpc: universe/libs/optional/100% -> main
libnpth0 1.2-3 in xenial ppc64el: universe/libs/optional/100% -> main
libnpth0 1.2-3 in xenial s390x: universe/libs/optional/100% -> main
libnpth0-dev 1.2-3 in xenial amd64: universe/libdevel/optional/100% -> main
libnpth0-dev 1.2-3 in xenial arm64: universe/libdevel/optional/100% -> main
libnpth0-dev 1.2-3 in xenial armhf: universe/libdevel/optional/100% -> main
libnpth0-dev 1.2-3 in xenial i386: universe/libdevel/optional/100% -> main
libnpth0-dev 1.2-3 in xenial powerpc: universe/libdevel/optional/100% -> main
libnpth0-dev 1.2-3 in xenial ppc64el: universe/libdevel/optional/100% -> main
libnpth0-dev 1.2-3 in xenial s390x: universe/libdevel/optional/100% -> main
22 publications overridden.

[Matthias Klose (doko)]

Override component to main
fwupd 0.6.3-0ubuntu2 in xenial: universe/admin -> main
fwupd 0.6.3-0ubuntu2 in xenial amd64: universe/admin/optional/100% -> main
fwupd 0.6.3-0ubuntu2 in xenial arm64: universe/admin/optional/100% -> main
fwupd 0.6.3-0ubuntu2 in xenial armhf: universe/admin/optional/100% -> main
fwupd 0.6.3-0ubuntu2 in xenial i386: universe/admin/optional/100% -> main
fwupd 0.6.3-0ubuntu2 in xenial powerpc: universe/admin/optional/100% -> main
fwupd 0.6.3-0ubuntu2 in xenial ppc64el: universe/admin/optional/100% -> main
fwupd 0.6.3-0ubuntu2 in xenial s390x: universe/admin/optional/100% -> main
libdfu-dev 0.6.3-0ubuntu2 in xenial amd64: universe/libdevel/optional/100% -> main
libdfu-dev 0.6.3-0ubuntu2 in xenial arm64: universe/libdevel/optional/100% -> main
libdfu-dev 0.6.3-0ubuntu2 in xenial armhf: universe/libdevel/optional/100% -> main
libdfu-dev 0.6.3-0ubuntu2 in xenial i386: universe/libdevel/optional/100% -> main
libdfu-dev 0.6.3-0ubuntu2 in xenial powerpc: universe/libdevel/optional/100% -> main
libdfu-dev 0.6.3-0ubuntu2 in xenial ppc64el: universe/libdevel/optional/100% -> main
libdfu-dev 0.6.3-0ubuntu2 in xenial s390x: universe/libdevel/optional/100% -> main
libdfu1 0.6.3-0ubuntu2 in xenial amd64: universe/admin/optional/100% -> main
libdfu1 0.6.3-0ubuntu2 in xenial arm64: universe/admin/optional/100% -> main
libdfu1 0.6.3-0ubuntu2 in xenial armhf: universe/admin/optional/100% -> main
libdfu1 0.6.3-0ubuntu2 in xenial i386: universe/admin/optional/100% -> main
libdfu1 0.6.3-0ubuntu2 in xenial powerpc: universe/admin/optional/100% -> main
libdfu1 0.6.3-0ubuntu2 in xenial ppc64el: universe/admin/optional/100% -> main
libdfu1 0.6.3-0ubuntu2 in xenial s390x: universe/admin/optional/100% -> main
libfwupd-dev 0.6.3-0ubuntu2 in xenial amd64: universe/libdevel/optional/100% -> main
libfwupd-dev 0.6.3-0ubuntu2 in xenial arm64: universe/libdevel/optional/100% -> main
libfwupd-dev 0.6.3-0ubuntu2 in xenial armhf: universe/libdevel/optional/100% -> main
libfwupd-dev 0.6.3-0ubuntu2 in xenial i386: universe/libdevel/optional/100% -> main
libfwupd-dev 0.6.3-0ubuntu2 in xenial powerpc: universe/libdevel/optional/100% -> main
libfwupd-dev 0.6.3-0ubuntu2 in xenial ppc64el: universe/libdevel/optional/100% -> main
libfwupd-dev 0.6.3-0ubuntu2 in xenial s390x: universe/libdevel/optional/100% -> main
libfwupd1 0.6.3-0ubuntu2 in xenial amd64: universe/admin/optional/100% -> main
libfwupd1 0.6.3-0ubuntu2 in xenial arm64: universe/admin/optional/100% -> main
libfwupd1 0.6.3-0ubuntu2 in xenial armhf: universe/admin/optional/100% -> main
libfwupd1 0.6.3-0ubuntu2 in xenial i386: universe/admin/optional/100% -> main
libfwupd1 0.6.3-0ubuntu2 in xenial powerpc: universe/admin/optional/100% -> main
libfwupd1 0.6.3-0ubuntu2 in xenial ppc64el: universe/admin/optional/100% -> main
libfwupd1 0.6.3-0ubuntu2 in xenial s390x: universe/admin/optional/100% -> main
36 publications overridden.

[Richard Hughes (richard-hughes)]

I can do a new tarball release with all the suggested fixes if that would make things easier.

[Mario Limonciello (superm1)]

Richard,

Can you hold off until tomorrow on the tarball release? I'm working on a
fix for the test suite not working in sbuild I'll push later today that I
would like part of it.

On Thu, Mar 31, 2016, 13:15 Richard Hughes <email address hidden> wrote:

> I can do a new tarball release with all the suggested fixes if that
> would make things easier.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1536871
>
> Title:
> [MIR] fwupd
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1536871/+subscriptions
>

[Tim Chen (timchen119)]

@Mario
For #23, does this affect system without gnupg2 installed ? What will happen if system only has gnupg 1.x ?

[Mario Limonciello (superm1)]

@Tim,
gpgme doesn't do any underlying check on what version, it will happen on a
system with gnupg 1.x as well.

On Fri, Apr 1, 2016 at 12:41 AM Tim Chen <email address hidden> wrote:

> @Mario
> For #23, does this affect system without gnupg2 installed ? What will
> happen if system only has gnupg 1.x ?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1536871
>
> Title:
> [MIR] fwupd
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1536871/+subscriptions
>

[Richard Hughes (richard-hughes)]

> I'd very much like to see the firmware.xml.gz file using sha-256

I added support for more than just SHA1 to fwupd last week. After some more testing, I'll enable it on the metadata file from the LVFS.

[Seth Arnold (seth-arnold)]

Thank you Richard