Jochen: I'd rather you (manually) patch the dirmngr tarball included in
gpg4win-2 and create a testinstaller and try that one out.

I found the Problem in this issue and tested that the attached patch solves the
problem, yes It would have worked on GNU/Linux as the "b" has no effect there.
Finding out since when the problem existed appears moot to me and you would have
to check in dirmngr's SVN and likely always existed.

But maybe there are additional problems (as this is imo a very exotic feature)
so it would probably make sense to test it again on Windows before preparing the
next stable Gpg4win release.

Jochen, can you please find out:
a) Does this still work on GNU/Linux?
b) Did this work with elder Gpg4win version? With binary search you

should find out qickley when this broke.

this also affects version 2.1.15 (latest gpg4win beta) and 1.1.1 (latest gpg4win
stable)

Okay, if this transfers line endings because of the textmode read, it will
depend on the contents of the CRL in question. This explains why the defect was
not seen in earlier testing.

And pem does not work for this (I guess and tried on a GNU system).
It is okay that pem does not work, because this is a rarely used function I think.

Interesting...

The Kaspersky issue is about Outlook 2007... Is that supposed bug really already
THAT old?!

This could be a nasty one. The crash occurs after the data structure of the mail
was unloaded in outlook and GpgOL already completely detached it's event
handlers from the object and frees up the memory. GpgOL is not executing any
code when the crash occurs. That outlook blames GpgOL is likely because it jumps
into an invalid memory region that was allocated for GpgOL but is no longer
valid. This shouldn't happen though as we have already successfully unregistered
all our callbacks.

So I currently think that somehow when using send from explorer outlook through
some side effect / bug does a callback into GpgOL's event handling code which
was already destroyed. I'll try to confirm that theory on monday by keeping the
event handlers around after the unload event occurred.

Also does not appear that we are the first ones with that problem:
https://forum.kaspersky.com/index.php?showtopic=225375

:-/

Thanks! :-)

Thanks for the report. I am able to reproduce the problem.

Looking into it.

Ah, I misunderstood your problem. In the future, please paste all program interactions in one chunk
in the right order. We did merge some changes related to exporting of secret keys, so it may very
well be solved by that.

Thanks for caring :)

I think the problem is that your key export fails, because you pointed
--homedir at the (presumably) empty directory "%tmp%\_tempKeyring".

The export did not use any filter and tried to export a key as can be seen in
Msg8313 "error receiving key from agent"
The import itself also stated no errors as it can be seen in T2355 (dranft on May 12 2016, 03:00 PM / Roundup), but this
imported secret key cannot be used (or exported) anymore.
Also important: This is no longer reproducible in 2.1.14 (which might be enough
to set the bug to fixed)

I don't believe this demonstrates a bug.

I think the problem is that your key export fails, because you pointed --homedir at the (presumably)
empty directory "%tmp%\_tempKeyring". This leads to the not very helpful error message about the
eof. If the export were successful, gpg would have written the key to stdout.

For reference, here is what I tried. First GNUPGHOME points to a home with the key I want to export:

    $ echo $GNUPGHOME
    /tmp/tmp.T7I4M9RIc3
    $ g10/gpg --list-keys alpha
    gpg: please do a --check-trustdb
    pub   dsa1024 1999-03-08 [SCA]
          A0FF4590BB6122EDEF6E3C542D727CC768697734
    uid           [ unknown] Alfa Test (demo key) <alfa@example.net>
    uid           [ unknown] Alpha Test (demo key) <alpha@example.net>
    uid           [ unknown] Alice (demo key)
    sub   elg1024 1999-03-08 [E]

You need some kind of pinentry program, because you may be asked for the current passphrase or an
export passphrase:

    $ cat $GNUPGHOME/gpg-agent.conf
    pinentry-program /usr/bin/pinentry-x11

Now export the key:

    $ g10/gpg --export-secret-keys alpha >/tmp/alpha.gpg

Now I create an empty home, and import the key in batch mode:

    $ export GNUPGHOME=$(mktemp -d)
    $ g10/gpg --batch --import /tmp/alpha.gpg
    gpg: keybox '/tmp/tmp.bL2caQmZri/pubring.kbx' created
    gpg: /tmp/tmp.bL2caQmZri/trustdb.gpg: trustdb created
    gpg: key 2D727CC768697734: public key "Alfa Test (demo key) <alfa@example.net>" imported
    gpg: key 2D727CC768697734: secret key imported
    gpg: Total number processed: 3
    gpg:               imported: 1
    gpg:       secret keys read: 3
    gpg:   secret keys imported: 2

