Today
Yesterday
We got new suggestions for this:
please check if this is still an issue
Tue, Sep 16
I found and fixed a bug (likely a regression in the new code): When CN_prefill or EMAIL_prefill is configured as true and no fixed CN or EMAIL is configured then Kleopatra should prefill Name and Email with values taken from CONFIGDIR/emaildefaults (used by KDE apps on Linux), from the Windows user or from the EMAIL environment variable. This didn't work anymore.
Backported to 2.2 but not yes tested with 2.2
I used the GPGME function gpgme_op_assuan_transact_ext with an query string like this:
ad_query --subst --attr=dn,userAccountControl (&(objectcategory=person)(objectclass=user) (|(userPrincipalName={{email}}) (mail={{email}})))
Of course {{email}} must be replaced with the mail address queried, this might probably also be the login name.
Can you please repeat this with gpg4win-5-beta using the keyboxd and also using the pubring.kbx (i.e. w/o use-keyboxd in common.conf)?
Sorry, I don't know Fedora packaging details. Please ask on gnupg-users for help if you want to build gpa yourself on that platform. This bug report is only read by very few people but on gnupg-users you can get the attention of several thousand users and developers.
Meanwhile we notice this also with OpenPGP Mails. This needs to be further investigated.
Mon, Sep 15
There was
We'll keep it as it is, for the improvement see T7814
[...]
X509v3 Key Usage: critical Key Encipherment, Data Encipherment
Updated the task description after talking with @ikloecker
I don't see how this could happen unless you have canceled an export. In this case Kleopatra saved an empty path as last location and then on the next export Kleopatra proposed Documents. The latest changes prevent Kleopatra from saving an empty path as last location and they ensure that Kleopatra immediately writes [Export]LastDirectory to disk.
Sun, Sep 14
Your first two issues are no issues. This is just usual output from a configure run.
Sat, Sep 13
Fri, Sep 12
Sorry, I just found out, that windows caps the filename earlier than max length, so my former tests were invalid.
All mails touched by gpgol should already have a GPGOL_UID_DASL. So to replicate:
- Send a new encrypted mail (e.g. Edward -> Ted)
- Don't open that mail, but open the context menu: Move -> Other Folder ...
- Select a subfolder of INBOX and click OK -> the mail is not moved
fix tested and confirmed with GnuPG 2.5.12 on windows 10
Thu, Sep 11
Looks good to me on gpg4win-5.0.0-beta369 @ win10
Wed, Sep 10
Tested with VS-Desktop-3.3.90.8-Beta and the test gpgol.dll from 2025-09-10 and the same test mail from the original report:
The spawning does not occur any more. (Tested with Outlook setting "show as text only" and without.)