What is the current status of this issue?

It could have been discussed whether this makes sense. However, we can't change it anymore because it would change the behaviour. Consider a cron job which looks into a directory with keyids and imports them from a keyserver. It is totally fine if the script returns success if no keys are available.

In case if someone finds it through a search:

The solution seems to be a newer libccid version. If that is the case we may want to include the fix also in our own ccid driver.

Got this from my card vendor. Sonoma had a buggy CCID driver; compile one yourself and the bug's gone: https://forums.developer.apple.com/forums/thread/732091?answerId=768462022#768462022

For various reasons dirmngr requires and implements a full resolver and implements that. This way all DNS queries are passed through Tor. Thus this is a feature and not a bug. The error message could be better but we can only return what SOCKS tells us.

That's right: -K is merely a -k which prints only keys which have at least one secret key or a stub key (for smartcards) available.

Funny error description from macOS. Looks that there is no device - your PC/SC test programs confirms this. Thus I don't think this is a bug in scdaemon.

Sure it does not. That is the whole point of the loopback thing.

GnuPG is and can't be FIPS-140-3 compliant due to the way it is implemented. We may eventually employ the new hash-and-sign API of Libgcrypt to move into this direction but that has not yet been done. However, this also requires the use of the new indicator API and the, well, a RedHat kernel.

--openpgp means the current OpenPGP standard as implemented by GnuPG. This was important in the first few years of OpenPGP but not anymore today. The option --rfc4880 might be what you want. Please keep also in mind that the preference list declares what a concrete implementation supports and not necessary what's in an RFC.

Hi @werner,
I understand we should use --with-libksba-prefix, but it doesn't work:

That is not a bug but required for backward compatibility. See me/ksba.m4:

I never made a threat model. But definitely *any* cracker, should be out of my system, either from governmental agencies or from a kiddo in Russia.
I know that I have someone that is remote accessing my machine, since I got some tells. And that this cracker have used my Emacs text editor.

Smartcard PINs are different from passphrase for on-disk keys. Once a PIN is entered the smartcard is unlocked as long as it is powered up. In theory we could power down and power up the card to lock it. The question here is what is your threat model? If you have malware on your system it could simply brick your token or, more common, peek at your PIN.

I guess this is the first time such a key was reported. Printing diagnostics would be a bit of work because the code to compute th. expiration time is deep in gpg's guts.

The first signature is a direct key signature (class 0x1f) and this determines the expiration time. The usual case is to have the expiration time in the user id signatures. Our code does not allow to chnage the expiration time of direct key signature. This is because direct key signature are used by PGP and GnuPG only to add designated revokers. Gpg has no means to create a direct key signature like you have in your key.

@MathiasMagnus This change is to support Win32-OpenSSH by gpg-agent emulation of ssh-agent; You can use gpg-agent emulation of ssh-agent when you use Win32-OpenSSH. That is, you can use GPG auth subkey for Win32-OpenSSH.

@gniibe Am I misunderstanding something? I thought that with this change one is able to connect from a Windows box to a Linux box and have GPG agent forwarding work. I am still hitting pretty much the same issue described here: https://github.com/PowerShell/Win32-OpenSSH/issues/1564
On my Windows endpoint I'm running gpg.exe version 2.4.0.49237 and in C:\Users\mate\AppData\Roaming\gnupg\gpg-agent.conf I have a single line enable-win32-openssh-support. Running gpg-connect-agent.exe reloadagent /bye I have a gpg-agent running. Get-Process gpg-agent shows that it's running. In my Windows env I have SSH_AUTH_SOCK set to \\.\pipe\openssh-ssh-agent and my Linux endpoint is configured in SSH config with

ForwardAgent yes
AddKeysToAgent yes
RemoteForward /run/user/1015/gnupg/S.gpg-agent C\:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra

As the remote end reports /run/user/1015/gnupg/S.gpg-agent that socket for agent-socket when issuing gpgconf --list-dirs and my local gpgconfg.exe --list-dirs reports C%3a\Users\mate\AppData\Local\gnupg\S.gpg-agent.extra where I transform %3a to \: manually. SSH authentication works perfectly, when connecting pinentry-qt pops up to unlock my key and when connecting to yet another machine, my SSH agent is forwarded again. However, gpg fails to use my agent. Issuing gpg --list-secret-keys --verbose prints the following to the console:

gpg --list-secret-keys --verbose
gpg: using pgp trust model
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
gpg: no running gpg-agent - starting '/usr/bin/gpg-agent'
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
gpg: waiting for the agent to come up ... (5s)
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
gpg: waiting for the agent to come up ... (4s)
gpg: waiting for the agent to come up ... (3s)
gpg: waiting for the agent to come up ... (2s)
gpg: waiting for the agent to come up ... (1s)
gpg: can't connect to the agent: End of file

What is missing to tie the knot on both ends without having to resort to 3rd party tools like @rupor-github 's agent-gui? The remote gpg version is 2.2.19, is that the issue? Must that also be 2.3.9+?

I can't see what we shall do here.

Yes I do understand Windows XP is not supported. Just in case it is a minor problem that is easy to fix and will not cost you much effort. I'd like to add more information: I do not change
%LOCALAPPDATA%. There is no such environment variable. A similar environment variable is:
APPDATA=C:\Documents and Settings\myname\Application Data
I do set GNUPGHOME=E:\key, which I think should be allowed because I do not want my personal info be stored in system drive.

This is a support question and not a bug. You should ask such questions on the channels for Gpg4win, which does the Community support for GnuPG on Windows: https://www.gpg4win.org/community.html

To clarify that I meant that the underlying problem is our current keylisting speed in Kleopatra I have opened T6206.

In T6195#163175, @werner wrote:

keyboxd has nothing to do with this, it merely makes the lookup of keys a bit faster. The computation of the WoT itself takes long and there is no shortcut for it. Fortunately most users don't have a deeply meshed WoT with dedicated revokers etc., thus for them things are fast in the standard configuration.

keyboxd has nothing to do with this, it merely makes the lookup of keys a bit faster. The computation of the WoT itself takes long and there is no shortcut for it. Fortunately most users don't have a deeply meshed WoT with dedicated revokers etc., thus for them things are fast in the standard configuration.

I agree. We have to get rid of auto check trustdb and such stuff. I always found that impossible to program around because it either takes a long time (check-trustdb) or it might return invalid results (no check).
The solution for this is keyboxd.

If you run gpg --export-ownertrust you will notice that the trust has been set to ultimate (value is 6). However, due to the no-auto-check-trustdb in your gpg.conf that will valeu will only be shown after running gpg --check-trustdb. The value shown in the key listing is the computed value and the computation is done by --check-trustdb. I don't see a bug here.

Standard behaviour for stdio functions.

You get this error because the key has been created in gnupg mode (and not in de-vs) and thus it has these preferences.

Reading through the report, the spec., and current implementation, I concluded that this is not a bug, thus, I'm closing this.

You deleted the socket file but you did not restart the agent. Thus gpg can't contact the agent anymore. On Windows we use a socket emulation which requires the socket's file only for a new connection (to get the port and magic cookie).

Excuse me you are right of course. man gpgconf | grep quot says it all.

man gpg | grep quote nor man gpgconf | grep quote does not tell anything about it. I recognized the single opening quote of "string at post processing the output of gpgconf --list-options to generate a gpgconf.conf template. I just expected a closing quote for "string".

vitusb: We had this discussion on cryptography@ years ago. No need to start it again - or well, try it over there. This is a bug tracker and not a discussion forum.

These curves are not the default in the compliance mode "gnupg" only if you explicitly switch to the BSI defined "VS-NfD" mode they become default.

Nope. The double quote indicates a string. See the man page.

In T5783#153879, @werner wrote:

Sending a private key with just the local protection is not a good idea.

In T5784#153872, @werner wrote:

Please no holy wars on the type of curves. NIST as its opinon, Europe has its opinion, DJB has of course a different opinion. Please use the the cryptography ML for such political/technical discussions.

Sending a private key with just the local protection is not a good idea. It is better to export the key and then send it in an encrypted mail - for example in symmetric mode with a strong password.

Please no holy wars on the type of curves. NIST as its opinon, Europe has its opinion, DJB has of course a different opinion. Please use the the cryptography ML for such political/technical discussions.

That is a security feature of WIndows. We can't do much about it except for bad hacks. Checkout Kleopatra to see how you can improve this.

The first is a warning and the other error codes are exactly what we want.

