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
Expired Debian key issue #1575
Comments
Тоже самое
|
Use
|
The problem still seems to exist. Key was replaced by the updated one. No other key laying around. Update: Maybe this info is of help to fix this. LC_ALL=C.UTF-8 add-apt-repository ppa:ondrej/php
rm /etc/apt/sources.list.d/ondrej-ubuntu-php-hirsute.list
apt update && apt upgrade |
I checked mine, and there are no expired keys in my list. |
Same issue here during apt-get update:
Appears fixed after re-downloading the gpg key:
|
This fixed it for me |
how delete old key (if "apt-key list" shows that the expired key is still in /etc/apt/trusted.gpg): import new keyring: update package-list: |
I re-checked again, and there is a second copy of the expired key in a different location. @stefanux's answer is the solution. Even if you have downloaded the new key, it is best to follow @stefanux's steps. If you run as root, you may need to change the permissions on the downloaded file to 644 for it to be readable. |
I have reopened the issue to prevent duplicates... |
Better Style, use apt-key add
|
Actually, not really better style:
|
This fixed it for me too. |
I still cannot fix the error with the provided steps: deleted the key and reimported it with steps:
but still getting:
apt-key list: |
@tauceti82 are you deleting the wrong key? The suggestion of @stefanux was:
(Then get the new one again.) |
I tried both...but the error points at key EXPKEYSIG B188E2B695BD4743 so I deleted this key. |
Your |
it only contains one entry for /etc/apt/trusted.gpg.d/php.gpg which I already posted |
@tauceti82 I did :
and it worked fine. |
thats what I exactly described above what I did and still I get the error :( |
Post the full |
For the next transition, I'll prepare something like |
|
I can confirm the same behavior that @tauceti82 is experiencing on my end. I have followed every set of instructions in this thread, including verifying the permissions of the file /etc/apt/trusted.gpg.d/php.gpg as noted in @waynedixon 's response to @stefanux 's solution, and made sure to try rebooting, and no dice. My key file output is as follows after all the instructions:
The apt-get update results in the same:
|
Same for me. There is no expired key in apt-key list but get the same error. |
Has anyone tried removing the key and then listing the active keys? It could be that the new key is masking the expired one, but then apt sees the expired key first. |
I removed the key via apt-key del and it was deleted meaning it was not listed in apt-key list and then loaded it again... did not work. 03-18 [E] [expires: |
The question isn't whether it listed the correct keys, but whether it also listed something else that should not be there. What I am saying is that you should carefully review all the files and all the keys and remove stuff that should not be there. I am quite sure that there's some forgotten file that still list the old key and it is causing problems. I would try removing the php.gpg file and then listing the keys again if something shows up. It is a local configuration problem and you are the only one who can solve it, we can't administer your installation for you. |
Yes I also think that somewhere is a reference to the old key or some bug in apt. If anyone also affected by the problem could get it to work please Post here. I will continue looking... |
Is there What's output of |
|
And what happens if you remove both |
Could you try running |
I already did. When removing the keys apt Update complains that the key could not be found. |
This is really a wild shot, but is your time and date correct on the affected machine? |
Yup. Of course checked that also! |
There's no "of course" when debugging... ;) But I am a loss... Do you have the same checksum on the file?
|
Yes it has the same checksum. |
🤷 Basically I deleted the old key and added the new one. That worked. Could it be that you use some cache or proxy that still has old signatures? |
I still haven't fixed it, but I've found a place where the problem seems to be reproducible with bare minimum configuring for anyone wanting a direct way to see it. I downloaded the VM for Nextcloud V 16.0 ( https://www.turnkeylinux.org/nextcloud ) went through the password configuring process, and immediately found the same behavior when doing apt update afterwards. Following the steps above for fixing the key did not fix the problem. I will cross-post an issue in their bug tracker. |
Ah, I spoke too soon. I was able to fix it in my case and it did turn out to be a key source that apt-key list wasn't listing. As discussed on this page on the Turnkey forums ( https://www.turnkeylinux.org/forum/support/fri-20190329-1841/when-updating-vm-nextcloud-v-151-error ), they store the key at the location /usr/share/keyrings/php-sury.org.gpg . Following the steps outlined on that post fixed the issue for me, essentially identical to the solutions already described here but with replacing the key file at its other location. |
Yeah, that was going to be my next suggestion - use |
Omg you rock! I also use a turnkey Nextcloud image!!! I will check this ASAP! |
Yeah, wget -O /usr/share/keyrings/php-sury.org.gpg https://packages.sury.org/php/apt.gpg did the trick for me. |
Yes thank you!!! It also worked for me. Damn that was really hard because it isn't listed with apt-key list. Don't know why turnkey uses different locations. Thanks everyone and especially Ondrej!!! |
This one works on stretch. Didn't on Buster (for me). Weird. |
From the linked turnkey forum Post use this to find out where the pgp key is linked: You can use grep to check for both the existence of sury.org in the sources.lists and whether or not it's locked to the specific key file, using grep. I.e.: grep -r sury.org /etc/apt/sources.list* |
Just wanted to let you know that I had the same issue on a Gandi VPS Stretch image and that removing the key and adding it back as suggested here worked for me (adapting the key path to what I had of course). Expired key shown via /etc/apt/trusted.gpg.d/extra_php_version.gpg
--------------------------------------------
pub rsa3072 2019-03-18 [SC] [expired: 2021-03-17]
1505 8500 A023 5D97 F5D1 0063 B188 E2B6 95BD 4743
uid [ expired] DEB.SURY.ORG Automatic Signing Key <deb@sury.org> edit: fixed typos |
on my side I have do this :
And it work fine. Im based on LXC turnkey nextcloud on proxmox environment, |
I think I'm in a catch 22 here. I am trying to create a Docker image and find that I cannot RUN apt-get update because of this key issue. I need to run wget in order to get the new key, but I can't install wget until I run apt-get update. Any suggestions? |
You know you can copy local files to the image? |
Thanks for this. Yes, I know I can copy local files to the image, but I also need to install packages into the image and think I need to be able to run apt-get in order to do that? |
I can run wget on my Mac to get one of the keys described in the comments above, but then I would have to figure out a way to pass that to apt-get, wouldn't I? |
To be clear about this, I cannot, while doing a Docker build, even execute a RUN apt-get update command because of this key error, and I cannot install wget in order to implement any of the proposed fixes above without running apt-get update. |
Finally figured this out and am posting this to help anybody else with similar issues.
Thanks to oerdnj for the hint about copying files into the container. |
After updating the deb.sury.org APT key, per the information on this page (https://www.patreon.com/posts/february-update-47617742) on Debian Stretch, I am receiving the following error:
Hit:5 https://packages.sury.org/php stretch InRelease
Err:5 https://packages.sury.org/php stretch InRelease
The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org
Reading package lists... Done
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.sury.org/php stretch InRelease: The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org
W: Failed to fetch https://packages.sury.org/php/dists/stretch/InRelease The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org
I updated the APT key on another system, running Debian Buster, and that one worked fine. I also tried manually installing the updated apt.gpg file, and it still shows the same error. So, I think there may be an issue with the signature on the Debian Stretch InRelease file.
The text was updated successfully, but these errors were encountered: