- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 6 2020
@bzbue1 Thanks for the info.
Yes. We want to move away from the edit interface as much as possible. It's very fragile and broke a lot in the past when --edit-key emitted different status lines and the state machine did not work anymore.
Aug 5 2020
Aug 4 2020
Aug 3 2020
Jul 31 2020
Jul 29 2020
That patch fixes the build problem I got into today when trying to build 2.3 for windows. So ? from me and please commit the patch as it is already required when assuan and gpgrt config no longer emit ws2_32 in their pgk-config --libs line.
I just saw that there is related discussion and a patch for this in T4994 so I will close again here.
to give you any help I would need to know the exact error. I can only tell you that this is not a problem related to Gpg4win something else must be messy on your system. The Uninstaller of Gpg4win cleans up all registry keys that do not contain user config and all files should be removed unless some other process on the system interferes.
This change broke for me the compilation of GPGME which I fixed with: 52f930c1ed7eee6336a41598c90ef3605b7ed02b I found that fix there OK because GPGME explicitly uses ws2_32.
Jul 27 2020
Phabricator allows it again to upload patches. It's D507
In Kleopatra/src/dialogs/subkeyswidget.cpp there is already a context menu for subkeys.
Still an issue, just noticed that with the 3.1.12 release announcement, it really looks ugly.
Jul 24 2020
Jul 23 2020
Jul 22 2020
Jul 21 2020
Jul 20 2020
Jul 17 2020
Jul 16 2020
Hi, yeah its complicated for Kleopatra to detect the defaults as they can be set both in Kleopatra config and GnuPG config. The GnuPG config overrides the Kleopatra config. Kleo has code to handle this but not when it adds the comboboxes to the GUI. So I've just removed the "default". We only had this for RSA and DSA / Elgamal, for ECC we did not indicate the default.
Jul 14 2020
I can reproduce the issue. GpgOL creates a temporary file using the original filename and that fails because the pipe is one of the invalid filename characters on Windows / NTFS.
After digging through our complete parser code it turns out that we did everything correctly but Outlook adds the line break when we change the bodyformat from HTML to plain text. So this issue only existed since the fix for: T4639
Jul 13 2020
It's not only for URL's. I've tested with any long line when sending "text/plain" GpgOL properly sends this but displays it wrongly.