2 and 3 are aliases for RSA. Some rarely used PGP versions used them to
indicate signing or encrypting RSA keys. GPG supports them. The specs say

   There are algorithm types for RSA Sign-Only, and RSA Encrypt-Only
   keys.  These types are deprecated.  The "key flags" subpacket in a
   signature is a much better way to express the same idea, and
   generalizes it to all algorithms.  An implementation SHOULD NOT
   create such a key, but MAY interpret it.

What version of libgcrypt are you using? ("gpg --version" shows that)

Thanks, The fix will be online soon.

Ok using the same compiler I've used a year ago I also get the same result I got
a year ago (phew I thought i screwed up the test).

But with the patch this should just work once we change the used mingw-version.
I could not find a bugreport or some other information where and when this is fixed.

I've tested this again with the mingw version that is part of ubuntu and it works.

I've commited a patch to gpg4win to enable this and will check if this also
works with the debian wheezy mingw-crt version.

pinentry-qt should have only been the default if you install a gpg4win version
that includes qt.

Could you execute pinetry-qt directly and enter "getpin" in the command line
window that opens?
What happens then?

I've overlooked your bugreport and opened a very similar one
T1685

Werner has commited a proper fix for this in gpgme master.

Thanks for the report anyway. If I had seen this earlier it would have saved me
some time debugging this and coming to the same conclusion ;-)

Tested the patch with 1.4.4 on Windows against
vm-keyserver.spline.inf.fu-berlin.de which did not work previously.

Patch is also included in gpg4win now.

Thanks!

There is no guarantee that you will see a keyid at all. The keyid and the
fingerprint are actually different objects and it is only for v4 key format that
you can compute the keyid from the fingerprint. We have to implement this
knowledge into gpgme.

Meanwhile I did this and master does now work as expected. It even returns the
fingerprint if available. You may this with the also enhanced gpgme-tool.

While working on it I also fixed the --search-key thing for gnupg master.

D209: 447_keylist-shortening.patch

Please do not use the bug tracker for questions. See the FAQs and then ask at
gnupg-users@gnupg.org for help.

Thanks.

With dirmngr 1.1.1 and libgcrypt-1.6.0 (gpg4win-2.2.2-beta19) I have what I
think is a similar error on Windows:

C:\Users\aheinecke>"c:\Program Files\GNU\GnuPG\dirmngr.exe"
dirmngr[3060]: Fatal: can't register GNU Pth with Libgcrypt: Not supported

Doesn't crash though. I've not tested the pth_init patch. If you think this is
useful please tell me and I will do so. I assume it will also fix this problem.

Ping?

Thanks.

D208: 446_libgcrypt-1.6.1.patch

D207: 445_libgpg-error-1.13-t-lock.patch

and for 1.4

Fixed for 2.0.

There are no known attacks on SHA-1. MD5 is disabled anyway in recent versions.
But please continue at gnupg-users - if you like.

Thanks for the explanations.

Further analysis showed that the second call to AllowSetForeground window was
blocked by the ForegroundWindowLockTimeout. If you set this timeout to zero
everything worked as expected.

There is a discussion on this under:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/09fa16ba-c6ef-410d-bec2-a99a9b9a98d9/issue-with-foregroundlocktimeout-setforegroundwindow

Which suggests a solution of setting the foregroundlocktimeout to zero before
attempting to set the foreground window. I've found this solution not applicable
for our case as we run into the lock on "AllowSetForegroundWindow" and not when
actually setting the foreground Window.

Another workaround is to call AttachThreadInput on the current foreground thread
call SetForegroundWindow and then detach again. There might be problems with
this approach so it is just used as fallback. But it should resolve this problem
for now.

Thank you for the prompt response.

I am familiar with the standard. The only violation of a MUST I'm aware of is that
recipient and personal digest preferences are ignored for hashes with known attacks;
perhaps some of these changes cause GnuPG to behave badly in other cases?

This is already known and has been discussed at gnupg-devel -users. This is
indeed a regression which needs to be fixed. The import filter does only check
the primary key and as soon as you downlaod via a subkey id the key is rejected.

It is on my short list.

This has been discussed at gnupg-users at lengths. You need to read the OpenPGP
standard to understand some of the defaults. For the others you may start yet
another disucssion thread at gnupg-users.

re 4) The iteration count used depends on the machine.

What I described is done for all pinentries.

FWIW, I checked my POSIX 2001 standard and it does not define -p. The
GNU manual for uname however has to say:

`-m'
`--machine'

     Print the machine hardware name (sometimes called the hardware
     class or hardware type).

`-p'
`--processor'

Print the processor type (sometimes called the instruction set
architecture or ISA).  Print `unknown' if the kernel does not make
this information easily available, as is the case with Linux
kernels.

Ok, thanks I'll check what happens if

5. The agent thinks that the passphrase entered is too weak
6. The agent starts another pinentry
7. The agent sends "getinfo pid" to the pinentry (this i can see)
8. ?

Fix has been pushed for 1.6 and master. Thanks,

IIRC, there is a need to allocate a new console or something like this. It is
too long since I studied this and concluded it is too much work and English
users won't appreciate it anyway ;-)

1. The agent starts pinentry.
2. The agent sends "getinfo pid" to the pinentry"
3. The agents sends an "INQUIRE PINENTRY_LAUNCHED <pid>" to the caller.

4a. If the caller is gpg, gpg calls AllowSetForegroundWindow for the received
pid; gpg has been started via gpgme and gpgme has called ASFW for gpg.
4b. If the caller is gpgsm, it proxies the PINENTRY_LAUNCHED to gpgme which then
calls ASFG for the pid.

The different methods are required because gpg is a one-off process while gpgsm
may be used several times.

Thanks for that good description. Fixes pushed to master and 1.6. I can't test
it, though.

Yes Kleopatra uses gpgme for key generation. Still I don't see how gpgme figures
into this sorry. Should gpgme start gpg-agent and ensure that it has the
setforeground window access right?

1. The gpg-agent asks for a passphrase with pinentry -> set foreground window is

allowed.

2. If that passphrase is weak it launches a new pinentry with a confirm dialog

-> set foreground window is not allowed.

And the agent does not have the right to call allowsetforegroundwindow. In the
first case I think this might be because another component gets the PID of the
pinentry and calls allowsetforeground window (have to do further debugging to
check this)

In the second case afaik only gpg-agent is involved and no one sets
allowsetforeground window on the pid of the second pinentry.

I don't think switching the console to UTF-8 is the real problem here.

At least just using chcp is not enough. Fonts do also factor into this and this
is where it gets weird:

If you run chcp 65001 and have a raster font selected the output is garbled.
If you then switch to a truetype font the output is correctly interpreted.

Now if you run the command while already having a truetype font selected the
output is garbled again but differently.. o.O

And looking at common/utf8conf.c there is already code that tries to handle
different Console Output Codepages but appearently there is a bug somewhere in
there :) (Or that code is not used / respected)