Sry I accidentally posted an incomplete message with T2812 (aheinecke on Oct 31 2016, 05:08 PM / Roundup) (I used itsalltext
and postet a wrong version).

I wanted to write:

On the command line it's looking good. The second keylist is also down to 5
seconds on Windows.

But used from gpgme it still takes about a minute. If you add --with-colons and
slow down system calls by using strace you can also see this on GNU/Linux:

~> time strace gpg2 --no-default-keyring \

--keyring /usr/share/keyrings/debian-keyring.gpg \
--no-auto-check-trustdb --trust-model pgp \
--with-colons -k >/dev/null 2>&1

2.26s user 0.40s system 102% cpu 2.601 total
~> time strace gpg2 --no-default-keyring \

--keyring /usr/share/keyrings/debian-keyring.gpg \
--no-auto-check-trustdb --trust-model tofu \
--with-colons -k >/dev/null 2>&1

21.43s user 24.47s system 108% cpu 42.451 total

On Windows it's:

PS C:\Users\aheinecke> Measure-Command -Expression { gpg --no-auto-check-trustdb
--trust-model tofu --list-keys > $null
}
TotalSeconds : 7.0945596

PS C:\Users\aheinecke> Measure-Command -Expression { gpg --no-auto-check-trustdb
--with-colons --trust-model tofu --lis
t-keys > $null }
TotalSeconds : 56.0914993

PS C:\Users\aheinecke> Measure-Command -Expression { gpg --no-auto-check-trustdb
--with-colons --trust-model pgp --list
-keys > $null }
TotalSeconds : 1.4855689

I'm also still seeing decryption blocked on Windows while a keylist
--with-colons runs.

I wonder if we should generally check out performance of reading the keyring on
Windows
mabye we could genrally improve it so that it's better cached by Windows.

7a634e48b13c5d5d295b8fed9b429e1b2109a333 should fix the contention issue.
Please let me know if you are still having issues.

That's awesome aheinecke! Honestly wasn't sure if this issue would ever get much
attention. Thanks for the effort in making Gpg4win a more secure product!

eec365a & 614ca00 fixed the performance issue for me here.

us@chu:~/neal/work/gpg/test (GnuPGTest)$ rm tofu.db
us@chu:~/neal/work/gpg/test (GnuPGTest)$ time gpg --no-default-keyring --keyring
/usr/share/keyrings/debian-keyring.gpg -k >/dev/null
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: Note: signatures using the MD5 algorithm are rejected

real 0m45.569s
user 0m34.316s
sys 0m10.872s
us@chu:~/neal/work/gpg/test (GnuPGTest)$ time gpg --no-default-keyring --keyring
/usr/share/keyrings/debian-keyring.gpg -k >/dev/null
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: Note: signatures using the MD5 algorithm are rejected

real 0m2.306s
user 0m2.284s
sys 0m0.020s
us@chu:~/neal/work/gpg/test (GnuPGTest)$ time gpg --no-auto-check-trustdb
--trust-model pgp --no-default-keyring --keyring
/usr/share/keyrings/debian-keyring.gpg -k >/dev/null
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: please do a --check-trustdb
gpg: Note: signatures using the MD5 algorithm are rejected

real 0m2.261s
user 0m2.248s
sys 0m0.012s

The first time a key is encountered, we need to do a number of checks that
require reading its keyblock. These include checking whether the key is signed
by an ultimately trusted key. So, this cost is pretty much unavoidable, but it
should be a one time thing.

That other gpg processes stall is surprising, and I will investigate this. I
went to a fair amount of trouble to make sure that that doesn't happen in practice.

That the cost is higher on subsequent runs is a bit disconcerting. I will also
investigate this.

GpgOL is built with DEP and and ASLR now. Need to enable this for GpgEX and some
other parts of Gpg4win, too. So not yet fully resolved but I keep it in mind.

Under GNU/Linux you can compare the strace output to see that there is a problem
even if it's quick because it is cached:

~> time strace gpg2 --no-auto-check-trustdb --trust-model pgp -k 2>&1 |wc -l
33383
strace gpg2 --no-auto-check-trustdb --trust-model pgp -k 2>&1 1.04s user 0.45s
system 104% cpu 1.433 total
wc -l 0.02s user 0.16s system 12% cpu 1.433 total

~> time strace gpg2 --no-auto-check-trustdb --trust-model tofu -k 2>&1 |wc -l
558528
strace gpg2 --no-auto-check-trustdb --trust-model tofu -k 2>&1 9.60s user 8.47s
system 106% cpu 17.022 total
wc -l 0.60s user 2.34s system 17% cpu 17.022 total

This is with my normal pubring that contains 790 public keys.

I run in the same issue as PRab whenever I suspend or hibernate my machine. The
machine as Broadcom BCM5880 with a smart-card reader, so I cannot unplug it.
Quickest workaround is to kill/restart scdaemon.

Is there/could there be a command that could be sent to scdaemon via the agent
so a reset could be triggered? It should be easy enough to line that up as part
of the resume scripts.

It is now patched in gpg4win and I think aheinecke pushed the patch also to linux.

The Bug iteself has been resolved with that patch, but is yet unreleased.

I'm on T2448 (aheinecke on Sep 05 2016, 02:14 PM / Roundup).

Jochen, is T2448 (aheinecke on Sep 05 2016, 02:14 PM / Roundup) something you could do?

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.