Repository Signing Key Expiry
This email is specific to Debian / Raspbian repos. 1) This is the first problem. Over the weekend the repo signing key downloaded during initial set-up expired. (This sort of set-up https://software.opensuse.org//download.html?project=home%3Am-grant-prg&package=get-iplayer). This led to all attempts to use the repsitory to error out, (eg apt-get update, apt-get install....). The errors appeared as below:- sudo apt-get update Hit:1 http://archive.raspberrypi.org/debian buster InRelease Get:2 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB] Get:3 http://download.opensuse.org/repositories/home:/m-grant-prg/Raspbian_10 InRelease [1,531 B] Hit:4 https://apt.syncthing.net syncthing InRelease Err:3 http://download.opensuse.org/repositories/home:/m-grant-prg/Raspbian_10 InRelease The following signatures were invalid: EXPKEYSIG 3FD1CDB63E00F70B home:m-grant-prg OBS Project <home:m-grant-prg@build.opensuse.org> This happened to me and to an unknown size user community. 2) This is the second problem. I established that the key had been refreshed on opensuse.org and now had a mid-2023 expiry date so I thought re-downloading it using the curl command in the instructions should do the trick. The command worked OK but the curl command had changed from using a target keyring of "home:m-grant-prg.gpg" to "home_m-grant-prg.gpg". So the curl command did not overwrite the old keyring. The end result was that the old expired key was still found and repository actions still errored out. The solution I have suggested to the user community is to remove the offending keyring. It seems obvious that this exact same problem will occur in 2023 (at least problem 1). I am sure that OBS has a transparent solution for this and I just have never seen it. I would be most grateful if someone could point me in the direction of the relevant documentation. Thanks, Mark
Hi Mark, I can't speak to 1) but let me explain the cause of your second problem. Mark Grant <m.grant.prg@gmail.com> writes:
2) This is the second problem. I established that the key had been refreshed on opensuse.org and now had a mid-2023 expiry date so I thought re-downloading it using the curl command in the instructions should do the trick. The command worked OK but the curl command had changed from using a target keyring of "home:m-grant-prg.gpg" to "home_m-grant-prg.gpg". So the curl command did not overwrite the old keyring. The end result was that the old expired key was still found and repository actions still errored out. The solution I have suggested to the user community is to remove the offending keyring.
This change was done in [1] due to the following GitHub Issue[2]. Apparently the old keyring file names would break GPG in some way. When I accepted this PR I did not think of your use-case (updating the keyring) and I'm sorry for causing the trouble. The question is how to go from here. Rolling back the change would not only cause the issue mentioned above again, it would also cause the same problem you just experienced in the other direction. Maybe it's better to document this somewhere and suggest what you did: removing any old keyring file for the repo. What do you think about that? Best, Alex 1: https://github.com/openSUSE/software-o-o/issues/842 2: https://github.com/openSUSE/software-o-o/pull/843
Alex, Thanks for the quick response. On Tue, 16 Mar 2021 10:57:02 +0100, Alexander Graul wrote:
Hi Mark,
I can't speak to 1) but let me explain the cause of your second problem.
Mark Grant <m.grant.prg@gmail.com> writes:
2) This is the second problem. I established that the key had been refreshed on opensuse.org and now had a mid-2023 expiry date so I thought re-downloading it using the curl command in the instructions should do the trick. The command worked OK but the curl command had changed from using a target keyring of "home:m-grant-prg.gpg" to "home_m-grant-prg.gpg". So the curl command did not overwrite the old keyring. The end result was that the old expired key was still found and repository actions still errored out. The solution I have suggested to the user community is to remove the offending keyring.
This change was done in [1] due to the following GitHub Issue[2]. Apparently the old keyring file names would break GPG in some way.
I have not seen the gpg problem described, but obviously you had to fix it.
When I accepted this PR I did not think of your use-case (updating the keyring) and I'm sorry for causing the trouble.
The question is how to go from here. Rolling back the change would not only cause the issue mentioned above again, it would also cause the same problem you just experienced in the other direction. Maybe it's better to document this somewhere and suggest what you did: removing any old keyring file for the repo. What do you think about that?
I agree that your original patch should stand, I agree with your assessment above. Documenting it seems the right thing to do but I wouldn't know where. I ended up suggesting to my user community to run sudo rm -v /etc/apt/trusted.gpg.d/home:m-grant-prg.gpg This still worries me as asking users to run such a command does have risks, if they cut and paste fine but... The alternative to use apt-key del for that key in that keyring might be safer but may fall foul of your gpg error and also may still leave the keyring even though empty. So I think it should be documented and suggest the rm option. Thanks for your help. Regards, Mark
Best, Alex
1: https://github.com/openSUSE/software-o-o/issues/842 2: https://github.com/openSUSE/software-o-o/pull/843
participants (2)
-
Alexander Graul
-
Mark Grant