Recall that each user has their own keys and configuration. This seems to be a general question on how to use GpgOL. Please use the help resources listed at gpg4win.org instead of this bug tracker.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Nov 27 2020
Nov 26 2020
You are right, the new 3.4 cards support brainpool curves in addition to the nist curves.
Sorry, I realized this myself this morning and did couple of fixes. rG7113263a00d8 does this all however I forgot to mention the bug number.
Nov 25 2020
Nov 24 2020
Okay, I now got such a patch:
I found a good enough solution: I changed the code to compute the OpenPGP s/n from the Yubikey s/n right after a Yubikey has been detected. Later, and if OpenPGP enabled on the YK, the S/N is already there but we use the S/N from the 0x4f DO. That is needed because we can't compute the OpenPGP version number ahead and use 0.0 in the S/N.
Nov 23 2020
Released on 2020-11-18
Note that if you run into problems with a smartcard you should run "gpg --card-status" once. GUI frontends usually do that and this is the reason why this regression was not detected. Will be fixed in 2.2.25 (T5140).
Removing 2.2 tag because it has been fixed in one of the last releases.
Its done for 2.2 thus changing the tag.
Thanks.
Before step 2.d you should stop gpg-agent and other daemon
This was fixed in 2.2.24 with commit rG7f765a98fd662
If you want to debug this, I suggest to use a logging socket. Put into all gpg-agent.conf files these lines:
I though about this too but we need to take care about the logging functions of Libgcrypt which are intertwined with nPth (clamp function of libgpg-error).
Nov 22 2020
Nov 20 2020
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
Nov 19 2020
Urgs, that was my fault.
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.
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.
Nov 17 2020
A 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.
Nov 16 2020
Nov 15 2020
I know these troubles.