Dear Martin,

Not sure what I did wrong this time, but it's broken again - GPG will again prompt for the PIN on my computer instead of on the Gemalto Ezio Shield reader :(

I'm using GnuPG 2.2.4-1ubuntu1.2 with your patch applied:

I have the same effect if I send a signed text-only or HTML email using Outlook 365 and our Exchange 365 and if I view the mail on Outlook on Android. The mail shows no contents only the file. If I view the mail using Outlook 365 on my PC or Windows 10 Mail it looks fine.
If I address it also to my Microsoft account and my Gmail account (using all adresses in the TO: field of the same mail) the email looks normal in the Gmail Android app and (!) in Outlook for Android.
So the same mail - both in the same Outlook for Android app - looks correct in my Microsoft account inbox but only shows the file in my Exchange inbox - in the same Outlook App. Weird… Nokia 7 plus, Android 9, newest patch level (September 2019) and no updates in Google Play Store.
BTW: In Exchange 365 I configured the message flow, default remote domain (there is no other) to never to use Rich Text, always and only HTML.

Thanks for the feedback! Right now it hangs only for a few seconds, then works as usual. No idea how this come, but I'll close the issue and contact the ML if it appears again.

Please try with the latest GnuPG version (2.2.17) - it is unlikely that we can give support for an old version with Ubuntu's own set of patches. It is also advisable to post to the gnupg-users ML because over there you have hundreds of Ubuntu users.

I agree with @werner that when presented with a User ID with self-sig with preference, the preferences subpackets from the self-sig should take precedence.

I modified _gcry_ecc_fill_in_curve so that g_y has new value in eid4730.

I believe the issue is as follows. When given the option ttyname=... pinentry will open() the given tty and that fails since it is owned by the regular user and not root; strace reports:

openat(AT_FDCWD, "/dev/pts/1", O_RDONLY) = -1 EACCES (Permission denied)

However, when not given this option, pinentry will simply write() to stdout which causes no permission problem; through sudo and the terminal this goes to /dev/pts/1.

I found a way to replicate that error with just pinentry by doing (as root):

# tty
/dev/pts/1
# pinentry
OK Pleased to meet you
OPTION ttyname=/dev/pts/1
OK
GETPIN
S ERROR gtk2.open_tty_for_read 83918849
ERR 83918849 Permission denied <Pinentry>

When I remove OPTION ttyname=... there is no error.

My other terminals (xterm) are /dev/pts/1, /dev/pts/2, etc. and I can reproduce the bug in them too.

Also in another terminal?

I did not (neither in my root shell nor in my user shell) but setting and exporting this environment variable does not make any difference: gpg --gen-key still fails as above. (Note that tty indeed returns /dev/pts/0 .)

Do you have

GPG_TTY=$(tty)
export GPG_TTY

That's my badness. I think that I haven't seen this problem, because I mainly use tokens (where keygrip difference doesn't matter, after --card-status).

Hi
FYI here is what I did to resolve:
running gpg.exe and gpg-agent.exe as Administrator and XP mode....
gp-agent:
set service Priority to REALTIME
Disabled Windows UAC virtualization.

Thanks for your help investigating this.

if you run

What is weird is that pinentry supposedly detects the absence of an X session and falls back on curses. For instance, I have:

You should always run gpg with --verbose if you run into an unknown error. It shows more information; in your case info about the requested pinentry. The strace does not show this. You probably have no permission to launch the X version opf the pinentry because the xauth does not work. As a quick test use ssh -X root@localhost instead.

Please provide a full description of what you did. What command line did you use, have you su-ed or logged in regular.? What is the output of "gpgcof --list-dirs" ?

OK, I identify the problem.

For pinpadtest.py, you need to offer an option --add (adding dummy byte), when you are using Cherry ST-2xxx.

For pinpadtest.py, you need to offer an option --add (adding dummy byte), when you are using Cherry ST-2xxx.

It is not supported, by CCID protocol itself. So, it is not supported by scdaemon, and by any of card readers (which I know of), either.

It is not supported, by CCID protocol itself. So, it is not supported by scdaemon, and by any of card readers (which I know of), either.

It is not just about being annoying but for security reasons. It would be too easy for other applications *think webbrowser or Acrobat) to take a screenshot and pop up a modified version of that screenshot with data entries to act as a MitM.

$ gpg-connect-agent --dirmngr 'getinfo version' /bye
D 2.2.17
OK

Can you check which dirmngr version you are running

gpg-connect-agent --dirmngr 'getinfo version' /bye

