- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jun 25 2021
Thank you, this is my great honor!
If it is convenient, can you provide an email address? So that I can elaborate to you.
Needs to be tested with the current 2.2 version and a gcry_log_debugsxp should be added to the error output.
This will not be fixed. Brainpool is a standard feature of Libgcrypt and thus this is a bug in the used Libgcrypt installation. Note that although I recently fixed a new regression test for this case, I do not think that it is a good idea to add extra code for a broken Libgcrypt.
This has been solved in 2.2.26 commit rGc75fd75532
That might depend on your pinentry version. With a pre-1.1.1 pinentry and 2.2.28 I get this:
Will be in 2.2.29.
Thanks. I added it to the list. If you have not yet done this I would suggest to write a note to gnupg-users.
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.