-
Notifications
You must be signed in to change notification settings - Fork 415
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failed to load signature: Need more input #6032
Comments
|
I was working out why I had to disable secure boot, and it turns out Lenovo disables the Microsoft 3rd Party UEFI CA by default. Enabling that allowed the If that was really the cause, perhaps this issue could be about modifying the error message to indicate the signature failed due to UEFI CA issues? |
|
I don't think disabling secure boot should affect anything like this -- can you try turning off secure boot again and doing |
|
I have the same problem, my secure boot is disabled and neither |
|
Same here (Lenovo TP490s, Fedora38) sudo fwupdmgr refresh --force |
|
Same here, Fedora 38. Appeared today.
Tried to reinstall - did not help. |
|
Basically, this happens on enabling remote too:
|
|
I've the same issue on Arch |
|
Lenovo P50, Fedora 38: fwupdmgr refresh --force |
|
This error is when we try to parse the signature in libjcat from the thing the CDN delivered. I'm on holiday on a little island with not much internet, so this will need someone else to debug this. I just refreshed just fine on my f38 machine I updated a few days ago, do it's not everyone affected. Did any recent update start causing this perhaps? Is it a transient issue? |
|
For instance, the -vv output is going to be super useful, as is downgrading fwupd, libjcat, glib2, libcurl etc |
|
Hi @hughsie !
|
|
If you remove cdn. from the lvfs.conf does it work? If you get the .jcat file what does it look like? |
|
And does the jcat cli load the file? |
|
@hughsie I removed cdn. from config and it worked! |
|
@hughsie Cannot attach that .jcat - github does not support it It is in archive |
|
Can you compare what the CDN sent and what the main server sent please? |
|
@hughsie |
|
Maybe the problem with archive itself |
|
These are them after extraction, formatted for readability |
|
@hughsie Seems like the issue is resolved. I can run for cdn |
|
I also don't get an error anymore: |
|
I also don't get the error anymore when executing it by hand, but the systemd service still fails, but without any error message, just the following; |
|
So maybe the CDN went crazy? For the systemd service, can you add -v and see any more debug lines? |
Sure; |
|
Same problem here. Downloading I compared {"JcatVersionMajor": 0, "JcatVersionMinor": 1, "Items": [{"Id": "firmware-06672-stable.xml.xz", "AliasIds": ["firmware.xml.xz"], "Blobs": [{"Kind": 4, "Flags": 1, "Timestamp": 1691483156, "Data": "eacfbe188f1e337c983ed9c262e9b15a24182aac"}, {"Kind": 1, "Flags": 1, "Timestamp": 1691483156, "Data": "29ec1995117637f7c336064170dc911c22312b83554b13e1c694de0581320e14"}, {"Kind": 2, "Flags": 1, "Timestamp": 1691483162, "Data": "-----BEGIN PGP SIGNATURE-----\n\niQEzBAABCAAdFiEEP8a4BEEO0IQNjy+XSKbYDkU4usIFAmTR/BoACgkQSKbYDkU4\nusIqFgf/cm4MpOvBq3nOHQIfjJ8/SEQzf1onvVWAD231m4oVE3xgWMBWzc4uQRvt\nCJajR1j6OoHPezb3aZiXOUeTAv7adQZO7Hg4OK6kGIZl1hgL2kYnwbDldccVwUPo\n1I0pq3naoGWxgN+Z0i5IkdC2ul4KR9fnar/vzzh4vRimV9WAJJtM9vZdUM0/+miT\nVubLNbEWrIIJcCyIbdVpMWkyGkSRllxjmPGZpwd/73vn6AKI+oumlXsOQzA1Uf8W\nJCKeOCjC7/B53bX8dNCf9ThgWa3wfEVvVJSCxkq5gkhSPTP85QUA09xPcOZXao2A\n9nA7gf8jTFNEqhTde+VLrQq463TkcQ==\n=BnoP\n-----END PGP SIGNATURE-----\n"}, {"Kind": 3, "Flags": 1, "Timestamp": 1691483162, "Data": "-----BEGIN PKCS7-----\nMIIGUgYJKoZIhvcNAQcCoIIGQzCCBj8CAQExDTALBglghkgBZQMEAgEwCwYJKoZI\nhvcNAQcBoIIEOjCCBDYwggKeoAMCAQICDFprhisibP88kP07YjANBgkqhkiG9w0B\nAQsFADA6MRAwDgYDVQQDEwdMVkZTIENBMSYwJAYDVQQKEx1MaW51eCBWZW5kb3Ig\nRmlybXdhcmUgUHJvamVjdDAeFw0xODAxMTYwMDAwMDBaFw0yODAxMTYwMDAwMDBa\nMBkxFzAVBgNVBAMTDlJpY2hhcmQgSHVnaGVzMIIBIjANBgkqhkiG9w0BAQEFAAOC\nAQ8AMIIBCgKCAQEArR5nseG3+Zs+o41P9LTspiVSGVcp6ifNHhbKKxBvZZXsy0gX\n+P/VRlsHLiKQrFulQ8GbPODytFv0o+y/0MkiJxv/fY3yEZ2bwNpsSeXFQSGHI6yz\njaVNeNCu8lnnDtD7kiC8UNUNHcnA4+2h/Yv4k+KPqYF+Qb6nWAEIID1ObMnjeJUb\ndbPPvy12aasV3gZcZ+goYNFc0ua6OU/CNEuzAVVCTAJ/EpCdGpll1+6BGU5ImIUG\nTlMTWq2xmCfCPugakHrmWA66yHWwE6LmC/U7qQDWFemsSNnmzyBB9HPkqsW1DjHr\n+ZmNUPj3+q2UGnNwP/Cne462XbsZB569w7pnzQIDAQABo4HcMIHZMAwGA1UdEwEB\n/wQCMAAwNwYDVR0RBDAwLoYXaHR0cHM6Ly9md3VwZC5vcmcvbHZmcy+BE3JpY2hh\ncmRAaHVnaHNpZS5jb20wEwYDVR0lBAwwCgYIKwYBBQUHAwMwDwYDVR0PAQH/BAUD\nAweAADAdBgNVHQ4EFgQUMcrnDWk3DM1GJCqJK7EbAycgB+UwHwYDVR0jBBgwFoAU\nsY3q5COnfgmOte4x4GrdnjQ3ZawwKgYDVR0fBCMwITAfoB2gG4YZaHR0cDovL3d3\ndy5md3VwZC5vcmcvcGtpLzANBgkqhkiG9w0BAQsFAAOCAYEAjoXBOtVb1qPLuE7I\nShdSkk66JMNmzZnODbun3BaViUF3PPhuRiJ2y7Bu7loCnxHwzKpq5Hn4Untg1WhQ\nSsPEv6H2oc2E4HU1Gds2HEE1UL0VzulPEwaOFX0OZ37LmJ2VFvfgwfNmjAWZ+ngN\nsjuff3PWeHNsOwbS3To0CBlHqz9LlcA7Gxpxbz4DbUEvgTTKZFbasgUS6/QmbpPy\n880ThgD93yCg6Q002AooPMw8zW6gGUP7/2D4aKBjgM/IJDrJEicTdKDFtUacsN+d\nCfIEcn6F1rzPgwo0B/yLYVMpbL8WzxSS7cX5dBlkreH6Nf7g+A2NTryU/6FxoFxo\nnWJmLssNQCgx42Ywc8CgJRt1yWXxoZXOPap8zPvFAAmrfUlqfZlr2Wzcf2nxpSZJ\noQRzGDXDRiYNt28xjX408cJ+Wy+0oWwgnXCkfzMDnJQB8MX6+5Ah4v4mS/XjmOIi\nQ+hKCT99Yf0Eq3TWzFhyYducqLU904FbrrUSoi07DfxXa/8RMYIB3jCCAdoCAQEw\nSjA6MRAwDgYDVQQDEwdMVkZTIENBMSYwJAYDVQQKEx1MaW51eCBWZW5kb3IgRmly\nbXdhcmUgUHJvamVjdAIMWmuGKyJs/zyQ/TtiMAsGCWCGSAFlAwQCAaBpMBgGCSqG\nSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIzMDgwODA4MjYw\nMlowLwYJKoZIhvcNAQkEMSIEICnsGZURdjf3wzYGQXDckRwiMSuDVUsT4caU3gWB\nMg4UMA0GCSqGSIb3DQEBAQUABIIBABng4wodCLYNGreeKti2m4cG2JahoNDDrrv2\nLRMFPpkHvOmlPdO2GW00+xsD+EYbv1Xu3X6OD/AOpQwkupugA4kaLh4bE3iSvR3R\ncLi6bpMcA3icQpQXcfNtgQMUMkbzx+EkWmKGqRKlVSOn/rGd/031lSriev0P7DUQ\n4UEwoXai8iC/KDQsd2i4/GEBeUVtOzba1SH2q5uyBduSE0e5N6IxNISL7EywAb0K\n2UCS6E92xd0WyDQgV9QMzxfaqcqYKdnWtHJUgpHsbX1jXzmpmxER8WZrnHWmsyn2\nLU6BBtTOEzbP4gqUkCxqXh5Z0mfWyEDKYGdzMNi0fk25dFvvwVk=\n-----END PKCS7-----\n"}]}]}However, decompressing the one I get from CDN fails: I also compared the gzipped binaries right after the download (i.e. without decompressing them) and it appears that the CDN truncates the original file. The file downloaded from CDN is four bytes shorter and it is a prefix of the original file from the main server (i.e. if I remove the last four bytes from the file downloaded from the main server, it matches exactly to the file downloaded from CDN). |
|
What's the file size in bytes of the truncated version out of interest? |
|
I was facing this issue on Debian 12.1 Bookworm aswell, when I opened up "Discover" software centre. An error message popped up: "Failed to load signature: need more input". Now, what I tried based on the previous comments are and every single attemts are failure: Updating my BIOS/UEFI to the latest version: negative My UEFI menu doesn't have anything such as enable/disable capsule UEFI update or such, BUT all I know that my machine was perfectly working as intended, everything was normal, until my distro received a big update, and after that, I'm receiving these error messages are bombarding me, and it seems everyone else. I'm on Debian stable for a reason, for not to receive such bugs, but it seems, not even that is a warranty... I can't seem to find any fix on this, and based on the comments, for now we are groping in the darkness. |
I.e. they differ by four bytes. Specifically the last four bytes are missing on the CDN:
Funnily enough the four bytes missing are exactly the four bytes which, in the gzip file format as part of its 8B trailer, indicate the original length of the uncompressed text ( |
|
$ diff firmware.xml.xz.jcat cdn.firmware.xml.xz.jcat -rw-r--r--. 1 sam sam 2223 авг 8 06:25 cdn.firmware.xml.xz.jcat |
|
@cwrau that's a different issue, no? what does "fwupdmgr refresh --force" say for you on the interactive CLI? |
Ah, ok, so I should open a new issue? Running interactively works, as it has before, just the systemd refresh service fails |
|
Yup, new issue please. |
|
I'm new at linux so forgive me if I sound like a noob. I'm on Kubuntu 23.04 for a few days now. Today (after updating OpenSSH via Discovery) I am getting this error whenever I open Discovery. This is the output using -vv I'm in The Netherlands if that is important. |
|
I have an issue with similar symptoms since today, on an updated Fedora 39 (Kinoite but should not matter). I've noticed that if I move the URL back to |
|
And it works again today (I no longer have the issue). |
|
Working with our CDN provider, we've verified that there is no difference between the files hosted in each region and the origin file. Does anyone still see the symptom at this time? |
Details```log 2023-10-05T10:05:23.992632+0200 steve systemd[1]: Starting Refresh fwupd metadata and update motd... 2023-10-05T10:05:24.016430+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): GLib-DEBUG: 10:05:24.016: setenv()/putenv() are not thread-safe and should not be used after threads are created 2023-10-05T10:05:24.019615+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): GLib-GIO-DEBUG: 10:05:24.019: _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’ 2023-10-05T10:05:24.019615+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): dconf-DEBUG: 10:05:24.019: watch_fast: "/system/proxy/" (establishing: 0, active: 0) 2023-10-05T10:05:24.019824+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): dconf-DEBUG: 10:05:24.019: watch_fast: "/system/proxy/http/" (establishing: 0, active: 0) 2023-10-05T10:05:24.019856+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): dconf-DEBUG: 10:05:24.019: watch_fast: "/system/proxy/https/" (establishing: 0, active: 0) 2023-10-05T10:05:24.019887+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): dconf-DEBUG: 10:05:24.019: watch_fast: "/system/proxy/ftp/" (establishing: 0, active: 0) 2023-10-05T10:05:24.019913+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): dconf-DEBUG: 10:05:24.019: watch_fast: "/system/proxy/socks/" (establishing: 0, active: 0) 2023-10-05T10:05:24.019941+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): dconf-DEBUG: 10:05:24.019: unwatch_fast: "/system/proxy/" (active: 0, establishing: 1) 2023-10-05T10:05:24.019959+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): dconf-DEBUG: 10:05:24.019: unwatch_fast: "/system/proxy/http/" (active: 0, establishing: 1) 2023-10-05T10:05:24.019959+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): dconf-DEBUG: 10:05:24.019: unwatch_fast: "/system/proxy/https/" (active: 0, establishing: 1) 2023-10-05T10:05:24.019959+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): dconf-DEBUG: 10:05:24.019: unwatch_fast: "/system/proxy/ftp/" (active: 0, establishing: 1) 2023-10-05T10:05:24.019959+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): dconf-DEBUG: 10:05:24.019: unwatch_fast: "/system/proxy/socks/" (active: 0, establishing: 1) 2023-10-05T10:05:24.020061+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): dconf-DEBUG: 10:05:24.020: watch_established: "/system/proxy/" (establishing: 0) 2023-10-05T10:05:24.020097+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): dconf-DEBUG: 10:05:24.020: watch_established: "/system/proxy/http/" (establishing: 0) 2023-10-05T10:05:24.020125+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): dconf-DEBUG: 10:05:24.020: watch_established: "/system/proxy/https/" (establishing: 0) 2023-10-05T10:05:24.020155+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): dconf-DEBUG: 10:05:24.020: watch_established: "/system/proxy/ftp/" (establishing: 0) 2023-10-05T10:05:24.020197+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): dconf-DEBUG: 10:05:24.020: watch_established: "/system/proxy/socks/" (establishing: 0) 2023-10-05T10:05:24.020843+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): GLib-GIO-DEBUG: 10:05:24.020: _g_io_module_get_default: Found default implementation local (GLocalVfs) for ‘gio-vfs’ 2023-10-05T10:05:24.020875+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): pxbackend-DEBUG: 10:05:24.020: px_config_sysconfig_set_config_file: Could not read file /etc/sysconfig/proxy 2023-10-05T10:05:24.020914+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): pxbackend-DEBUG: 10:05:24.020: Active config plugins: 2023-10-05T10:05:24.020914+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): pxbackend-DEBUG: 10:05:24.020: - config-env 2023-10-05T10:05:24.020914+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): pxbackend-DEBUG: 10:05:24.020: - config-kde 2023-10-05T10:05:24.020914+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): pxbackend-DEBUG: 10:05:24.020: - config-gnome 2023-10-05T10:05:24.020914+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): pxbackend-DEBUG: 10:05:24.020: - config-sysconfig 2023-10-05T10:05:24.021717+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): GLib-GIO-DEBUG: 10:05:24.021: Failed to initialize portal (GNetworkMonitorPortal) for gio-network-monitor: Not using portals 2023-10-05T10:05:24.022054+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): GLib-GIO-DEBUG: 10:05:24.022: Using cross-namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3) 2023-10-05T10:05:24.023299+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): GLib-GIO-DEBUG: 10:05:24.023: _g_io_module_get_default: Found default implementation networkmanager (GNetworkMonitorNM) for ‘gio-network-monitor’ 2023-10-05T10:05:24.023299+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): pxbackend-DEBUG: 10:05:24.023: px_manager_on_network_changed: Network connection changed, clearing pac data 2023-10-05T10:05:24.023346+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): pxbackend-DEBUG: 10:05:24.023: px_manager_constructed: Up and running 2023-10-05T10:05:24.023346+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): GLib-GIO-DEBUG: 10:05:24.023: _g_io_module_get_default: Found default implementation libproxy (GLibproxyResolver) for ‘gio-proxy-resolver’ 2023-10-05T10:05:24.026569+0200 steve fwupdmgr[2566873]: (/usr/bin/fwupdmgr:2566873): Fwupd-DEBUG: 10:05:24.026: Emitting ::status-changed() [idle] 2023-10-05T10:05:24.034378+0200 steve systemd[1]: fwupd-refresh.service: Deactivated successfully. 2023-10-05T10:05:24.043320+0200 steve systemd[1]: Finished Refresh fwupd metadata and update motd. ```Nevermind, exit code Then this looks like it's working now 👍 |
|
Didn't meet this issue for more then a month. (Germany) |
|
I'm affected too. From Germany. |
|
Happened again today. :( |
|
Same here. As before, And it's not just a single endpoint which returns the truncated file. I can repeatedly download it, hitting a different endpoint (at least as per |
|
Hi, also experience this issue under Manjaro. I switched in |
|
Happened to me on Fedora 38 too. Removing cdn solved the problem as suggested in a number of replies. It would be great if it could re-try without CDN by default. |
That would destroy the main server any time the CDN went wrong. Outgoing bandwidth in AWS is expensive. :/ |
|
I guess the hacky workaround is to just to append 6 bytes of "XXXXXX" to the JCAT file -- libjcat seems to parse it just fine with the extra data appended and then if the CDN did truncate the file then ¯_(ツ)_/¯ |
|
Can anyone affected go back to the CDN and try again please? There's 6 bytes of junk on the end of https://cdn.fwupd.org/downloads/firmware.xml.xz.jcat now |
I doubt that's sustainable. Last time the file was missing four bytes, this time it's six. Next time it might be eight, and you're back to square one. And that's not to mention just /how awful/ of a hack that is to begin with. ;) That aside - works for me now. Main website & CDN deliver the same file for now - including the |
That was supposed to be an easter egg! :) |
Switching back to CDN has worked for me. |
|
Thanks for helping us to track this down. If you are affected still, can you post the output of these two commands: |
|
If this hack, cough, workaround, fixed the issue for you please say. If it's still broken, please shout louder! |
|
@hughsie, I had to use @leture's fix: #6032 (comment) to get things working this morning. |
|
My Discover on Fedora 39 KDE just started throwing this error today, same from the command line. Checksums are different between CDN and direct download: curl output to cdn.fwupd.org: https://gist.github.com/DomiStyle/5814ef8ffe082ee56098138437622274 |
|
Same problem for me again. According to curl my data package come from (I would have used spoiler / details tags for collapsible output but this seems to destroy the codeblock formating on Github.) I confirm the observation of @DomiStyle. Exactly the NULL NULL |
|
In the code: In retrospect 8B stands for 8 BYTE and |
|
Can you both try now please. |
|
@hughsie Looks good now! Checksums match and fwupdmgr doesn't complain anymore. |
|
Thanks for the fast respones @hughsie. I can confirm fwupd it works again. Also at the moment the output of CDN and main are Identical. So Cloudflare does not cut off the end. |



Describe the bug
fwupdmgr refreshdownloads, but then reportsFailed to load signature: Need more input.Steps to Reproduce
fwupdmgr refreshfwupd version information
Debian testing, installed from apt. Fresh install, first boot. Had to disable secure boot to install.
**fwupd device information**
Please provide the output of the fwupd devices recognized in your system.
The text was updated successfully, but these errors were encountered: