Marking this as resolved as it was forgotten in the testing state.

I think this is resolved by kleopatra's watchdog. There is a bug that the agent becomes unresponsive somehow then the loading also hangs but this is unrelated to kleopatra.

Sorry I did not see your first comment.

I would change gpgme_addrspec_from_uid and the gnupg equivalent to strip out the subaddress.

It does not make sense to handle this in the protocol. The client should always ask for joe@example.org and thus keep the whole thing mostly out of gpg. This requires that keys are not created with sub-addresses. However, if someone has a need for this, this strategy should work:

First let me say that it is never a good Idea to use outdated / unmaintained security software. PGP Messages are external input and you pass that to unmaintained software.

I've added two message handling routines and a small program to test it (run-messenger.cpp) You can use run-messenger.cpp for reference.

To reproduce it the key is to close Outlook through the file -> close option.

Fair enough. Let's wait and see what others think.

Also consider that it is possible to change the key usage flags. Thus it will never be clear whether one has a fixed or unfixed public key. I'd like to close this bug because it is currently also discussed in the IETF WG.

In the log I can see where it uses a non default codepath:

I don't think this answered my question -- i'm asking how adding --no-keyring affects gpgme_op_decrypt_verify -- it seems like verification would fail if no keyring is used, no?

gpgme_op_decrypt_verify can always be used instead of gpgme_op_decrypt. This is an obvious requirement because the signature and the fact that there is a signature is only known after the decryption step. The newer GPGME_DECRYPT_VERIFY of the gpgme_op_decrypt_ext function is basically an alias for gpgme_op_decrypt_verify.
For both functions gpgme employs "gpg --decrypt".

I'm fine with this change, but i do note that some people expect --decrypt to mean "decrypt and verify, if possible". In particular, gpg(1) says about --decrypt:

So far, so good.

Hi sorry, here it is. I don't see a recommended way for providing a ton of text, so just pasting it here.

The dirmngr may at any time open a file in that directory and thus there is no reliable way to remove the home directory when any gpg tool is running. Daemons need to be stopped before a directory can be deleted. So I think this is a non-issue and brought to the table only because we have that kludge of detecting a n unlinked directory on Unix. But even on Unix this is not possible to get rid of the home directory, for example if you want to umount it.

Using intptr_t works with this particular case but it does not
solve the general problem under Windows. On Windows an integer
may identify a libc file handle, a socket, and some other
objects. Despite that they are integers they are all different objects
and it is hard to distinguish them

Ok. Thank you for sharing informations!

Yep, I can access this property.

I think that it's good to rewrite enum_secret_keys in g10/skclist.c.

The bug is gone by rG79f165d7a8bc: gpg: Make --skip-hidden-recipients work again..

Please provide a complete build log or at least the output of the configure run.

Sorry, it didn't made it into 2.2.11.

I guess we can close that, right?

Released: https://lists.gnupg.org/pipermail/gnupg-announce/2018q4/000432.html

• gpgsm: Fix CRL loading when intermediate certicates are not yet trusted.
• gpgsm: Fix an error message about the digest algo. [T4219]
• gpg: Fix a wrong warning due to new sign usage check introduced​ with 2.2.9. [T4014]
• gpg: Print the "data source" even for an unsuccessful keyserver query. ​
• gpg: Do not store the TOFU trust model in the trustdb. This allows to enable or disable a TOFU model without triggering a trustdb rebuild. [T4134]
• scd: Fix cases of "Bad PIN" after using "forcesig". [T4177]
• agent: Fix possible hang in the ssh handler. [T4221]
• dirmngr: Tack the unmodified mail address to a WKD request. See commit a2bd4a64e5b057f291a60a9499f881dd47745e2f for details.
• dirmngr: Tweak diagnostic about missing LDAP server file.
• dirmngr: In verbose mode print the OCSP responder id.
• dirmngr: Fix parsing of the LDAP port. [T4230]
• wks: Add option --directory/-C to the server. Always build the​ server on Unix systems.
• wks: Add option --with-colons to the client. Support sites which​ use the policy file instead of the submission-address file.
• Fix EBADF when gpg et al. are called by broken CGI scripts.
• Fix some minor memory leaks and bugs.

So maybe closing the inspector, too is necessary here so that the real close / unload on the mail is triggered. But it might just be that Outlook immediately reopens the mail in your case. Then it won't help but I think you should try that, too because any Interprocess communication will be more effort.

It happens with 3.1.4, too.

Works nicely now. I added a "yellow" warning to indicate that the message is a crypto message that can't be handled by GpgOL in the Junk folder. I see no way to actually decrypt in the Junk folder as we are not allowed to access attachments.

In T4241#119944, @msc wrote:

I wonder if it would be possible for you to close the mail / inspector of the mail with DiscardChanges before doing a save as?

Discarding changes with the Close(OlDiscard) method has no effect on the issue.

Here are warnings:

If we can assume C99, we have the type.
I know, it is not guaranteed to be enough size. For particular host (Windows 64-bit), it works.

or, more accurately so it matches the C api, perhaps gpg.constants.import_status