Err... Sorry for your troubles. It's my fault.

Tested and works fine with current gnupg and gpgcard.

D180: 398_0001-enable-key-to-card-upload-for-cert-only-keys.patch

my scdaemon.conf:
reader-port Cherry GmbH SmartTerminal ST-2xxx [Vendor Interface]
(21121310161160) 00 00
verbose
debug 2048
enable-pinpad-varlen
log-file /tmp/scd-pinpad.log

I did not activate debugging; but also have moved to 2.2.1 of the gpg4win tool
collection and can no longer replicate the problem.

I've upgraded to the gpg4win Oct 7 release (2.2.1, same version of GPGOL), and it
seems to be launching things in a more reliable order; can not reproduce in
2.2.1.

Can you please provide a debug log? Put the lines

verbose
debug 2048
log-file /foo/bar/scd.log

into ~/.gnupg/scdaemon.log - kill sdaemon and try again. Note that the PIN may
show up in the log.

Fixed with commit 6286d01 for 2.0.23.

Fixed with commit 9d89564 for 1.4.16.

Thanks for reporting.

Well, I don't known what Homebrew is?

Don't run it under debugger.

Please report a bit more than a shreenshot. We prefer to have at least the key
items reported as plain text so that we can search for it.

Please start kleopatra or gpa first - then start Outlook. Does that work?

Just tested with Cherry SMARTTERMINAL ST-2000U (via pcsc -> ccid).
Same issue with that reader, so not related to reiner-driver.

When I don't set the "enable-pinpad-varlen" option, pin-validation is done via
pc keyboard, if I do set the option, the complete action fails without asking
for the pin in any kind:

scdaemon[5137]: DBG: prompting for pinpad entry '||Please enter the PIN%0A[sigs
done: 46]'
scdaemon[5137]: DBG: dismiss pinpad entry prompt
scdaemon[5137]: verify CHV1 failed: Invalid value
scdaemon[5137]: app_sign failed: Invalid value
gpg: signing failed: Invalid value
gpg: signing failed: Invalid value

And pcscd must be restarted then, to get the setup working, again.

It would be nice to have this correct. HTTPS is far from perfect solution, but it's still one additional layer of protection. (Everybody should check the signatures on downloaded packages).

Based on that, you should remove all code from script and replace it with a
message instructing to use the other tool. I do not understand how providing
non-workable code has any value.

I do not want to reopen this... but it is odd. Feel free to ignore.

Thanks!

Something got screwed up in the somewhat bizarre chain of includes. My

only work around is to manually include the needed typedefs.

I'm not a programmer and I don't know what "manually include the needed
typedefs" means.

Interestingly the problem I report doesn't exist when gnupg2 is built within
Homebrew.

The --disable-agent doesn't matter for this bug. It's the same without it.

It's an artifact from Homebrew, which for whatever reason splits things into one
package for just the agent, and another for gnupg2-sans-agent.

Right: PKIX (as used by HTTPS) is not secure - we all know that.

STARTTLS for public mailing lists does not make any sense.

Duplicate of T1547

See T1547

See bug1547

Duplicate of T1547

No. The script has only not removed to not break existsing packaging systems
and to notify the user that a better tool is available.

Placeholders for ECDSA and ECDH. This is due to a change to support building
with Libcgrypt 1.6.

It has been mentioned at the ML that your problems might be related to a
misconfigured build machine. Please continue discussion at the ML.

@balderdash: Using --disable-agent is not a good idea

I'm vaguely surprised you were able to recompile libgcrypt 1.5.3 using Xcode 5.0.

See 1540.

See 1541. Something got screwed up in the somewhat bizarre chain of includes. My
only work around is to manually include the needed typedefs.

D181: 389_cert_card.patch

While it is provided, please make it work. The patch is trivial.

Done for 1.4.15 and 2.0.22.

Done for 1.4.15 and 2.0.22.

Done for 1.4.15 and 2.0.22 to be released today.

Will do so.