[arch-dev-public] pacman root key issue with gnupg-2.1
Hi all, With GnuPG 2.1, they have tightened up on keys without a passphrase. We don't have a passphrase on the root key in the pacman keyring... This means that things like adding keys (pacman-key --recv-key <keyid>) now fail. The pacman-4.1.2-7 has a patch to pacman-key that adds an option when creating the initial key that allows passphraseless keys to work. The only solution I can see to this problem is having everyone regenerate their pacman root key. Instructions: make sure you have pacman >= 4.1.2-7 installed rm -r /etc/pacman.d/gnupg pacman-key --init pacman-key --populate archlinux readd any other keys you need Of course, the original key generation will take a very, very, very long time. So we will also have to encourage users to install haveged and run it. Or can a gnupg expert point out another way to deal with this change? Allan
[2014-12-01 12:14:34 +1000] Allan McRae:
With GnuPG 2.1, they have tightened up on keys without a passphrase. We don't have a passphrase on the root key in the pacman keyring... This means that things like adding keys (pacman-key --recv-key <keyid>) now fail.
Strange, --recv-key works fine here, running gnupg-2.1.0-6 on a pre-gnupg-2.1 pacman-keyring.
The pacman-4.1.2-7 has a patch to pacman-key that adds an option when creating the initial key that allows passphraseless keys to work.
That option was required for key generation, indeed. Cheers. -- Gaetan
On 01/12/14 13:22, Gaetan Bisson wrote:
[2014-12-01 12:14:34 +1000] Allan McRae:
With GnuPG 2.1, they have tightened up on keys without a passphrase. We don't have a passphrase on the root key in the pacman keyring... This means that things like adding keys (pacman-key --recv-key <keyid>) now fail.
Strange, --recv-key works fine here, running gnupg-2.1.0-6 on a pre-gnupg-2.1 pacman-keyring.
How about --lsign? The bug report (that I just added you to) mentions --lsign. My --recv-key issues may be independent. Allan
[2014-12-01 13:33:18 +1000] Allan McRae:
On 01/12/14 13:22, Gaetan Bisson wrote:
[2014-12-01 12:14:34 +1000] Allan McRae:
With GnuPG 2.1, they have tightened up on keys without a passphrase. We don't have a passphrase on the root key in the pacman keyring... This means that things like adding keys (pacman-key --recv-key <keyid>) now fail.
Strange, --recv-key works fine here, running gnupg-2.1.0-6 on a pre-gnupg-2.1 pacman-keyring.
How about --lsign?
Right. It seems porting the pacman keyring from pre-2.1 to 2.1 mishandles the no-password case: signing anything with the resulting master key fails. We should be able to fix that by manually fiddling with the keyring, but I haven't found how yet. As you point out, recreating a fresh keyring with gnupg-2.1 is the easiest solution, though it will inconvenience users that have already imported and signed keys locally. I suggest we post a news item advising all users to do that. Cheers. -- Gaetan
[2014-12-01 16:31:28 -1000] Gaetan Bisson:
Right. It seems porting the pacman keyring from pre-2.1 to 2.1 mishandles the no-password case: signing anything with the resulting master key fails. We should be able to fix that by manually fiddling with the keyring, but I haven't found how yet.
As you point out, recreating a fresh keyring with gnupg-2.1 is the easiest solution, though it will inconvenience users that have already imported and signed keys locally. I suggest we post a news item advising all users to do that.
How about the following news announcement: The upgrade to gnupg-2.1 tampered with the pacman keyring in a way that rendered the local master key unable to sign other keys. This is only an issue if you ever intend to customize your pacman keyring. We nevertheless recommend all users regenerate a fresh keyring using: sudo pacman -Syu sudo rm -fr /etc/pacman.d/gnupg sudo pacman-key --init sudo pacman-key --populate archlinux [End of the announcement.] Additionally, to avoid future issues with pacman-key communication passphrases to gnupg, I suggest updating our pacman package with: - "pinentry-mode loopback" in /etc/pacman.d/gnupg/gpg.conf - "allow-loopback-pinentry" in /etc/pacman.d/gnupg/gpg-agent.conf See: https://bbs.archlinux.org/viewtopic.php?pid=1480570#p1480570 Cheers. -- Gaetan
On 05/12/14 12:50, Gaetan Bisson wrote:
[2014-12-01 16:31:28 -1000] Gaetan Bisson:
Right. It seems porting the pacman keyring from pre-2.1 to 2.1 mishandles the no-password case: signing anything with the resulting master key fails. We should be able to fix that by manually fiddling with the keyring, but I haven't found how yet.
As you point out, recreating a fresh keyring with gnupg-2.1 is the easiest solution, though it will inconvenience users that have already imported and signed keys locally. I suggest we post a news item advising all users to do that.
How about the following news announcement:
The upgrade to gnupg-2.1 tampered with the pacman keyring in a way that rendered the local master key unable to sign other keys. This is only an issue if you ever intend to customize your pacman keyring. We nevertheless recommend all users regenerate a fresh keyring using:
sudo pacman -Syu sudo rm -fr /etc/pacman.d/gnupg sudo pacman-key --init sudo pacman-key --populate archlinux
[End of the announcement.]
Additionally, to avoid future issues with pacman-key communication passphrases to gnupg, I suggest updating our pacman package with: - "pinentry-mode loopback" in /etc/pacman.d/gnupg/gpg.conf - "allow-loopback-pinentry" in /etc/pacman.d/gnupg/gpg-agent.conf
See: https://bbs.archlinux.org/viewtopic.php?pid=1480570#p1480570
As far as I can tell, those options are just supposed to allow gpg to work without a pinentry. But we should never require a password to be entered, so it does not matter whether the pinentry is available or not. So I am missing the reason to add this. Also, not that /etc/pacman.d/gnupg/gpg.conf is not owned by the pacman package, but is created by gpg when generating the root key. Allan
[2014-12-07 21:27:39 +1000] Allan McRae:
On 05/12/14 12:50, Gaetan Bisson wrote:
[2014-12-01 16:31:28 -1000] Gaetan Bisson:
Right. It seems porting the pacman keyring from pre-2.1 to 2.1 mishandles the no-password case: signing anything with the resulting master key fails. We should be able to fix that by manually fiddling with the keyring, but I haven't found how yet.
As you point out, recreating a fresh keyring with gnupg-2.1 is the easiest solution, though it will inconvenience users that have already imported and signed keys locally. I suggest we post a news item advising all users to do that.
How about the following news announcement:
The upgrade to gnupg-2.1 tampered with the pacman keyring in a way that rendered the local master key unable to sign other keys. This is only an issue if you ever intend to customize your pacman keyring. We nevertheless recommend all users regenerate a fresh keyring using:
sudo pacman -Syu sudo rm -fr /etc/pacman.d/gnupg sudo pacman-key --init sudo pacman-key --populate archlinux
[End of the announcement.]
Additionally, to avoid future issues with pacman-key communication passphrases to gnupg, I suggest updating our pacman package with: - "pinentry-mode loopback" in /etc/pacman.d/gnupg/gpg.conf - "allow-loopback-pinentry" in /etc/pacman.d/gnupg/gpg-agent.conf
See: https://bbs.archlinux.org/viewtopic.php?pid=1480570#p1480570
As far as I can tell, those options are just supposed to allow gpg to work without a pinentry. But we should never require a password to be entered, so it does not matter whether the pinentry is available or not. So I am missing the reason to add this.
Sure. That's just a precaution in case future versions of gnupg require pinentry even for empty passwords. But as you say that's unneeded now. I'll post the announcement later today if no one has further comments. -- Gaetan
On 08/12/14 06:44, Gaetan Bisson wrote:
[2014-12-07 21:27:39 +1000] Allan McRae:
On 05/12/14 12:50, Gaetan Bisson wrote:
[2014-12-01 16:31:28 -1000] Gaetan Bisson:
Right. It seems porting the pacman keyring from pre-2.1 to 2.1 mishandles the no-password case: signing anything with the resulting master key fails. We should be able to fix that by manually fiddling with the keyring, but I haven't found how yet.
As you point out, recreating a fresh keyring with gnupg-2.1 is the easiest solution, though it will inconvenience users that have already imported and signed keys locally. I suggest we post a news item advising all users to do that.
How about the following news announcement:
The upgrade to gnupg-2.1 tampered with the pacman keyring in a way that rendered the local master key unable to sign other keys. This is only an issue if you ever intend to customize your pacman keyring. We nevertheless recommend all users regenerate a fresh keyring using:
sudo pacman -Syu sudo rm -fr /etc/pacman.d/gnupg sudo pacman-key --init sudo pacman-key --populate archlinux
[End of the announcement.]
Additionally, to avoid future issues with pacman-key communication passphrases to gnupg, I suggest updating our pacman package with: - "pinentry-mode loopback" in /etc/pacman.d/gnupg/gpg.conf - "allow-loopback-pinentry" in /etc/pacman.d/gnupg/gpg-agent.conf
See: https://bbs.archlinux.org/viewtopic.php?pid=1480570#p1480570
As far as I can tell, those options are just supposed to allow gpg to work without a pinentry. But we should never require a password to be entered, so it does not matter whether the pinentry is available or not. So I am missing the reason to add this.
Sure. That's just a precaution in case future versions of gnupg require pinentry even for empty passwords. But as you say that's unneeded now.
I'll post the announcement later today if no one has further comments.
My only comment is to add a comment about using haveged. I have not successfully generated a key without it running lately...
[2014-12-08 08:18:29 +1000] Allan McRae:
My only comment is to add a comment about using haveged. I have not successfully generated a key without it running lately...
Good idea. Here is an updated proposal: The upgrade to gnupg-2.1 tampered with the pacman keyring in a way that rendered the local master key unable to sign other keys. This is only an issue if you ever intend to customize your pacman keyring. We nevertheless recommend all users fix this by generating a fresh keyring. In addition, we recommend installing haveged, a daemon that generates system entropy; this speeds up critical operations in cryptographic programs such as gnupg (including the generation of new keyrings). To do all the above, run as root: pacman -Syu haveged systemctl start haveged systemctl enable haveged rm -fr /etc/pacman.d/gnupg pacman-key --init pacman-key --populate archlinux Cheers. -- Gaetan
[2014-11-30 17:22:08 -1000] Gaetan Bisson:
[2014-12-01 12:14:34 +1000] Allan McRae:
With GnuPG 2.1, they have tightened up on keys without a passphrase. We don't have a passphrase on the root key in the pacman keyring... This means that things like adding keys (pacman-key --recv-key <keyid>) now fail.
Strange, --recv-key works fine here, running gnupg-2.1.0-6 on a pre-gnupg-2.1 pacman-keyring.
Didn't you mean --lsign-key now fails (instead of --recv-key)? As per https://bugs.archlinux.org/task/42966 ? I can confirm that's an issue... -- Gaetan
participants (2)
-
Allan McRae
-
Gaetan Bisson