thanks for the dns explanation - IMHO, there should be added something about that in the wiki
When it does not work for you on http1 either, then I guess, it's really just some outdatedness of my gpg/dirmngr and this ticket can be closed.

It does not work either. Your problem is the use of a wildcard DNS for archlinux32.org:

The test above was with gpg master but I got the same result with current 2.2:

ok, I disabled it again. btw: why do we need openpgpkey.archlinux32.org in the cert? Is this standard or did I misconfigure something?

Thanks. Here is a dirmngr log:

I set archlinux32.org back to http2 - so you can see for yourself, how gpg fails to retrieve the key for buildmaster@archlinux32.org

I believe, it means, that it may fall back to http1.1 - the documentation is not clear to me on this.
A simple test however shows, that at least curl has no problems to use http1.1 or http1.0 with the http2 enabled nginx.

Does your ngix configuration mean that there is no fallback to standard http?

And it is merged into master.
Along with the support of multiple readers/token, the parts which assumes Windows 32-bit are fixed, too.

For argparse.c, it can be only stopped with nonnull attribute for the API, I suppose.

I take this so that libgpg-error can be released soon.

The message has not been encrypted to you. Ask the sender to encrypt to you.

How to fix "failed: no secret key

This is generally the better tracker to report Gpg4win / Kleopatra issues. The git systems are linked in a way that I can both automatically add a commit here and in the KDE tracker.
I just noticed the KDE report a bit quicker because there is less traffic, but I would have seen it here within the day.

There is no need to use the new CTB format for a packet with tag 3. OpenPGP implementations need to support all packet header encodings. We do not plan to make this configurable.

I created a branch for this task: https://dev.gnupg.org/source/gnupg/repository/gniibe%252FT4620/

Agreed.

yep, the implementation thinks that the default signing key is expired due to metadata contained in the public keyring. The secret key is available to the implementation. So the error mesage No secret key can cause confusion and/or panic if the user thinks they've actually lost their secret key.

You mean the default key is expired?

fwiw, i can reproduce this on debian unstable with gpg version 2.2.17, without a redirected agent -- so the agent redirection isn't relevant here.

Today a new signed message from BSI Buerger CERT was received. The PGP signature could be verified by first opening of the document. As I opened the file some hours later again, it failed, as I opened it a third time (shortly after the second time), the signature was verified. Outlook was not closed between the second and third opening. Signature verification appears unstable.

@stm -- thank you for this!

There is no reason for apologies :-). As far as I know this all is open source, freeware and you don't get paid for this, right? So, I simply also try to add my contribution by most precise error reports to help to find the error and am grateful if it will be solved one day in the future :-).

I'll try to look at it this week. Apologies for the delay with this.

Last week GpgOL again destroyed an email with a BSI newsletter - it was shown as empty after I opened it a second time - and the same is true in such cases then in Windows 10 Mail as well as using Outlook Web Access:

But this problem remains for several versions for some time. I tried to find out the source of this "new option" in the communication, but I could not find anything about "GPG Agent" in the source code of openssh.

Sorry for the late answer, but I have been busy. Actually this happened against several ssh versions, for some time now.

The signature of the latest communication from German Buerger CERT Warnings could be read and the signature could be verified. I tried also with Hasso-Plattner-Institute (Identiy leak checker), the same result. I do not understand, why all signature verification failed last week, and they can be verified this week. However, at the moment it seems to work fine.

Oh, this report is about libgpg-error.

Thanks for the sample certs. I noticed the posts but had not the time to look into them.

I have the same problem since today with Outlook 2016. In the past months / weeks GpgOL version 2.4.2 worked fine. I received some mails today signed by the German Buerger CERT warnings. The signature as "asc" file was attached, but could not be verified. Today I received also a PGP signed e-mail from Hasso-Plattner-Institute (Identity leak checker), also this signature could not be checked. Both worked fine in the past and the public keys stored in Kleopatra are valid.

Would be great to see this fix rolled out! Absence of support for these keys disoriented me for months after switching to pinentry-tty. I use my longest passwords for GnuPG, so being able to fix typos (instead of abandoning password entry altogether) would be greatly appreciated.

@werner How can I install libgpgme-develp package on windows 7?

Sorry, we don't use or support PIP. Please ask whoever packaged that for PIP.

... https://lists.gnupg.org/pipermail/gcrypt-devel/2019-July/004760.html

If helpful I can demonstrate or let you debug in a TeamViewer (I have a license) or VNC remote session in a fresh VM.
For sure this is not urgent for me. So, take your time!