I've tested to generate an rsa2048 key with backup on a v2.0 card and it works
now. I have not tested restoring from backup etc. But as this report was about
the failed generation, this issue is resolved imo.

Thanks!

The patch seems to have fixed it.

I removed the not-working checkbkupkey subcommand in
44aee35e69540510617aea4b886ef845590960fe

Also fixed the bkuptocard subcommand in: 40959add1ba0efc1f4aa87fa075fa42423eff73c

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

Thanks, I can confirm that this solves it.

Fixed with commit af14285

Fixed in
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=b30c15bf7c5336c4abb1f9dcd974cd77ba6c61a7

I've implemented this in fc010b6. If you get a chance to test it, I'd
appreciate any feedback! Thanks!

I confirm that I'm not able to reproduce T2176 (guilhem on Dec 11 2015, 02:21 PM / Roundup) nor T2176 (guilhem on Dec 11 2015, 01:07 PM / Roundup) with 4ffe44c, so
I'm changing the issue to “resolved”. Thanks for the prompt action!

For my case with OpenPGPcard, the patch fixed the problem of wrong fingerprint
computation. Please test with the patch.

Sorry for my mistake for reading your post. I considered it would be the case
for m, but I also fixed the case for e, the exponent.
Here, I reproduce the problem with OpenPGPcard (while it only occurs 1/256 with
Gnuk Token).
I confirmed that original OpenPGPcard returns e as four bytes 00 01 00 01 with
0x00 in front. This causes 100% failure for fingerprint computation.
I'm going to test the patch with OpenPGPcard. (I'm now installing newer
libgpg-error, to build master of GnuPG.)

gniibe: its not one failure in 248. It was 248 failures in 248 tries...

werner: I had to downgrade to have a working system. I hope I'll find time to
reproduce this this week

Thank you for the bug report. The ratio of 1 failure among 248 made me a great
hint to locate the bug.

I think that it is fingerprint computation bug, which is fixed here:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=d40975cbe8ff86fcc4a1b4963fdffc66ddee85ce

Emanuel tested this. As I wrote, inline editors are another thing.

Thank you for your testing.

Your change is pushed with my comment:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=d1a97585c5e73fbc7d4cf90e38f76ffc5aea305f

I'll backport this to GnuPG 2.0.

Here's the logfile with all the errors (guru debug level) vanilla 2.1.10

After some time spending fighting with the build tools of gnupg (cross compile
for windows under debian) I managed to build the installer with my patched
file.

Most important: The most common error thrown is the 0x8010001e
(E_SERVICE_STOPPED) This is the important one. The other error 0x8010001d
(E_NO_SERVICE) is only thrown in the transition from ok to stopped. So only
sometimes.

This was my process:

git clone git://git.gnupg.org/gnupg.git
cd gnupg
git checkout tags/gnupg-2.1.10
./autogen.sh
cat ../0001-scd-Fix-removal-of-unplugged-usb-readers.patch | patch -p1
sed -i -e 's/^SELFCHECK=1/SELFCHECK=0/' build-aux/speedo.mk
make -f build-aux/speedo.mk w32-installer

I've created new logfiles (vanilla 2.1.10 und patched 2.1.10) to show the
difference and confirm that it'S actually working now :-)

I'm okay with signing off the commit. I can test this for Windows 8.1 or 10,
my only problem is that I'm not able to compile gpg for windows right now. Or
are there instructions somewhere on how to achieve this?

Thank you again.

I think that Windows 8 (and later) changed the PC/SC service. The service is
only available when smartcard is there, and after the removal, it returns
PCSC_E_NO_SERVICE error. This is not expected for current code.

I'm applying your patch with my comment like above. Do you agree to put the
line in the commit log?:

   Signed-off-by: Daniel Hoffend <dh@dotlan.net>

I don't have Windows 8 machine. So, I leave this issue as testing.

Should be fixed in git master. There is a small issue that sending encrypted
drafts from the inline reply window does not work. But if you open the draft in
a composer the Sign / Encrypt state is the same as it was when saving the draft.

The inline thingy is another issue. I can catch that and add a Messagebox to
tell the user she should open the messagecomposer to send.

We've added support for Outlook 2016 with gpg4win 2.3.0 (gpgol 1.3.0). Which has
just been released two days ago :-)
Please try this version.

Werner, I know that nothing much in pinentry has changed since 0.9.6 but this
bug is pretty bad for pinentry-qt. It would be good to have a new release.

I had a look at your logs. Indeed I can see where it crashes, and it really
looks like gpgol did something at the time of the crash. It crashed after a Mail
was Loaded by outlook and before it was read. I've read the related code again
and could not find a problem.

If you are testing again anyway Please set your EnableDebug value to 1536. This
enables Debug output related to outlooks internal data model and could help.

It was a crash. Outlook has been terminated and restartet automatically (can be
seen in gpgol log).
Now I'm going to start with gpgol enabled and I'll enable all other plugins step
by step.

We don't see any more crashes in testing and we had some other people test
1.3.0. before the release. Is it crashing or does outlook freeze up / not
responding?

Just to ensure that we have comparible setups, have you enabled other plugins
again? If so which?

I'll take a look at your debug output to see if I find something out of the
ordinary.

I installed the new gpg4win 2.3.0 release and activated gpgol. When answering an
email I had another crash reported in ntdll.dll. But I suspect that the crash is
related to gpgol even though it's not directly reported.
Now I'm going to leave gpgol disabled.
The corresponding logs are appended and might be that there are some hints inside.
Best regards
KJ

I've tried to improve the web page.

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg-doc.git;a=commit;h=fa61217e26a97c4b9f3294746a581aee5eb47ad8

Since Werner needs to check this, I'm changing the status of this issue to
testing and adding him to the cc.

