- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Nov 20 2020
The same problem occurs for NKS (v3) cards where the keys also do not have a keytime.
The above workaround may not be necessary because another code path sets the algorithm string as seen in
$ gpg-connect-agent "SCD READKEY --info -- NKS-NKS3.4531" /bye S KEYPAIRINFO 39400430E38BB96F105B740A7119FE113578B59D NKS-NKS3.4531 - - rsa2048
The following patch fixes the crash:
diff --git a/scd/app-nks.c b/scd/app-nks.c index 47be7cd85..4d925dccd 100644 --- a/scd/app-nks.c +++ b/scd/app-nks.c @@ -871,7 +871,7 @@ do_learn_status_core (app_t app, ctrl_t ctrl, unsigned int flags, id_buf, strlen (id_buf), usagebuf, strlen (usagebuf), "-", (size_t)1, - algostr, strlen (algostr), + algostr, algostr ? strlen (algostr) : (size_t)0, NULL, (size_t)0); } xfree (algostr);
Thanks, I was wrong.
Right, our installation really needs an update. It is not gnupg.org mail but just the mails from phabricator - which unfortunately does not use our standard mail system
Adding [algostr] in g10/call-agent.c is correct, but there is no [fprtime] (resp. it's already listed in the format as [keytime]).
How about distinguishing CARDNO and application specific SERIALNO?
Yes, it is due to a backport from master: rG1049f06c6d2e: scd:openpgp: Allow keygrip to be used to reference a key
Fixed in rG84020385be19: scd:openpgp: Public keys should be available for check_keyidstr..
Nov 19 2020
{F1982353}
You forgot to add lang/cpp/src/data.h.in
I looked the gpg-agent.log, it indeed suggested the problem fixed in rG61aea64b3c17: scd: Fix the use case of verify_chv2 by CHECKPIN., which is included in 2.2.24.
Building and installing 2.2.24 at least made it not crash, the very least it's an improvement in that respect.
You have multiple readers and using PC/SC by specifying reader-port.
We fixed in master by T4998: scdaemon: PC/SC "No such device" without reader-port, and I didn't know similar fixes should be backported.
I will soon.
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.