GNOME Bugzilla – Bug 548136
Passwords containing "%" followed by any two characters are improperly handled
Last modified: 2012-02-02 14:05:19 UTC
Please describe the problem: If the password contains "%" followed by any *two* characters, i.e. "%sf" or "%vd", you will not be able to use seahorse to decrypt a private PGP key that was originally encrypted with gpg. This means that you cannot change the key's password using seahorse nor can you use seahorse-agent to fetch your private key for signing text, etc. If the private key is created or otherwise encrypted with seahorse using one of these passwords, gpg will not be able to decrypt the private key. Steps to reproduce: 1. Create a new public/private key pair using gpg as follows: GPG_AGENT_INFO="" gpg --gen-key 2. Accept defaults for key type and key size, enter some user name, etc. 3. For the password enter "%ss". 4. Start seahorse and attempt to change the password for the new key. Actual results: No matter what password you enter, you will always receive an invalid password response. Expected results: Entering "%ss" as the password should allow you to go about changing the password on the new key. Does this happen every time? Yes. Other information: It's possible to turn around the presented scenario and create a public/private keypair using seahorse and a password as specified. gpg will be unable to decrypt the key using that password even though seahorse will be able to do so. It's also possible to use seahorse to change the password on an existing key (as long as the password does not have the bad form) to a password which gpg will not be able to use to decrypt the key. Basically, it looks like the password dialogs for seahorse are malfunctioning.
*** Bug 548496 has been marked as a duplicate of this bug. ***
Hmmm, this smacks of us using the string directly in a printf style format function. I'll look around.
Probably a g_strdup_printf function then.
Odd, I can't duplicate this. Would you happen to know if it's seahorse-agent or seahorse itself doing the password prompting? Does this occur if you don't use the agent?
I believe it to be seahorse-agent prompting for the password. That's why the password set using gpg and pinentry (step 1 of the reproduction instructions) will generate a key which also cannot be decrypted when I try to use Thunderbird to sign a message, which is using gpg and the default gpg agent settings under Gnome. As far as I can tell, the same password entry dialog is displayed for Thunderbird when signing a message as is displayed when using seahorse to try decrypting the key prior to changing the password, so if seahorse-agent displays one, it's probably displaying the other. If there are some steps you would like me to follow in order to verify the state of things, please send them along. Would killing seahorse-agent be sufficient to cause seahorse to fall back to another mechanism for password retrieval?
Yes, I believe that killing seahorse-agent would cause gpg and gpgme to use the internal seahorse callbacks to prompt for a password. The two share the same dialog, so the result may look similar.
After killing the seahorse-agent program, the fallback which is used is to call the pinentry program to retrieve the password. This method works fine since that method is used by step 1 of the reproduction steps to initially set the password. I ran another test this time using seahorse itself to create the key rather than gpg. Instead of step 1 as specified for reproducing this defect, use seahorse to create the key. Follow the remainder of the steps as specified. This will yield a key which seahorse and gpg can decrypt when using the pinentry program (instead of seahorse-agent) to retrieve the password. If seahorse-agent is used to retrieve the password, the key cannot be decrypted by either program. All of this means that seahorse can do the right thing to set a password for a key it creates, but that seahorse-agent is corrupting the passwords it retrieves somewhere before the passwords are actually used.
Thanks for the research. I'll look into it further as soon as I get a chance.
Passwords with %s and %f get sent properly back to gpg. I cannot duplicate this with 2.23.92. When you get a chance can you see if this is still the case?
I have only found this problem on seahorse 2.22.3 under Gentoo running on AMD64. I don't have any newer version available to this system unless I grab the source and compile it directly outside the package manager. That won't be a problem unless compiling and running that new version requires replacing other packages on my system. Let me know what to expect, and I'll give this a try if possible. One other person on the Gentoo forums has the same problem (http://forums.gentoo.org/viewtopic-t-702652-highlight-.html), and removing the %s from his password also corrected the issue. Perhaps this is a Gentoo-specific defect.
I'm closing as we have no duplicates so far. Also I can't reproduce with r2968. Jeremy, please reopen this issue, if you still have problems!
Hello Tobias, unfortunately we have a duplicate now. The above mentioned workaround "solved" the problem for me. Is there any information I can provide that might help you solve the issue? Dirk
Hey Dirk. Are you saying that you encounter this issue? If so, then we need to reopen this bug. And with which version are you experiencing this bug?
http://bugs.gentoo.org/show_bug.cgi?id=234986#c6 app-crypt/gnupg-2.0.17 app-crypt/gpgme-1.3.0 app-crypt/seahorse-2.32.0
Oups. Jesus, that's embarrassing. Reopening. Stef, could you have another look into this? It's not about "Passwords with %s and %f get sent properly back to gpg." but about a percent and *two* characters. The downstream report has a good analysis.
I can't duplicate this with seahorse 2.91.91 (when run in both the following ways): $ seahorse $ GPG_AGENT_INFO="" seahorse I'll try on 2.32.0
Tobias, did you manage to duplicate this problem? Can't duplicate on seahorse 2.32.0 either. I generated a key generated in gpg (without using a GPG agent) with the password '%ss'. And I can change the password through seahorse. Pacho, could you include a screenshot of the prompt that's failing? That may help us identify where this bug actually is.
Strange - I cannot reproduce the problem myself after a) disabling gpg-agent and b) switching forth and back from/to a "%.."-Password. The switch to a non-"%.."-Password needed to be done from the command line, the switch back worked from within seahorse. History is as follows: after installing gnome seahorse wouldn't accept my gpg keys for mail signing in gnome evolution. Googling around made me try "eval 'gpg-agent --daemon'" within my session. The password prompt changed at that time from the seahorse one to the pinentry-gtk one. After recompiling most of my software that suddenly stopped working. pinentry-gtk didn't come up anymore, seahorse complained about some smartcard-related problem (regardless gnupg being compiled with or without smartcard support). I'll watch this and report back if I manage to reproduce that again.
Alright. Thanks.
any news for this report?
I guess this issue is OBSOLETE by now. Please reopen if this is not the case.