Backport was done with commit rC1d312bc65846 (for unknown reasons it did not show up in the list of bugs related to this bug; I added it by hand). Fix will go into 1.8.8.

I think that a backport to 1.8. also makes sense

Reading the code again, I think that some configuration of NKS card doesn't work well, when it has no certificates but keys (e.g. IDLM config).
I'm going to fix do_readkey as well (the approach #1).

In T5150#140039, @gniibe wrote:

With little (mostly no) knowledge of NKS card, I think I fixed this issue.

Thanks a lot for your time to locate the problem. I took the approach of #2.

I'm not sure why I thought that it would work now. With current master I get

$ gpg-connect-agent "SCD READKEY --info-only -- 39400430E38BB96F105B740A7119FE113578B59D" /bye
ERR 100663414 Invalid ID <SCD>

Fixed in master. I will backport to 2.2.

Seems to work now. I'm not sure whether I should close this issue because it's marked for backport.

Regarding a backport I think that I will eventually backport all app-*c to stable by source copying them. We have a quite stable internal API and thus it is easier to keep at least the card specific code in sync. I did some local work in this directory some time ago.

Thanks.

Thanks.

Thanks. May also happen if the first print_assuan_status fails.

Thanks. Fixed in master. Needs backport.

Thanks. Fixed in master.

Editor fault. The browser's editor is not like Emacs and here o my laptop the backspace key does not work as intended. I guess I was about to write ".. a back signature's usage flag".

what does "back signature's usage tool" mean? can we make an addition to the test suite that ensures that bad signatures will be rejected?

The fix was not fully correct because it considered a back signature's usage tool.

Done for master. Needs backport.

thanks for looking into this so quickly. where is your patch? i don't see it on the master branch yet.

Thanks for reporting and your patch. However, I used a different way to solve this bug.

Thanks. Pushed to master. I think it should also go into 2.2.

I just verified that this is indeed fixed.

No I don't recall any such problems, sorry.

@werner The backport to 2.0 didn't happen, I think. Is this still relevant. @justus Do you recall any more problems in the tests?

For the T2238, it was backported in effect (not intentional, though).

1.4: ca1fc59
2.0: 1c15136

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.

Commit e70f7a5 fixes this for 2.1.
Should be backported.
Thanks.

backported by dkg with commit 0c3d764 for 1.4.19

dkg: I've now applied your backport to the 1.4 branch. Sorry for not doing this
sooner. I believe that this now completely rectifies this issue. As such, I'm
marking this issue as resolve. Thanks.

Based on Werner's comment, this issue has been addressed. As such, I'm closing
this bug report.

See T2106 for the SHA-256 feature.

I have not yet used that new ssh version. Will look into it soon to get the MD5
fingerprints replaced.

The MD5 bug has been fixed with commit 2167951:

• gcry_md_write (md, "384\0\0\0\x08nistp521", 15);

+ gcry_md_write (md, "384\0\0\0\x08nistp384", 15);

2.0.29-beta has a fix for this. See also T1823.

backport for 2.0 commited. Thanks.

Fixed with commit 0c3d764.
Should be backported to 1.4.

Back ported to 2.0 (commit 2b2adb85948ce2c7db727ebc0c99e8ad2c29bf5f)

Fixed for 2.1 with 382ba4b.Should be backported to 2.0 and 1.4.

Should be fixed by commit 017c6f8fba9ae141a46084d6961ba60c4230f97a
on 2014-06-24.

Backported to 2.0: commit 2424028.

backported to 2.0 and 1.4.

Fixed in master will be backported to 2.0.
That is a very well written bug report. Thanks.

Backported to 1.4. It has also been applied to master some time ago.

Fixed for master.

Fixed for 2.0. But take care: The code now also uses the fixed-list-mode which
is the default in --list-keys for ages:

pub:-:1024:17:4713D527ECE16009:1118095577:::-:
fpr:::::::::8BFD3F436366D9820E9EAB2F4713D527ECE16009:
uid:::::::::George Hacker <georgeh@axian.com>:
uid:::::::::George Hacker <ghacker@axian.com>:
uid:::::::::George Hacker (GLS) <ghacker@redhat.com>:
uat:::::::::1 2493:
sub:-:1024:16:0D94CF6C0C8C2F1B:1118095578::::

Thanks, it's no problem to wait until 1.6.2. I just tested the patch and it's
working as intended.

Oh no!

I recall that I looked up the commit id this morning but obviously was disturbed
and thus didn't actually complete the cherry-pick. Sorry. I just pushed the
change. We need to wait some time before we can do a 1.6.2.

I attach a patch for 1.6.1.

D187: 422_0001-cipher-Take-care-of-ENABLE_NEON_SUPPORT.patch

Did you intend to include the changes in 1.6.1? It doesn't appear that they made
it into the release.

Done and 1.6.1 released

Thanks. I backport it tomorrow.

I just tested with the changes applied to the LIBGCRYPT-1-6-BRANCH head, minus
the sha1.c changes (since the NEON parts weren't there), and it is building and
running fine for me. I assume it should work fine in master given this, and can
test that later if you would like, I'm just currently missing the libgpg-error >=
1.13 dependency for doing that. Thanks for your help getting this fixed up.