We don't maintain a PHP wrapper. I'd recommend that you report this problem to
the maintainers of that package. When doing so, you'll probably want to include
the public key that you are trying to import and indicate what version of GnuPG
and the GnuPG PHP wrapper that you have installed.

gpg-agent caches symmetric keys and thus gpg needs to tell gpg-agent about it.

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.

If I create a key as follows, no expiry date is set:
$ gpg2 --faked-system-time 20100101T000000 --default-cert-expire 1y
--quick-gen-key 'Test Key <test@example.org>'

If I edit a key to add a new user ID under a faked system time as follows, the
new user ID does not receive the specified expiry date.
$ faketime 2010-01-01 gpg2 --homedir test --edit-key --default-sig-expire 2013-12-31

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.

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)

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

Confirmed that this issue is fixed with 2.1.8. I was able to delete the secret
key (stubs) and they were properly recreated.

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

Debian Unstable is now at 2.1.8-1. I guess this version should have the fix as
well? If yes, I can retry.

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.

Yes only on Windows. Works for me on GNU/Linux, too.

Only on Windows? A quick check on Unix shows that it works.

Thanks for reporting back and thanks to Neal for cleaning up the passphrase limits.

Please continue a discussion about KeePass at gnupg-users.

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.

backtrace without the arch patch, for RSA key

#0 ssh_identity_register (confirm=0, ttl=0, key=0x7ff366864800,
spec=0x7ff36577adb0, ctrl=0x14e0da0) at command-ssh.c:3112
#1 ssh_handler_add_identity (ctrl=0x14e0da0, request=<optimized out>,
response=0x7ff360004d20) at command-ssh.c:3247
#2 0x0000000000417948 in ssh_request_process (stream_sock=0x7ff3600009c0,
ctrl=0x14e0da0) at command-ssh.c:3513
#3 start_command_handler_ssh (ctrl=ctrl@entry=0x14e0da0, sock_client=<optimized
out>) at command-ssh.c:3619
#4 0x0000000000409c3b in start_connection_thread_ssh (arg=0x14e0da0) at
gpg-agent.c:2278
#5 0x00007ff365d3ee5c in ?? () from /usr/lib/libnpth.so.0
#6 0x00007ff365b274a4 in start_thread () from /usr/lib/libpthread.so.0
#7 0x00007ff36586513d in clone () from /usr/lib/libc.so.6

This patch was applied to the build

https://projects.archlinux.org/svntogit/packages.git/tree/trunk/ssh-ed25519.patch?h=packages/gnupg

Here is a gdb backtrace of the segfault

GNU gdb (GDB) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/gpg-agent...done.
[New LWP 7934]
[New LWP 7066]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/usr/bin/gpg-agent --daemon --debug-level 99
--enable-ssh-support --log-file /h'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 ssh_identity_register (confirm=0, ttl=0, key=0x7f9a398ee800,
spec=0x7f9a38804db0, ctrl=0x11fdda0) at command-ssh.c:3114
3114 command-ssh.c: No such file or directory.
[Current thread is 1 (Thread 0x7f9a38805700 (LWP 7934))]
(gdb) bt
#0 ssh_identity_register (confirm=0, ttl=0, key=0x7f9a398ee800,
spec=0x7f9a38804db0, ctrl=0x11fdda0) at command-ssh.c:3114
#1 ssh_handler_add_identity (ctrl=0x11fdda0, request=<optimized out>,
response=0x7f9a34004d20) at command-ssh.c:3249
#2 0x0000000000417948 in ssh_request_process (stream_sock=0x7f9a340009c0,
ctrl=0x11fdda0) at command-ssh.c:3515
#3 start_command_handler_ssh (ctrl=ctrl@entry=0x11fdda0, sock_client=<optimized
out>) at command-ssh.c:3621
#4 0x0000000000409c3b in start_connection_thread_ssh (arg=0x11fdda0) at
gpg-agent.c:2278
#5 0x00007f9a38dc8e5c in ?? () from /usr/lib/libnpth.so.0
#6 0x00007f9a38bb14a4 in start_thread () from /usr/lib/libpthread.so.0
#7 0x00007f9a388ef13d in clone () from /usr/lib/libc.so.6

