- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 17 2018
Indeed with debug dns I can see that what takes so long is the resolve_dns_name. After the debug output prints that line the key comes nearly instant.
The fix was released with Gpg4win-3.0.3
The default Pinentry for Windows is pinentry-qt it should both be accessible with descriptions and screenreader API support and it should allow you to paste in passphrases. The passphrase length is limited at 255 characters. This limitation comes from GnuPG and is there both for Windows and Linux. Have you tested Pinentry-qt with a screenreader?
as your behavior is unusual please verify that no other Addons interfere, we are still trying to figure out if there are incompatible other addons. So please try to disable any other addons and try again.
Jan 15 2018
Gpg4win-3.0.3 has been released.
No more reports of this since 3.0.2. With 3.0.3 I fixed an additional memleak which should further improve this. Resolved for now.
For the 3.0.3 I tested more with Microsoft Exchange Online, an Exchange 2012 Server and could not reproduce such problems. So I'm lowering the priority to normal as I don't think many users are affected.
Jan 12 2018
Multiple confirmations -> Resolved.
With git bisect I tracked it down to a0326ffb755c4a49a259cea3d83831d9ede7d5d9
Duplicate of T3576
System locale : de-CH
GpgOL should use the same language detection code that GnuPG also uses. If you open a command line (cmd) and run "gpg" in that command line is it also in german?
Jan 11 2018
I've noticed that myself and the cause for this is the code which we use to ensure that the key resolution dialog of Kleopatra opens in the foreground.
Thanks again for the test, your patience and the report :-)
Ok so I found out that you could even trigger this bug without persistent options just by activating and deactivating any S/MIME option on a mail. This somehow changed the behavior of Outlook.
But that's it.
With these Options set and explicitly unchecking Sign & Encrypt before sending I get the exact same behavior that you two describe. Mails are sent unencrypted.
In T3656#109394, @Mak wrote:Ahh, and yes I use a public personal s/mime cert to sign my mails. nothing else.
Another question: Any outgoing Filters (Email Rules)?
@JHohmann Your log is similar in that I can see two Write events after the send of which there should only be one. Somehow we seem to do crypto on a copy mail object and another mail is acutally sent.
Any chance that I could get a temporary test account on your Server?
Jan 10 2018
We now have update handling in the installer and this is the first thing the update handling fixes.
I understand now that README's for other languages are installed as aliases and added some missing ones.
For T3662 (PGP/Inline problem with Microsoft Exchange Online) I had to change the code used to send PGP/Inline.
I've changed the behavior now so that PGP/Inline also works with Exchange Online.
In T3656#109246, @Mak wrote:I sent it to a user on a different Mailserver. On my setup its nothing special... Win 10 Enterprise N en, Office 365 Pro Plus en, Kaspersky Internet Security. Server Win 2012 R2 with Exchange Server 2013 and GFI Mailessentials.
I don't think there is anything special... :-(
The status is now shown and updated.
No longer blocks with that commit. Keylistjob is started in the background. As long as the keylistjob is running the validity is shown as "Updating..."
This is not with 2.0 but with 2.2.3 / current master.