Thanks. I added it to the list. If you have not yet done this I would suggest to write a note to gnupg-users.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jun 25 2021
We need to see how to best fix this regression test for all Python versions.
We should not support a different OID or representation of 22519 which will only lead to incompatibilities and trouble existing users. 25519 is in too widespread use than to allow for any changes.
FWIW: We have always refused to support shared mode because we anticipated such problems. However, we have a customer using their own cards along with card maintenance software of them. For their purposes PCSC_SHARED works just fine makes and this is why I decided to add --pcsc-shared along with a warning that it is in general not a good idea.
You need to protect only 2 critical set of ADPU sequence Sign and Decrypt. All other can be done not safely and have a minor impact. Get generation and cards unlock can be profitable with the transaction mode... but is very rare user makes another use of the card in same time he start that’s command. The check external interference can protect from a bad start. I have started this ticket because my card suffer in exclusive mode render the use of openpgp not really usable. When my card is an pcsc-shared mode, all it's OK but the daemon not able to restore after external interference. The correction proposed is OK but I have made recommendations because this can cause a bad applet switch... if the state does not restore before trying to switch applet all it's OK. I am not actually able to set directly differential code but I have described in the patch the change I have made and this make my card very happy. Not problems and the pin was queried if another application makes interference.
There are multiple issues here.
Jun 24 2021
OK I have finally success to test... the master version has a problem with opening pcsc readers on windows I revert back on older version to able to correct this problem. For the current patch without yubikey reference. I suggest validating the interference in the first task for the maybe_switch app function.
Was released with 1.14.0 see T4996
Thanks werner. That helps us to know that such test failure is not a deep issue that would push us to not deliver this version of gnupg on AIX.
Jun 23 2021
For KDF setup (00F9), setting it to '' (null, to reset the DO) doesn't work, but it raises 6a80.
Once KDF is enabled, only factory-reset can reset the feature.
Jun 22 2021
So let's close this task.
Setting the gpg.program configuration value to "C:\\Program Files (x86)\\GnuPG\\bin\\gpg.exe" appears to resolve the issue.
It appears that Git ships with its own GnuPG program set, as can be seen in the attached image. I'll attempt to set the gpg.program setting in Git and see if that helps.
That looks all fine.
With the next release you will get only a warning:
gnupg-2.2/common/t-sexputil.c:467: test 0 failed: Unknown elliptic curve - ignored This is likely due to a patched version of Libgcrypt with removed support for Brainpool curves
The only download I have executed with regard to gpg4win is from the gpg4win website. You can see the output of the command you specified below.
may give you some clues.
You are not using gpg4win with its included GnuPG 2.2 but some broken gpg version. The error message
"invalid size of lockfile" can only be emitted by the Unix version of GnuPG. Check for other installed gpg versions - there are sites which allows the download of for example a Cygwin version - these version can't work properly on Windows.
I did some test on Windows 10 using gnupg 2.2 with this patch and things work.