Not a bug but a limitation of 2.2's option listing: In contrast to 2.3 we can't *show* the used options via gpgconf correcly if there is a conflict between global and local options. However, the actually *used* values are different and correct according to the config. In particular a global forced option overrides any local or command line option.

Just adding this note because a next step I'm also evaluating in my current T5593 configuration status it to temporarily create a new Gpg4win 3.1.16 hybrid configuration by also adding latest GnuPG v2.2.31 to see if all issues I reported here are still present (which is also quite probable).
Also because of T5593 it would just be quite interesting to see if GnuPG v2.2.31 too might experience same T5593 path related error.

Hi Werner,

Sure they don't get created - they are optional.

Just tracking my own additional investigation still about past Werner statement "percent escaping is correct and required" when this bug was closed for 1st time.
Also found interesting past references into rG055f8854d3f4 and rGe064c75b08a5 but only this last seems indeed much more specifically directly involved since it really contains related part of code (common/stringhelp.c) directly involved with this bug report for 'percent escaping' ':' (colon) character with '%3a' string even if sometimes, when possibly un-needlingly done, may even provide users unexpected on-screen displayed results like those I documented in this bug.
Problem now is that to really fully understand why on-screen displayed strings by 'gpgconf --list-dirs' correctly show a ':' (colon) correctly expected character near an unexpected (by end users) '%3a' (percent escaped) string that should just have corresponded with another simple (& user correctly expected) ':' colon character I can only really see to 2 options:
A) reopening this bug once again :-S ;
B) simply opening a new separate one asking for some additional explanations and maybe even to consider some future slight code changes to (at least for Windows OSes) ensure 'gpgconf --list-dirs' directory displayed paths results are more UI consistent with 'gpgconf --list-dirs homedir' or 'gpgconf --list-dirs sysconfdir' displayed ones where displayed C:\... paths always correctly display ':' (colon) instead of '%3a'.
So far this last seems me best viable option also because in same rGe064c75b08a5 I also saw another piece of code (tools/gpgconf-comp.c) with some similar code lines, that apparently (it seems me) if directly referenced (at least only for Windows OSes only, so maybe when a system variable %OS%==Windows_NT exists) instead of current one (common/stringhelp.c) also providing '%3a' 'percent escaping' results, might then have probably also easily avoided '%3a' user unexpected on-screen displayed results only depending by 'percent escaping'.

Just adding this note for any future reference needs only (or even message localization reference, since involved text characters strings are also expected to be among Italian language localized messages even if involved strings are not specifically being localized).

Hello Werner,

That's correct - The output needs to be percent escaped.

wk at gnupg dot org but better avoid any HTML parts etc.

Thank you, this is my great honor!
If it is convenient, can you provide an email address? So that I can elaborate to you.

Thanks. I added it to the list. If you have not yet done this I would suggest to write a note to gnupg-users.

The surprising thing is that it works at all. I wouldn't be surprised if certain would simply reject it as "not a pdf" given that the "%PDF-1.x" marker isn't at the beginning.

--clearsign may only be used for plain text documents due to line ending conversion etc.

See the release notes for GnuPG 2.2.17 (T4606 first item). You need to import your peer's signature from a different source; e.g. ask them to send you your signed key by mail.

The log file specified in .gnupg/dirmngr.conf is created at the start of dirmngr.
dirmngr is invokded by the first call of gpg, and it keeps running and handle next request from second invocation of gpg.
So, nothing is problem.

You used custom options which did not pick up the proper libksba. Install libksba correctly then try again. Please direct further questions to the mailing list and please build the latest version 2.2.23 and not an arbitrary old version.

The CRL states how long it is valid and we cache it for about that time.
OCSP responses are by definition not cachable but we allow for a clock skew of 10 minutes.

OpenPGP (RFC-4880) requires support for 3DES and SHA-1 thus you can't disable them. However, they are not used in practice because the key preference guarantee the use of more modern algorithms,

Iyou look at the key on the command line (or with Kleopatra's certificate manager), for example by using "gpg --list-key foo@bar.com" or by applying the command "gpg --show-keys" on the pasted keyblock you get this:

I don't see any error here. There is a trailing LF on the binary data which gpg rightfully complains about.

Thanks for the patch, applied!
You are correct the NEWS file states that this was added in 1.9.0