Finally, I confirmed the problem. Sorry for taking long time. My understanding
was bad. I'm going to fix this.

I removed the not-working checkbkupkey subcommand in
44aee35e69540510617aea4b886ef845590960fe

Also fixed the bkuptocard subcommand in: 40959add1ba0efc1f4aa87fa075fa42423eff73c

Fixed in aecf1a3c.

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.

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.

Fixed in 1.4.20 (and 2.0.28).

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

I'm considering fixing this.

New Debian package is uploaded based on master branch of Poldi.
Problem has gone, so, closing this issue.

In the current master, there is no problem.
In Debian, we needed to add -lgpg-error due to questionable patch introduced by
Debian itself: https://bugs.debian.org/405238

When we use libgcrypt installed by released version of libgcrypt, the master
branch of poldi has no problem.

It is base64 trimmed the last '='.

Introducing new specifier, say %f, would be good, while keeping %F as is.
%f includes the hash algorithm string as SSH does.

I think that current lock/unlock mechanism is only for mutual exclusion between
multiple writers. I mean, lock/unlock is done to avoid inconsistency caused by
multiple writers.

It seems that we forget to implement mutual exclusion between writers and
readers, as Neal described.

Before 2.1.10, the write access was limited to specific interactive usage
patterns and it didn't cause major problems (it caused rarely if happened).
Now, I think that we should implement mutual exclusion between readers and writers.

I think that this was fixed in:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=d1a97585c5e73fbc7d4cf90e38f76ffc5aea305f

It will be in 2.1.11 and 2.0.30.

I confirmed that this is fixed in 2.0 and 2.1.

Thank you. There is no reason. It is fixed in:

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

Thank you for your audit.

It ignores the calculated value if it detects failure of gcry_pk_verify.
This is now a kind of standard practice to avoid possible attacks.

Here is a reference:
https://securityblog.redhat.com/2015/09/02/factoring-rsa-keys-with-tls-perfect-forward-secrecy/

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.)

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

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.

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.

Closing, I assume it's the same bug of 2112, which was fixed.

Thank you for the bug report with log.

It could be related to the bug which was just fixed:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=f42c50dbf00c2e6298ca6830cbe6d36805fa54a3

I'm backporting this to 2.0.x.

Sorry for your trouble. I believe that your key includes ed25519.

Once, we introduced a bug and it was fixed in 2.1.9. For a key registered by
old GnuPG by ssh-add, it should be removed and to be add again.

Thank you for pointing out. It was long standing mistake.
Fixed in the repo.

Ah... It is finally reproducible for me.

The problem is: '-i' doesn't mean importing. You need to use '--import' to
import keys. '-i' means '--interactive'.

'gpg -i file' just tries to parse the file. Secret key parsing became
unsupported in 2.1.x.

Thank you for your cooperation.
I think that the message was emitted by 'gpg -d' (not 'gpg -i').
Could you please confirm that by invoking 'gpg -d sec.asc' alone?

In my environment (Debian testing), the symptom is not reproducible with 2.1.8,
2.1.9, and development version of gnupg. It is decrypted with no problem, and
it is imported with no problem.

If you know there is Arch Linux specific patch, please let me know.

Please do that:

$ script output-log.txt # which invokes new shell
$ gpg --version

And run your gpg commands of exporting and importing keys.

$ exit

Then, you have a file 'output-log.txt'.
Please describe your oparating system and your configuration file.

Please remove your private key(s) of ed25519 and register it again.

Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798956#24

Sorry, I can't understand your situation to identify bug(s) by your explanation.

Please give us your command lines of import and exact output of GnuPG (before
your interpretation). Exact session log is preferred.

Please note that the message, "GPG: FIXME: merging secret key blocks is not
anymore available" is not an error, but the debug message,
which should not be encountered by importing keys.

So, I guess that something wrong was happened.

For 1.6, please see:

    commit d501cc4edd55d3953d7581b3f8ff0c348df31ef0
    commit 24f6c65e36edec13aa781862ff1ff45ca3e99b99

Please test.

Thank you for the patch. I apply to master.
I'm going to apply to 1.6.

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.

Using PC/SC, I believe that you can revive your cards.

Please see:
https://lists.gnupg.org/pipermail/gnupg-devel/2013-March/027518.html
https://lists.gnupg.org/pipermail/gnupg-devel/2013-March/027519.html

Thank you for your report. There is no logic to check fingerprint. So, I think
that the key retrieval itself might fail somewhere.

Assuming your gpg2keys_curl is installed at /usr/lib/gnupg2, could you please run
following command, and input lines?

$ /usr/lib/gnupg2/gpg2keys_curl -o public-key.asc
COMMAND GET
HOST gist.githubusercontent.com
SCHEME https
PATH
/aelana/0cde322d66206ea5fb90/raw/1cc31e99fbdb5a75e4104fe597794ec3dccd6bc4/gistfile1.txt

0x85D5A0DA4EC2B038128F9D8847912162AEB99527

<<<<< OUTPUT FROM SERVER IS EXPECTED HERE >>>>>

Yes, I believe 2.1.8 should work well. The private key management is moved to
gpg-agent, and gpg-agent automatically create stubs.

I tested with 2.0.29 and it works well.

Perhaps, this is same bug in T2112

I think that the problem is fixed in 2.0.29.
And the display improvement (msg6937) is backported, it will be in 2.0.30.
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=fea9d4354c93b662c75febe020fb799ce4f2ec89

D330: 688_gpg-ssh-agent-20150929.diff

Sorry, the patch of yesterday was wrong.
Please test attached new patch of gpg-ssh-agent-20150929.diff.

For no pinentry pop-up, I think that this is same cause described in the Issue 2112.
Please try the patch in T2112

D331: 687_gpg-ssh-agent-20150928.diff

Thank you for the bug report with the trace.

I think that the code has been buggy and the change since 2.1.7 reveals the bug.
Here is the possible fix. It's the pointer calculation error.

If it's Bash, it is like:

$ rm -i ~/.gnupg/private-keys-v1.d/$(gpg-connect-agent "KEYINFO --ssh-list"

/bye | awk '{print $3}').key

It has been fixed. However, because the keygrip is same (before the fix and
after the fix), ssh-add doesn't update the file.
A user needs to remove the file at first.
I'm not sure what to suggest here.
Perhaps, getting the keygrip by 'gpg-connect-agent "keyinfo --ssh-list" /bye',
and then remove the file.
then ssh-add again.

If you can binary-edit, please add
prefix @ (0x40) to the public key in the *.key file.
There is the sequence like:

...(3:ecc(5:curve7:Ed25519)(5:flags5:eddsa)(1:q32...

This shoule be changed:

      ...(3:ecc(5:curve7:Ed25519)(5:flags5:eddsa)(1:q33@...

Sorry for your inconvenience.

When did you create your GPG key of ed25519?
Or... did you register your SSH key by ssh-add?
If so, gnupg/agent/command-ssh.c:2147 doesn't add prefix 0x40.
That's the problem.
Sorry, that's my badness. I didn't look through this code path.

Fixed in 1.6.4.

Fixed in 1.6.4.

Perhaps, we need to backport this change:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=874ef16e70ab750db7b153f17a7e859a0db6a2f1

I wonder if this is related to the change of
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=80521c3ff900a09a1b382869783187c463144c77

Do you have 'allow-loopback-pinentry' option in your .gnupg/gpg-agent.conf?
It is not enabled by default, since allowing loopback mode gives easier access
to private keys.

committed to master branch:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=b3286af36d452fc801be573a057b0838d53a2edd