Pushed rM7b5182f28893
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Dec 8 2017
I've been running gnupg-w32-2.2.3_20171207.exe for about as long as it's been available and no hanging whatsoever. Thanks a lot!
Thank you for your cooperation.
This ticket can be closed. No further issue with email decryption after applying the provided patch
Dec 7 2017
I still have trouble beliving it is the reader. Since I tried now 3.
As well I have a 4096 bit key and everybody has been encrypting this with my key. Therefore it does not make sense to me.
Could we please merge it to the stable branch (2.2.3 does not have this patch yet) or it is not tested enough? Existing subkey sellection strategy doesn't play well with mail signing and affects GPGTools/GPGMail users as well as any other users with multiple signing subkeys. Thanks!
Moving on, I will just look to make a stand along project for efl-pinentry interface. I withdraw my previous submission. Welcome to resume and move forward with Mike Blumenkrantz version. Thanks!
Frankly, I doubt that this belongs into gpgme.
Andre can you please apply this?
W/o a special tag in the commit there seems to be no way to mark a patch as applied.
All commited. I created a new installer gnupg-w32-2.2.3_20171207.exe which comes with the new libassuan 2.5.1 and the two required patches for gnupg.
Fixed at last.
Added it. For now it's pretty bare but already an improvement on the old (which only showed "class") and no indication if a signature was revoked.
Prio low, as I noticed that Kleopatra already had some code in there to merge a secret with a public key in a keylisting. This can be used for me.
I pushed this change with the addition of a doc entry and to protect against a not yet initialized socket interface.
I looked into it. The problem is that attachments are opened as "Read Only" so we can't change the message class or handle it ourself. Once opened there is no apparent way to change the message to read only. Only if the message containing the attachment is marked as modifyable:
I tried to reproduce this with current GpgOL and it just worked. Even if I connected Enigmail to Exchange (Outlook.com).
For Gemalto USB Shell Token V2, libccid has known issue: https://ludovicrousseau.blogspot.jp/2017/03/gemalto-idbridge-k30-k50-ct30-and-zero.html
I don't know about ACR 38U.
Dec 6 2017
I experience this same behavior, standard shell. Both with admin, windows live based account and local, non-admin account.
Here two other Reader example - same message - same problem:
Reader: Gemalto USB Shell Token V2 (00483E73) 00 00
Reader: ACS ACR 38U-CCID 00 00
With Gpg4win 3.0 we registered associations for S/MIME and OpenPGP Files:
I just tested with intevation's CA on Windows and it works. It also worked with our test.ca in the base test before the 3.0.1 release. I think this is resolved.
We now check for an error of the gnupg-w32 installation (which should not happen normally) and show a Message Box on error.
It's also fixed. There was a problem with the error handing. A canceled pinentry is communicated as an error with code operation canceled.
In T3577#107074, @aheinecke wrote:So if the user had a "real" error it might have crashed instead of showing the error.
As a note: The second crash might be related in that the crash could happen on any error. So if the user had a "real" error it might have crashed instead of showing the error.
Indeed easily reproducible issue.
Applied to libassuan master.
Thanks for testing.
I created another patch which can be applied independently: D457: Avoid crash using nPth
Tested it on Windows, with the sleep test patch in Libassuan it does not hang anymore when it hanged without this change.
For better reproducibility of hang, this is more better:
It's a patch to libassuan. The patch to gpg-agent is not the exact one. libassuan patch is the exact one.
I'm doing the test. I'm currently waiting on a hang with the test change applied.
If you can get the developers to make a try-build that is built securely then I'd guess most of us would be happy to try it. Not all of us have a build system for gpg.
To reproduce this problem of nonce write->read race on Windows, and forgotten wrapping of read/write, please apply this patch for testing:
And then, please confirm that rG1524ba9656f0: agent: Set assuan system hooks before call of assuan_sock_init. can fix this, even with the patch for testing.
For Gemalto Shell Tokens: http://support.gemalto.com/index.php?id=tokens
There are three variants. Please describe detail.
I checked a card reader: https://pcsclite.alioth.debian.org/ccid/readers/CardMan3121.txt
We had similar report back in 2015, but it was not fixed in GnuPG (possibly, card reader problem):
https://lists.gnupg.org/pipermail/gnupg-users/2015-September/thread.html#54345