pinentry-mac must not store an empty passphrase (Error: no passphrase given)
Reported by Support | February 5th, 2020 @ 12:24 PM | in 2.2.20 (closed)
Assigned to GPG Mail Support Plan #1170. In case the user leaves the password field empty, when prompted by pinentry-mac for the password, it must not store the passphrase. Otherwise, upon the next decryption the user is no longer asked for the password, but instead GnuPG simply fails with "No passphrase given" and never prompts the user for the password.
Steps to reproduce
- Create new test key with a passphrase: test@test.org as email address
-
Run the following command in Terminal:
killall gpg-agent -
Encrypt a message for that key:
echo "Test" | gpg -aer test@test.org > test.asc -
Try to decrypt the message:
gpg --decrypt test.asc -
When prompted for the passphrase by pinentry-mac, make sure that "Save in keychain" is checked, leave the password field empty and simply press enter.
Expected
Either pinentry-mac should not accept an empty passphrase (best case), or pinentry-mac should be shown again, as the passphrase is invalid (technically)
What happens instead
GnuPG fails with gpg: Entschlüsselung mit
Public-Key-Verfahren fehlgeschlagen: No passphrase given. gpg:
Entschlüsselung fehlgeschlagen: No secret key. (The
secret key is available, but gnupg couldn't access it, due to the
missing passphrase)
In addition, every attempt to decrypt a message encrypted to that key now fails without ever prompting the user again, since the passphrase is fetched from macOS Keychain Access.
Solution
Make sure pinentry-mac doesn't accept an empty passphrase. In
case no passphrase is set on a key pinentry-mac is not launched at
all, so that shouldn't be a problem.
In addition, if an empty passphrase is returned, behave as if no
keychain entry existed in the first place to fix the problem for
users where pinentry-mac already misbehaved.
Comments and changes to this ticket
-
Mento February 11th, 2020 @ 09:47 AM
- State changed from “new” to “fixed”
- Assigned user set to “Mento”
- Importance changed from “” to “Low”
-
steve February 22nd, 2020 @ 12:04 AM
- State changed from “fixed” to “verified”
Verified
2705n Behaves as described above. After the empty passphrase is stored in macOS Keychain, new pinentry requests are not showing for future attempts to decrypt something with that key.
2714n Empty passphrase is not stored in macOS Keychain with "store in keychain" option enabled. Future attempts to decrypt something for that key still result in pinentry asking for the passphrase.
-
-
Support March 3rd, 2020 @ 10:02 AM
- Tag changed from “” to “#tag id: 460388, name:”
Assigned to Tender discussion #15756.
-
Support March 6th, 2020 @ 05:35 PM
- Tag changed from “#tag id: 460388, name:” to “tag id 460388, name”
Assigned to Tender discussion #15768.
-
-
-
-
-
-
-
steve June 29th, 2020 @ 11:59 AM
- Tag cleared.
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
Luke Le
steve
Support