This has been fixed in the repo (7d5999f). AFAICS, you need to ssh-add the key
again.

Was requested this way by a customer. Note that additional constraints can be
enabled too. I change this to a feature request.

Yeah, I know it is actually an old feature requests to first sort the candidate
keys and then try them in order.

It turns out that it was a symlink in the path that mislead a cwd test in a
Makefile. No problem when building your sources from a real path.

This specific cwd test differs from others found elsewhere in your Makefiles,
maybe you should take a look anyway.

Sorry for the noise.

Please explain in detail what you did to get this error.

With recent versions of OpenSSH, the default fingerprint shown is uses SHA256.
The fingerprints emitted in sshcontrol are MD5. You can get ssh-keygen -l to
produce comparable MD5 fingerprints with "-E md5".

Perhaps the generated sshcontrol should also include the base64-encoded SHA256
fingerprints as well, though?

That still doesn't explain why ecdsa 384 keys are mis-fingerprinted, though.

This is still a problem with 2.1.8

Which version of Libgcrypt are you using. (gpg --version shows it)

libgcrypt-config --version
1.6.4

When did you create your GPG key of ed25519?
Or... did you register your SSH key by ssh-add?

The ssh key was generated by "ssh-keygen -t ed25519" and added by ssh-add.

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

I change from:

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

to:

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

then 'ssh-add -L', and get
The agent has no identities.

It seems not working for me. By the way, I switch to 2.1.7 version which
doesn't have this problem.

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.

Nope. Search for the original discussion on the debian bug tracker. We
introduced this option just for one Debian user and it shall in general not be
used. Thus who feel that they need a longer key should anywa switch to ecc.

That is interesting.
Which version of Libgcrypt are you using. (gpg --version shows it)

Sorry, I don't known about mintty. Cygwin is actually a different OS on top of
Windows and can't fully integrate with native Windows applications like gnupg.

Tahnks for testing

yes, this was fixed in 2.1.8

Please put

verbose
debug ipc
log-file FOO

into dirmngr.conf and try with 2.1.7. Make sure to shutdown running dirmngr
processes before testing.

Duplicate of T2000

This was causing some other problems so it got treated as a bug in T2000 it
is fixed in the latest 2.0 and 2.1 releases.

AFAIK, this is a bug in oner version of the OSX toolchain. Others have shown
that it is possible to build the vanilla tarball on OSX. If your problem
persists, please search the gnupg-users mailing lits and ask there for help.

Is that okay or are concerned about keys with passphrsses generated on slower
boxes - they would indeed be checked faster than 100ms. Using gpg --passwd for
such keys adjusts the iteration count so that they will again be delayed by
about 100ms.

gpg-agent has a --allow-emacs-pinentry option which should solve dkg's concerns
of unintended use of the emapcs pinebtry feature.

Thus I change your request for a generic method to pass options to pinentry to a
feature request.

Solution (c) will be used for 2.1.8.

Won't fix in 1.4 because that version is mostly useful on old systems and those
don't have proper utf-8 supoort anyway.

There is a bug in Libgcrypt < 1.6.4 causing a bus error in the AESNI code.
The 2.1.8 installer will come with a fixed libgcrypt.

Fix released with 2.0.29.

Which libassuan version are you using?
libassuan-config --version
should show it.

2.0.29 has been released.

Sorry, I missed that for 2.0.29

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

backport for 2.0 commited. Thanks.

This should be something similar to gpg --always-trust

I tried your commands but i get the following error (both commands):
"keydb_get_cert failed_ Falscher BLOB-Typ"

I tried it with using a new certificate and using a previous versions of gnupg.

This is on purpose. By looking at all kind of different places you would get
whatever version is installed there and run into trouble figuring out how to
update it. Thus if your gpg-error is installed at a different place you should use

  ./configure --with-gpg-error-prefix=/usr

to tell configure to use the system provide libgpg-error. In general it is
better to use the latest libgpg-error, though.

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

Based on aheinecke's comments I'm closing this.

I just try the git version, use the autogen.sh to generate the ./configure
script. But, the configure sript failed to execute with error related to LIBGNUTLS.
So my issue is only with the downloadable version of the archives.

Applied in 60bc5186.