@Reuben: If you have some ideas of additional improvements, I'd be grateful.
Thanks.

After installing the lastest beta I had unfortunately several crashes of Outlook.
The crashes are reported for severeal modules. There was no crash in module
gpgol reported, nevertheless I disabled gpgol.
If there are some news - even no more crash - I'll give an update here.

Best regards
KJ

I had all flags enabled (2047) and set it now to 1.

Thanks again.
KJ

There was only a crash at the very beginning when I started outlook and forwared
an email with encryption to myself. Outlook crashed but module MSPTLS.DLL has
been reported to be the cause of the failure.

I'll try it out.

In the log file of gpgol I noticed that there is a huge amount of messages
in.lock taken or released and the same for out.lock. Is it possible to disable
selectively these lines because it floods the disk and I'd like to have some
debug lines enabled if some problem might occur.

Yes just set the enableDebug registry setting of GPGOL
(HKEY_CURRENT_CUSER/Software/GNU/GpgOL) to 1
You currently probably have it at a much higher level.
This will disable the most spamming debug outputs and leave the important stuff
active.

Thanks for the quick fix and your detailed answer.

I installed the new version and had nearly no problems: I successfully exported
contacts serveral times (even waiting more than 10 minutes) and de- and
encrypted emails multiple times.

There was only a crash at the very beginning when I started outlook and forwared
an email with encryption to myself. Outlook crashed but module MSPTLS.DLL has
been reported to be the cause of the failure.

In the log file of gpgol I noticed that there is a huge amount of messages
in.lock taken or released and the same for out.lock. Is it possible to disable
selectively these lines because it floods the disk and I'd like to have some
debug lines enabled if some problem might occur.

Best regards
KJ

I'm marking this as resolved as the currently released version of pinentry
compiles with gcc-5.1

Given the amount of time since the request for testing, I don't think we are
going to get a response. As such, I'm going to close this issue and mark it as
resolved. If there is still a problem please either reopen this bug report or
file a one. Thanks.

I'm marking this as resolved. If it is still an issue, please feel free to
reopen. Thanks.

Version 2.4.0 has been released which replaces the used vasprintf code.

Fixed with commit 8b6c83d for 2.1.10.

Uh that's an embarassing error.

Thanks for your analysis and fix. I haven't seen problems with this in my tests
but the UTF8 Byte array is indeed temporary and the pin pointer is invalid after
it's destruction.

I've commited the your fix (with an ammended commit message so it confirms to
the msg style used in pinentry) with f143d21

Werner I've assigned it to you as this needs a release :/ Sorry.

For 1.6, please see:

    commit d501cc4edd55d3953d7581b3f8ff0c348df31ef0
    commit 24f6c65e36edec13aa781862ff1ff45ca3e99b99

Please test.

No problem!

Regarding ipv6. It's not that my OS doesn't support it, it's that the network I
am currently connected to (on my laptop) is not providing IPv6. There's nothing
to say that I won't move to another network that does.

Detecting IPv6 capability would be useful, but (I think) difficult. Especially
since I can move between networks in the lifetime of a single dirmngr. If I move
from a network *without* IPv6 to a network *with* IPv6, should dirmngr realise
and re-enable IPv6?

Anyway, we should open a new bug for this?

P.S.

The fix is applied to OpenBSD ports 2.1.8.

Cheers

What I have in mind is to create a meta data file for each key file. This file
can then be used for things like confirm flags. Tehre is for example a request
to adda confirm flag for OpenPGP keys if used with --extra-socket. Maybe we can
even fade out sshcontrol and use such a meta data file instead.

Then it would be really useful to have a GUI to edit these files.

looks good to me

Right. Hopefully fixed with 48ab8cd

I wonder why this worked for me. If I try to run your testcase it fails with
bash / dash / zsh.

Thanks, but I'm afraid that's not sufficient; the issue of the whitespace after
have_qt5_libs still exists after that commit for bash.

See the following test case: $ cat ./test.sh
#!/bin/bash
have_qt5_libs="no";
echo ${have_qt5_libs}

have_qt5_libs2 = "no";
echo ${have_qt5_libs2}

$ ./test.sh
no
./test.sh: line 5: have_qt5_libs2: command not found

The good news is that besides this buglet I've now pushed the updated revision
to our testing repository and have yet to get any bug reports. The patch I've
pushed is
https://gitweb.gentoo.org/repo/gentoo.git/tree/app-crypt/pinentry/files/pinentry-0.9.6-add-disable-pinentry-qt5-option.patch#n38
which doesn't experience this issue.

I've fixed the variable assignment with rev. e9d063e
Sorry. Worked for me on debian jessie with dash.

Thank you for testing.

ssh-add'ing your key, you have .gnupg/private-keys-v1.d/<KEYGRIP>.key registered.
Removing an entry in .gnupg/sshcontrol manually doesn't remove the file, and it
results inconsistent state.
Please remove the file.

I admit that current UI set for SSH is not enough; we need improvement here.

"+ have_qt5_libs = no;" result in command not found issues in configure so I
changed this to "+ have_qt5_libs="no";".

I've done some preliminary packaging tests and things seems to be working as
expected, will give it some more local testing before pushing it onto users in
testing

Sorry, I spoke too soon on that last message, the bug was still there, I was
just running the agent at version 2.1.7... not awake yet.

Anyway, your patch solved the issue of not being able to add new keys to the
agent via ssh-add, though it may have raised another issue.

I successfully added a new key to the agent, then I removed it from the
ssh-control file and added it again. When trying to readd it after restarting
the agent, it did not show a password prompt to set the password. Instead it
returned a successful message without actually adding the key to the agent.

% ssh-add foo
Identity added: foo (foo)