I found an issue in the assuan code of client side. This might be the cause of the server failure for nonce.

The followup of this issue for libassuan is: https://dev.gnupg.org/T6324

Hello Andre Heinecke,

I see the use to have an option to have a stricter "min-rsa-length", and which will be useful even in the future e.g. for 4096.

So the problem is occuring when the output is finalized (which happens after the GpgME Decrypt Result is signalled). And when there are still bytes to write in line 332 https://dev.gnupg.org/source/kleo/browse/master/src/utils/output.cpp$332

What I mean is that our socket emulation is encapsulated in libgcrypt and details should not be visible to the caller. Further libassuan and kleopatra might be build against different libc versions and thus the used structures might also differ.

As you might have seen from the commits mkportable has been removed from Gpg4win.

From the NEWS assuan_sock_set_sockaddr_un was only added in 2014, years after the UIServer code was really last modified.

I do not consider the whole PyPi thing a secure solution and thus we do not want to engage us there. However, if you need small patches to GPGME, please go ahead post them to the ML or upload them here.

The question is why Kleopatra does not use assuan_sock_set_sockaddr_un as we do in GnuPG. See for example
https://dev.gnupg.org/source/gnupg/browse/master/kbx/keyboxd.c$1124 - was this a workaround back when we had no support for Unicode? assuan_sock_set_sockaddr_un and assuan_sock_get_nonce work together and their internal workings should be opaque to the caller.

Btw. This is how Kleopatra creates the socket: https://dev.gnupg.org/source/kleo/browse/master/src/uiserver/uiserver_win.cpp$34 which does not use a function that would set is_socket=1. My naive fix would be:

My opinion here would be add the "import key from signature" and "put key in signature" in the automatition group of the main GpgOL config page and change the wording of "Import any keys included in Mails" to "Import keys from Headers and Attachments".

o.O have overlooked this since October.

This is most likely caused by an incompatible addon. See: https://wiki.gnupg.org/GpgOL/IncompatibleAddons

If no keyserver is configured GnuPG uses its default keyserver. "disable-dirmngr" would be the option to completely disable keyserver access but that is rarely used.

I think the current way is a good compromise. Turning this into a fatal error has also resulted in very many support cases.

On Windows, a whitespace character followed by a number in parenthesis at the end of the file name is now stripped from the proposed output file name.

Somehow I was waiting for such a comment ;-) Sure you are right and we will fix the README eventually.

Thanks for the certificate, looks good as far as I can tell. I have trouble with CRL checks for your certificate as https://crl.sectigo.com/ does not work for me. But that should not be an issue when decrypting.

@ikloecker Well in the spirit of user friendlyness Kleo could assist the user by removing this added blurb. We already assist the user in using a different folder then the temporary folder for such files.

Hello Andre Heinecke,

This is probably not the right place, but considering you're telling people *here* that they should not build in the source tree, your README and INSTALL files do tell the users to do exactly that.

Your response to my other bug report (T6320) advised me not to build in tree and that fixed the "make check" problem. In turn, that means I no longer need to patch Makefile.am and run autoreconf. That has made this Development Version warning to go away.

See T6310 and the release note update at T6303.

Sorry, I can't replicate this.

@ikloecker You are right, I only thought of public key import. Then lets serialize this. Might even make for a nicer Progressbar if we count the outstanding files.

In T4505#166463, @aheinecke wrote:

I have an Idea. Can't we read all data into memory in Kleopatra (for Certificates this should be ok) and then give this to GPGME as a single data object. So that only one process imports multiple files?

In T4505#166390, @ikloecker wrote:

I really don't want to bypass gpgme and then parse the import results and all other status output of gpgsm ourselves. I'll go for Andre's suggestion and serialize imports of multiple files.

Please attach the certificate so that we can check what is problematic with that certificate. I am changing this issue to wishlist as the solution here will most likely be that we have to extend the S/MIME capabilities of Gpg4win.

For testing I have created a Gpg4win installer and only selected minimal installation and gpgme-json was there. Both in /bin and /bin_64.

This bug is CVE-2022-47629

Thanks all. It is a bug in Win32 OpenSSH. https://github.com/PowerShell/Win32-OpenSSH/issues/1953 it is already fixed. I think the issue will be resolved after the update is shipped. I could use ssh -T git@github.com as a workaround.

Well, not our bug... it's a kind of support question and answer:
This might help: https://stackoverflow.com/questions/3844393/what-to-do-about-pty-allocation-request-failed-on-channel-0

Pushed the change.

Ah, I had not done git pull for a week, and I didn't realize your patch.