- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Nov 19 2020
The problem seems to have returned in 2.2.24.
Urgs, that was my fault.
Thanks again for your report.
I'm still having problems with 2.2.24. Now the card removal is detected correctly, but the initialization fails.
Thanks. I understand the situation. Basically, gpg-agent's computation is done by a single thread (in current implementation), although it accepts many requests simultaneously.
Nov 18 2020
We had some card related regressions in 2.2.23. I would appreciate if you could first test again with 2.2.24 which was released yesterday.
I am sorry, but this is not a help desk but a bug tracker. See https://gpg4win.org or https://gnupg.org to find out which community support is available.
Resetting priority to normal for re-evaluation
Re-opening. Now trying to generate new keys fails with a "Wrong card" error.
In T5137#139066, @werner wrote:Note that you actually run 30 independent processes with gpg 1.4 but with gpg-agent there is just one process to handle the private key operations (decrypt). To utilize more cores you need to setup several GNUPGHOME with the same private keys.
In T5137#139064, @gniibe wrote:I think that it is not gpg-agent but pinentry which causes millions of futex syscall errors.
For interactive use case, pinentry may be the point of contention.
I might be wrong if your key is not protected by passphrase.If possible, please try adding arguments for gpg invocation: --pinentry-mode loopback --passphrase-file YOUR_FILE_FOR_PASSPHRASE
This can avoid the invocation of pinentry entirely.
Output of (unpatched) gpg with --debug ipc:
$ GNUPGHOME=$HOME/.cache/gnupg-master-home gpg --debug ipc --quick-gen-key --yes piv@example.net card gpg: reading options from '[cmdline]' gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: enabled debug flags: ipc gpg: DBG: chan_3 <- OK Pleased to meet you, process 7588 gpg: DBG: connection to the gpg-agent established gpg: DBG: chan_3 -> RESET gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> OPTION ttyname=/dev/pts/7 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> OPTION ttytype=xterm-256color gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> OPTION display=:0 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> OPTION xauthority=/home/ingo/.Xauthority gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> OPTION putenv=XMODIFIERS=@im=local gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> OPTION putenv=GTK_IM_MODULE=cedilla gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> OPTION putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> OPTION putenv=QT_IM_MODULE=xim gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> OPTION lc-ctype=de_DE.UTF-8 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> OPTION lc-messages=de_DE.UTF-8 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> GETINFO version gpg: DBG: chan_3 <- D 2.3.0-beta1481 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> OPTION allow-pinentry-notify gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> OPTION agent-awareness=2.1.0 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> SCD SERIALNO gpg: DBG: chan_3 <- S SERIALNO FF020001008A7796 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> SCD SERIALNO gpg: DBG: chan_3 <- S SERIALNO FF020001008A7796 gpg: DBG: chan_3 <- OK gpg: Serial number of the card: FF020001008A7796 gpg: DBG: chan_3 -> SCD LEARN --keypairinfo gpg: DBG: chan_3 <- S CHV-USAGE 40 00 gpg: DBG: chan_3 <- S CHV-STATUS -2 3 -2 gpg: DBG: chan_3 <- S KEYPAIRINFO EB6A99D61EF3BC7C7934173CD9833376D773E65D PIV.9A a gpg: DBG: chan_3 <- S KEYPAIRINFO 482BD076054B6950A6FC476C356AF029A5115BBD PIV.9E a gpg: DBG: chan_3 <- S KEYPAIRINFO 0773CFCB90C043F3A6151B3F2FBF23726F10A48A PIV.9C sc gpg: DBG: chan_3 <- S KEYPAIRINFO ED6579C1360100BE92C46ECB1A1826A63614D5AB PIV.9D e gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> SCD GETATTR $SIGNKEYID gpg: DBG: chan_3 <- S $SIGNKEYID PIV.9C gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> SCD READKEY --info -- PIV.9C gpg: DBG: chan_3 <- S KEYPAIRINFO 0773CFCB90C043F3A6151B3F2FBF23726F10A48A PIV.9C sc - nistp256 gpg: DBG: chan_3 <- [ 44 20 28 31 30 3a 70 75 62 6c 69 63 2d 6b 65 79 ...(118 byte(s) skipped) ] gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> SCD SERIALNO gpg: DBG: chan_3 <- S SERIALNO FF020001008A7796 gpg: DBG: chan_3 <- OK gpg: Serial number of the card: FF020001008A7796 gpg: DBG: chan_3 -> SCD LEARN --keypairinfo gpg: DBG: chan_3 <- S CHV-USAGE 40 00 gpg: DBG: chan_3 <- S CHV-STATUS -2 3 -2 gpg: DBG: chan_3 <- S KEYPAIRINFO EB6A99D61EF3BC7C7934173CD9833376D773E65D PIV.9A a gpg: DBG: chan_3 <- S KEYPAIRINFO 482BD076054B6950A6FC476C356AF029A5115BBD PIV.9E a gpg: DBG: chan_3 <- S KEYPAIRINFO 0773CFCB90C043F3A6151B3F2FBF23726F10A48A PIV.9C sc gpg: DBG: chan_3 <- S KEYPAIRINFO ED6579C1360100BE92C46ECB1A1826A63614D5AB PIV.9D e gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> SCD GETATTR $ENCRKEYID gpg: DBG: chan_3 <- S $ENCRKEYID PIV.9D gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> SCD READKEY --info -- PIV.9D gpg: DBG: chan_3 <- S KEYPAIRINFO ED6579C1360100BE92C46ECB1A1826A63614D5AB PIV.9D e - rsa2048 gpg: DBG: chan_3 <- [ 44 20 28 31 30 3a 70 75 62 6c 69 63 2d 6b 65 79 ...(286 byte(s) skipped) ] gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> RESET gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> READKEY -- 0773CFCB90C043F3A6151B3F2FBF23726F10A48A gpg: DBG: chan_3 <- ERR 67141713 No such file or directory <GPG Agent> Key generation failed: No such file or directory gpg: secmem usage: 0/32768 bytes in 0 blocks
Fixed. Workaround for gpgme 1.15 (and earlier) implemented in Kleopatra: Do not call setRemark() with an empty QString.
I think Kleopatra is affected. It calls setRemark() on the job unconditionally with the text from the widget, and I'm pretty sure that this text is empty but not a null QString, if the user doesn't enter a remark.
It was a bunch or work and we are still not able to pass Unicode strings on the command line. Will eventually be done. At least people in Asia can now use their regular Windows account with gpg.
Yes sure. --debug ipc should give you some insight why gpg does not thing the key is on the card.
Ingo, can you please check? I guess we are not affected because Kleo already checks for an empty string. But dkg's suggestion sounds good to me.
Thanks Werner! Seems like an important step!
Nov 17 2020
After patching the above mentioned if-clause the command fails on the first try, but it succeeds on the second try
$ gpgconf --kill allA fix has been released; see T5052.
I change this to a feature request: Allow several processes to run public key decryption using the same set of private keys.
Note that you actually run 30 independent processes with gpg 1.4 but with gpg-agent there is just one process to handle the private key operations (decrypt). To utilize more cores you need to setup several GNUPGHOME with the same private keys.