Mon, May 15
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.
Tue, May 9
Apr 12 2023
Mar 15 2023
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:
Mar 14 2023
Mar 13 2023
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.
Feb 14 2023
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.
Feb 1 2023
@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.
Jan 31 2023
@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+?
Dec 22 2022
Oct 28 2022
I can't see what we shall do here.
Sep 22 2022
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.
Sep 21 2022
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
Sep 15 2022
To clarify that I meant that the underlying problem is our current keylisting speed in Kleopatra I have opened T6206.
Sep 14 2022
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.
Sep 3 2022
Sep 2 2022
Standard behaviour for stdio functions.
Aug 25 2022
You get this error because the key has been created in gnupg mode (and not in de-vs) and thus it has these preferences.
Jul 13 2022
Reading through the report, the spec., and current implementation, I concluded that this is not a bug, thus, I'm closing this.
Jun 16 2022
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).
Mar 16 2022
Feb 25 2022
Feb 23 2022
Feb 14 2022
Jan 18 2022
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.
Jan 17 2022
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.
Dec 21 2021
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.
Dec 10 2021
The first is a warning and the other error codes are exactly what we want.
Nov 25 2021
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.
Oct 14 2021
Oct 13 2021
Oct 12 2021
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.