It seems this is related to T2096 but the key in question here is rsa, not
ed25519. Downgrading to 2.1.7 worked for me as well.

You've actually added code to handle the hostname:port string with rev: 54e55149

But this does not work as the parse_uri check before hat is called with
"no_scheme_check" and so already passes a hostname:port uri as valid and does
not go into the fallback code that adds the http scheme.

D329: 685_0001-Dirmngr-Default-to-http-protocol-for-http-proxy.patch

I use several key of near all types: ed25519, rsa, dsa, ecdsa. All of them have
stopped working.

I laughed when I first read aheinecke's comments, at least right up until the
moment the gravity of the 'unmaintained upstream' hit me!

The Bug I filed on 22 July at: https://bugzilla.redhat.com/show_bug.cgi?id=1245732

has gone exactly nowhere, in a hurry, despite being assigned to Ngo Than.

In any event, another Fedora Forum user and I tracked down the root cause ourselves.

I can confirm this KGpg failure to autostart is *NOT* in any way related to GnuPG.

I have already documented how to cause, and how to avoid, this KGpg autostart
failure in this thread: http://forums.fedoraforum.org/showthread.php?t=305604

Hint: If you are interested, read page 2 of ^that thread first, for a summary,
and a reproducible testing procedure.

aheinecke: Kleopatra was, and is, a 'thing' of beauty! ;-3

Hi Werner,

Fixed in 2.1.8 INDEED!!

I know this to be true as the 'Passphrase too long' error still appears when
running gpg2 on a fully updated Fed 22 system. The latest GnuPG(2) package in
Fedora's repos is: gnupg2-2.1.7-1.fc22.x86_64. When that package is installed:

gpg2 --version

of course, reports: gpg (GnuPG) 2.1.7.

As I originally noted in this bug report, this 'Passphrase too long' error only
appears on my Fedora 22 systems. Therefore, Fed 22 is the operating system I
used to install the required libraries and then compile 2.1.8 from its source
code.

Following appropriate modifications to my ~/.bash_profile

gpg2 --version

now correctly reports: gpg (GnuPG) 2.1.8

Now when running TBird, Enigmail and Keepass2, gpg2 and pinetry-qt4 can now
accept very lengthy passphrases, flawlessly!

I don't know what the maximum passphrase insertion length limit is from a
Keepass2 Auto-Type perspective, but I am happy to report that GnuPG 2.1.8 can
easily handle Keepass2 generated passphrases significantly longer than 750 Bits.

Absolutely great work done here Werner!

Thank you very much Werner and Neal. I very much appreciate your sustained
attention to this now SOLVED matter.

BTW: If either of you have further input, or queries, on the passphrase entropy
topic, I would be happy to discuss these matters with Dominik Reichl who is the
developer behind Keepass - and all of it variants. I have contacted Dominik on
several Keepass issues. He is both highly intelligent and responsive.

Given that Keepass has a large user base across many operating systems, perhaps
a frank discussion, and optimization, of lengthy GnuPG passphrases in general
would be beneficial to a large population of security minded Windows and Linux
users.

Regardless of that, I find this is a regression. With my configuration I was
able to search on keyservers with 2.0.x and then with 2.1.x keyserver search no
longer works with the same configuration.

And it's probably easier to default to http protocol for a http-proxy in gnupg /
dirmngr again then it is for me to warn users in Kleopatra / Gpg4win that their
configuration no longer works with 2.1.

Duplicate of T2096

Are you using an Ed25519 key? There was a regression in 2.1.8 which has
meanwhile be fixed in the repo. See also T2096.

Actually I plan to remove (or make them a NOP) all network options from
gpg.conf. This should all be configured in dirmngr.conf.

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

I degrade this to a minor bug because gpg knows about this:

  gpg: WARNING: multiple signatures detected.  Only the first will be checked.

See this comment:
/* We can't currently handle multiple signatures of

different classes or digests (we'd pretty much have
to run a different hash context for each), but if
they are all the same, make an exception. */

Fixed in 2.1.8.

Thanks. I'm very happy with gnupg 2.1.

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.