Could you please check if that works for you?

To make it clear: I'm not even trying to sign or encrypt, just send a plaintext
message with attachment also in the clear.

Gpg4win 2.3.1 and 2.3.2 included 64 bit versions of gpgol.

Duplicate of T2171

You can now. Thus is not a bug but a feature request.

Note that we do not use Microsoft compilers but use gcc and in cross build
environment.

PS: forget the --homedir thing, it is even reprodicable in the default folder in
%appdata%.

Sorry, forgot my import cmdline:

C:\Program Files (x86)\GNU\GnuPG\2.1.12\bin>gpg --batch --homedir
%tmp%\_tempKeyring --import "P:\2EEC2B65A2B4B3EF.sec.asc"
gpg: Die "Keybox" `C:/Users/ranftd/AppData/Local/Temp/_tempKeyring/pubring.kbx'
wurde erstellt
gpg: C:/Users/ranftd/AppData/Local/Temp/_tempKeyring/trustdb.gpg: trust-db erzeugt
gpg: Schlüssel A2B4B3EF: Öffentlicher Schlüssel "Daniel Ranft (Giegerich &
Partner GmbH)" importiert
gpg: Schlüssel A2B4B3EF: "Daniel Ranft (Giegerich & Partner GmbH)" nicht geändert
gpg: Schlüssel A2B4B3EF: geheimer Schlüssel importiert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 4
gpg: importiert: 1
gpg: unverändert: 1
gpg: gelesene geheime Schlüssel: 3
gpg: unveränderte geh. Schl.: 2
gpg: keine ultimativ vertrauenswürdigen Schlüssel gefunden

Please explain the version number you entered and from where you downloaded GPA

Actually we are working on a 64 bit version.

Thanks for testing 2.1 and for reporting the results.
Good to know that it works now.

I have good news : gpg 2.1 rocks !
Problem solved and here is the solution :

As Sijie said, the "smartcard compatible" pageant was loading the SIG key and
the AUTH key.

Unfortunately, under gpg 2.0.x, when you export a public key and use gpg2ssh,
the output is the ssh key for the SIG key (and not the auth).

So when using gpg-agent, it was waiting for putty to request the AUTH key and
not the SIG key (as it should !). The "smartcard enabled" pageant was sending
the SIG key so it was working with it.

Now for the good part : with gpg 2.1, we can now natively use --export-ssh-key,
and this command export the AUTH key, so in the end, it works :)

Thank you everyone for the help, and I hope it can helps other people too !

Can we close this bug please ?

Regards

For history purpose, and trying to maximize information, I have been asked to post some part of the discussion I have
on the mailing list about this problem. Here it is :

I tried older version (of gpg4win) (which, at the time, worked for people with the
same setup as myself), but I can try new version too of course.

That is helpful, because development right now is concentrating more
on Gpg4win 3 with the new GnuPG 2.1 (to become 2.2) and this is where
gpg-agent and pinentry is handled slightly differently. So making sure that
it works with the new version is better for the future.

Ok, I installed gpg4win 3.0.0 BETA 128.
The problem stay the same, no pin is asked.

In the mean time, I tried this tool : http://smartcard-auth.de/ssh-en.html
It replace the pageant.exe that ships with putty. And it works. When I
log on the server with putty, I got asked for the PIN. So I think this
is not a problem with the smartcard or with keys. It seems that it's
only that gpg-agent doesn't trigger the pinentry.

I tried witht gpg-agent on another computer (fresh install) running Windows 7 x64, and
with another smartcard, same problem : no pinentry asked.

Yes gpg-agent is started before, I can see it in the process list (and even the scdaemon process).

In fact, pageant can't be started at the same time as gpg-agent (I suppose it share the same mutex because it
says "pageant is already running" when I try to start pageant while gpg-agent is already running).

Did you start gpg-agent before putty or pageant?

and there is no w64 version of 1.4

We won't fix such things for 1.4 (Windows)

I believe I have also seen this issue (or something very similar) on my Windows
7 64bit machine. I am running gpg 2.1.11. I hope this isn't redundant, but it
seems that I need to restart scdaemon anytime I unplug/replug my yubikey or
suspend/resume my computer.

Sometimes it doesn't recover even after restarting scdaemon. In those cases, I
am able to fix it by stopping scdaemon, removing the yubikey, starting scdaemon,
and finally reinserting the yubikey.

I've tested it with pubring now too and it works.
Justus mentioned in jabber that he noticed some more errors after this patch in
the scheme tests. I've not tried them.

Okay, so I can backport this to 2.0 ?

Tested this with keybox and it appears to be working. When running a keylist
while importing the import holds for a bit and continues after the keylist.
Not tested this with keyring yet.

MDK7MX, did you retry ?

I commited an adjusted patch for GnuPG 2.1 (3e50236).

I have pushed chnages to master to fix this problem. One drawback is that
during an import another process "gpg -k" may rarely see no keys at all. A full
fix would either require that we lock the keyrings during all read-only
operations, which would severely hit on the performance of all common
operations, or change the whole system to use a new key access daemon.

If this works the changes need to be backported to 2.0.

No Kleopatra does not open the pubring. Let's leave kleopatra out of this.

This bug is about multiple GnuPG processes that conflict with each other. See
msg7466 for an example.

Do you mean Kleo opens the pubring file itself?

Renamed the issue to my current understanding of this problem. Locking on
Windows does not work properly.

Yesterday I had a failed Keygeneration while GpgOL's certificate selection
dialog in Kleopatra was open. Tried again and it worked. I did not get Debug
output but the pattern suggests to me that the Certificate selection dialog
looked for changes in the pubring while generating a key and the locking broke
again.

This problem is rising in my priority of Windows Issues as it causes random
failures. There is also a load of similar reports on various channels to be
found through google https://www.google.at/search?q=pubring.bak

Thank you again.

It is likely that the token itself doesn't work well after wakeup from sleep
mode. In this case, all that we can do is re-inserting the token manually.

I'm not sure how PC/SC service handles USB reset after wakeup.

Sorry to say, but mapping the error to "no reader" doesn't help. The first
reset event doesn't get handled. Later it trys to remove the reader but it's
not getting correctly resetted/reinserted again.

I've attached the debug log again

Thank you for further testing.
I think that current code doesn't handle the case when card goes inactive/reset
while reader keeps working. Current code only goes to the reset sequence for a
card again when it detects reader failure. So, although the concept is
different, I think mapping PSCS_W_CARD_RESET to SW_HOST_NO_READER (for now) will
work. Given the situation we don't yet support multiple cards, this workaround
would be OK for a while.

Nope. Neither mapping the "reset card" event to SW_HOST_CARD_INACTIVE or
SW_HOST_NO_CARD helps. It seems that somewhere in the code the return code
SW error codes are not being handled correctly and the card doesn't get
resetted.

I've attached a small log where you can see that pcsc returns the error
reason "reset card" which then gets remapped to "Card reset required" (was
general error before). I also can see that the error is getting mapped to
GPG_ERR_CARD_RESET (because of the error message "Card reset required")
leaving the daemon around with no working card and reporting general errors
again (0x100b).

Additional Info: This bug only happens when you put your computer/laptop
into sleep mode while the smartcard/reader (yubikey) is plugged in. If I
remove the reader before putting it to sleep and attaching it after getting
out of the sleep mode, the scdaemon works fine.

D338: 740_0002-scd-map-card-reset-event.patch

Maybe it's more appropriate to map the PSCS_W_CARD_RESET event to the
SW_HOST_CARD_INACTIVE error code which later gets mapped to GPG_ERR_CARD_RESET
error code.

I've attached the patch file. It would make sense to backport this mapping as
well. Right now it's not yet tested.

I found another problem with the smartcard service under windows. Putting
the system into sleep mode and waking it up again creates an 0x80100068
error code (aka PCSC_W_RESET_CARD).

I'll test if it helps to map the RESET_CARD event to the same REMOVE_CARD
event to get the card reactivated after sleep mode.

Logfile:
2015-12-21 22:16:57 scdaemon[10040] DBG: send apdu: c=00 i=CA p1=00 p2=C4
lc=-1 le=256 em=0
2015-12-21 22:16:57 scdaemon[10040] DBG: PCSC_data: 00 CA 00 C4 00
2015-12-21 22:16:57 scdaemon[10040] pcsc_transmit failed: reset card
(0x80100068)
2015-12-21 22:16:57 scdaemon[10040] apdu_send_simple(0) failed: general
error

Okay, Feel free to re-open if you see it again.