Thanks for your patience.
I think I identified an issue in your debug log. Not yet catch the bug,
though.
The problem is caching passphrase by libsecret using
gnome-keyring-daemon. I believe that possible workaround is having
"no-allow-external-cache" in your .gnupg/gpg-agent.conf.
Let me explain, following the log...
> 2019/01/24 12:02:47.157702 length=37 from=15 to=51
OPTION allow-external-password-cache
< 2019/01/24 12:02:47.157773 length=3 from=40 to=42
OK
Here, gpg-agent sets allow-external-password-cache option.
> 2019/01/24 12:02:47.159062 length=54 from=536 to=589
SETKEYINFO s/A337DE390143074C6DBFEA64224359B9859B02FC
< 2019/01/24 12:02:47.159127 length=3 from=193 to=195
OK
Here, gpg-agent informs pinentry for keyinfo (it works as cache
identifier). "s/" stands for SSH, and A3...FC is the keygrip.
And then, GETPIN is issued from gpg-agent, (I think) pinentry must
examine the cache by the function
secret_password_lookup_nonpageable_sync in libsecret.
> 2019/01/24 12:02:47.159342 length=7 from=723 to=729
GETPIN
< 2019/01/24 12:02:47.175799 length=25 from=202 to=226
S PASSWORD_FROM_CACHE
OK
This means cache hits, and passphrase is "" (empty). This is wrong.
I guess, for some unknow reason, secret_password_lookup_nonpageable_sync
seems to return "", where NULL is expected (because of no cache hit).
Something is going wrong in libsecret, it is related to gnome-keyring
service.
In GNOME Desktop, it is gnome-keyring-daemon which handles secret store.
Please check your gnome-keyring-daemon is running correctly. It's in
gnome-keyring package.
You are using gpg-agent as ssh-agent. Please don't activate
gnome-keyring-daemon's feature as ssh-agent.
--
