See https://minerva.crocs.fi.muni.cz/ for a description of the timing attack.

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.

See also apt-get show libpam-poldi

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" ?

Do not use this legacy debug stuff. Use --debug CATEGORY. For example

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?