fwupdmgr refresh fails due to invalid signature
#391
Comments
|
Yep, I can also reproduce on Ubuntu with master. |
|
I'll try regenerating the metadata first as a quick fix. |
|
Right, that worked, I'll have a look at the old files and try to work out what went wrong. I have a suspicion it's my fault and the staging LVFS accidentally uploaded metadata with the test key. |
|
Nope, it appears the right key was used: (I have the public key imported system wide on this machine) |
|
Thanks for the fix, that was impressively fast! I’ll leave it up to you to decide when to close the issue. |
|
In the event log: ...which is what triggered the metadata rebuild (correctly). |
|
And nothing untoward in the uwsgi logs: 4 headers in 526 bytes (2 switches on core 0) |
|
$ sha1sum firmware.xml.gz* ..where the .1 is after the rebuild. |
|
Ohh, that's expected, other firmwares got pushed to stable in the meantime (new |
|
I can't work this one out -- I'll close and we can reopen if this every happens again. |
|
Please reopen, it's happening again. Since yesterday I get "Failed to update metadata for lvfs: '48A6D80E4538BAC2' is not a valid signature" on two machines running Fedora 27. |
|
It's gone again. If nobody changed anything, it seems to be something intermittent... |
|
reopening due to: |
|
@brumle80 can you upload /root/.cache/fwupdmgr/firmware.xml.gz and /root/.cache/fwupdmgr/firmware.xml.gz to this ticket please. |
|
I managed to find someone else having the same problem. This is what I see: Now, the other person provided me with files that were downloaded from the CDN just a few minutes ago: Hmm, so the detached signature is different. A file generated on the 28th Feb?! |
|
Some followup; it seems the CDN is shipping old files for some zones. I've purged all zones manually, and it should "fix" it, although we need some kind of root cause analysis and a plan to detect this again automatically in the future. |
|
the purge fixed it as it's working fine now, thanks for the quick resolve. |
|
Still/again Getting the same |
|
Same here |
|
I've purged manually; which seems to fix things for me too, but we really need a way to purge triggered from the LVFS. |
|
Again now: > fwupdmgr refresh
Fetching metadata https://cdn.fwupd.org/downloads/firmware.xml.gz
Downloading… [***************************************]
Fetching signature https://cdn.fwupd.org/downloads/firmware.xml.gz.asc
Failed to update metadata for lvfs: '48A6D80E4538BAC2' is not a valid signature
> shasum ~/.cache/fwupdmgr/lvfs-metadata.xml.gz*
d4a73a0924d9bed830ddff85f748dbe6bb3a3473 fwupdmgr/lvfs-metadata.xml.gz
be5d50b6fd62ed59edd0e10396a4f7499b56dfa8 fwupdmgr/lvfs-metadata.xml.gz.ascIt should refresh CDN automatically |
|
Different error this time; a permissions error on the server. I think I've fixed up everything now, but I'll do a root cause after breakfast. |
|
See https://github.com/hughsie/lvfs-website/issues/138 for the root cause. |
|
I've run into the same problem today: |
|
Works now, right? I broke the metadata sync when converting everything to Python 3. |
|
@hughsie ran it a few more times and still the same thing, I'm guessing it's the cdn cache. |
Retried a minute after posting, and it seems to have updated successfully, (Thank you, if someone did something server-side to fix it. :D ) |
|
We're working on a fix: #1827 |
|
Also having this at the moment =/ |
|
Same here |
|
Seeing this again in Fedora 32. This is the concrete output: Do you want me to open a new issue or do we keep the discussion in this issue? |
Switch to downloading the signature first, which we can then load to get the suffixed build-specific URL of the actual metadata file. You need to have libjcat 0.1.1 installed and fwupd built against the new version for this to work. Fixes #391
Switch to downloading the signature first, which we can then load to get the suffixed build-specific URL of the actual metadata file. You need to have libjcat 0.1.1 installed and fwupd built against the new version for this to work. Fixes #391
Switch to downloading the signature first, which we can then load to get the suffixed build-specific URL of the actual metadata file. You need to have libjcat 0.1.1 installed and fwupd built against the new version for this to work. Fixes #391
|
If you want to test all this out, you currently need to install both libjcat and fwupd from git master, although new tarballs won't be much further away. |
|
I am running into this on ubuntu 20.04 |
|
The fix is in the fwupd 1.4.x branch, which is not present in Ubuntu 20.04 |
|
Is the 1.4 branch in the Flatpak version? It seems not to be. |
I'm just building 1.4.4 in flathub now. |
|
Ubuntu 20.04. Same issue. |
Ubuntu Server 20.04. Same issue. |
|
Jumping on the bandwagon When trying get-updates: Additionally: not sure if this is the right place for this; and I'm kind of a noob with linux in general still so maybe I'm just dumb, but I may have some kind of malware on my machine at the moment, which I have no idea if it has anything to do with this, but I suspect it poisons the DNS cache somehow (have had problems with all kinds of websites in a browser, some sketchy certificate issues)... for what it's worth. Highly doubt fwupd is a likely cause of that though, if anything merely a symptom - I'm not completely sure if I have anything malicious at all at this point (been trying to diagnose for months) but if I do, it's very deep in the UEFI or something, and started in Windows soo. But in case anyone else sees this who has been wondering the same thing on their machines. |
|
Getting the same error Fetching metadata https://cdn.fwupd.org/downloads/firmware.xml.gz Failed to update metadata for lvfs: '48A6D80E4538BAC2' is not a valid signature What was the fix for this? Thank you On Centos 8 |
|
Same error on Elitebook 845 G7. |
|
Same error on recent ubuntu 20.04.1 server install: |
|
It is happening again currently: |
|
As of now works again, that was fast! Thanks! |
|
I am currently getting the same error reported here, as of the time of this comment: |
|
I got this regularly across servers for weeks. |
|
The fix to this was introduced in 1.4.x with switching to jcat based metadata. Unfortunately that means that 1.3.x and earlier will continue to encounter it from time to time due to cdn mirroring delays. If you continue to encounter it on 1.3.x and earlier please try again in a few minutes. |
and others
Running
fwupdmgr refreshfails on my system with the following error message:This is a new issue, on wednesday (07.02.2018), refreshing worked just fine. I can reproduce this on another machine as well (also Archlinux).
$ fwupdmgr --version client version: 1.0.4 daemon version: 1.0.4 compile-time dependency versions appstream-glib: 0.7.4 gusb: 0.2.11Archlinux 64bit
from source,pacman,apt-get, etc):pacmanYes
Yes
No
The text was updated successfully, but these errors were encountered: