[Gpg4win-users-en] gpg4win: cannot enter passphrase when creating key

[Alexander Kriegisch]

Sorry for pushing that question, but again: Do I need to clean up anything from my old installation so as to make it work? And can I log or save something beforehand to help you fix the problem?
-- 
Alexander Kriegisch


> Am 11.11.2013 um 12:47 schrieb Alexander Kriegisch <Alexander at Kriegisch.name>:
> 
> 
>>> On Sunday 10 November 2013 at 14:34:36, Alexander Kriegisch wrote:
>>> I have a fresh installation
>>> - of gpg4win 2.2.1
>>> - on Windows XP Pro SP3 (German).
>> 
>> did you ever have Gpg4win or KDE Plattform 4 applications on this windows 
>> installations before? (This is a safety question, they may interfere with 
>> some Registry or Paths settings.)
> 
> I think so, yes. At least gpg4win found some old keys from 2008 on my machine. Do I need to clean up anything?
> 
>>> First I tried the vanilla version (only GnuPG command line), then later the
>>> full package with Kleopatra.
>> 
>> Should not make a difference. 
>> 
>>> The result is always the same: I cannot create 
>>> a new key pair because somehow the passphrase is not captured correctly. On
>>> the command line the following happens: - Run cmd.exe
>>> - gpg --gen-key
>>> - The whole assistant works nicely until I get to the part where I
>>>   should enter my passphrase. Now nothing happens, I see no dots or
>>>   asterisks when entering the passphrase. I can enter it as many times
>>>   as I want to, the passphrase is not captured. I can only stop the
>>>   process via Ctrl-C. Then the passphrase is written to the console
>>>   as CLEAR TEXT(!) and treated as if I entered it as a command.
>> 
>> Bringing up the pinentry application seems to be the issue.
>> If you call pinentry.exe on the command line do you get something?
>> If you get a prompt, try entering "getpin".
> 
> Pinentry is not on the PATH, but with fully qualified path name it starts alright and the getpin subcommand brings up a little GUI window. Whatever I enter there is echoed to the console later.
> 
>>>   This is a security nightmare.
>> 
>> You need to be more precise than this. Given that you would want to create
>> a new certificate on a secure system anyway, there does not seem to be much
>> of an additional attack vector if the certificate is not created at all.
> 
> Well, it would be in the shell history and the PW would be readable on the console unexpectedly. So if someone walks by or has admin acces to my machine and can read the shell history, ... I mean an entered password should never be written to the console or a file in clear text, but this is what happens.
> 
>>>   I cannot understand how something like this 
>>>   can ever pass a test unnoticed.
>> 
>> Probably because it usually works, if we knew all the circumstances
>> where Gpg4win application would run, then it could have been tested.
> 
> I had no idea the situation was so exotic, sorry. Anyway, maybe if I can help you reproduce the situation you can write an automated test for it. :-)
> 
>>> By the way, the same problem was reported long ago already, but nothing
>>> happened. See this thread:
>>> http://lists.wald.intevation.org/pipermail/gpg4win-users-en/2009-August/000
>>> 349.html
>> 
>> Different version of Gpg4win, probably a different problem.
>> To be sure we had to have a way to reproduce the issue.
> 
> Yes, let's do that. I can send you whatever system or logging info you request before overwriting or fixing anything. How about that?
> _______________________________________________
> Gpg4win-users-en mailing list
> Gpg4win-users-en at wald.intevation.org
> https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-users-en