Yes that is expected, we block the save event as long as we have replaced the Body / Attachments of the mail with decrypted contents are shown. In our debug log you would see the message "Canceling write event".

Looking at the GPGME code the ERROR stati don't matter because they are only used to return a better error code in case an operation failed. The specific ones are not even recognized.

No info received.

No more complaints thus time to close.

I consider this bug to be solved.

MacPorts doesn't currently ship the bindings at all, but I'll see what they need to make that a reality too.

While this is now ideal for Debian, it may cause conflicts with other downstream vendors with slightly different needs to build their packages. In particular the FreeBSD ports and/or pkg system.

Yes! Thank you very much. My test runs and my Outlook has verified 2500 S/MIME Mails without a crash.

The explicit check for a valid FD (in select) I mentioned above is commit 8173c4f1f8a145c4b1d454f6f05e26950e23d675

I'm currently looking at the CloseHandle in _gpgme_io_close:

Btw I've checked that the errors are the same in T4111 and this:

Fixed it myself as I confirmed the leak with Dr. Memory.

I've seen now four crashes in _gpgme_io_spawn. I've added tracing that shows that the CreateProcess itself is crashing. I do not see how this is possible. I'm printing the command line and the program name in debug output and both look fine.
The command line is also mutable.

I'm also seeing hangs. Sometimes with gpgsm running. Sometimes without it running.

We had this idea to have a label: or similar item in the extended-key-format which is displayed in addition to the other info. The user can then use an editor to put whatever she likes into this field.

IIUC, in Gentoo multilib (or other distributions), <triplent>-{gpg-error,libgcrypt,libassuan,npth,libksba,npth}-config script is used.
In forthcoming libgpg-error 1.33, single gpgrt-config is used for all architecture, by having --libdir option at invocation time.

Actually we plan to provide a more convenient way to perform the DH operation. See for example P7 for the non-elegant way which is required today.

Did you have the chance to try it out with 3.1.4?

Sorry, there is no good way, but only workaround in this case, because it is complicated and it is basically wrong thing to do it by composite device (in my opinion). I'll describe detail in this comment.
I'm not Windows user, so, I don't have an idea how to recover from such a situation.

In T4225#119482, @aheinecke wrote:

Can you give me the exact steps what you are doing?
"Generation of an OTP" is strange to me. I have an FST-1 hardware token that runs the same software as a yubikey (GNUK) but I'm not so well versed in all the windows use cases. But I am interested to fix them.

I've closed this as a dup because the pinentry-qt is the default one on Windows and T4123 describes your problem.

Is it possible that you have used a different pinentry in the past? Like the GTK one?

Can you give me the exact steps what you are doing?
"Generation of an OTP" is strange to me. I have an FST-1 hardware token that runs the same software as a yubikey (GNUK) but I'm not so well versed in all the windows use cases. But I am interested to fix them.

Fixed in 1.8

Fixed in 1.8

yat2m updated. Thanks.

Thanks. There is an easier solution for this, though: I now trim trailing LFs.

For what it's worth I found some more places where data leaked out even in log level 1. It will probably be a bit of a process to get this clean to a 100% as there is no automated way to decide what needs to be filtered and what not.

Thanks. Fixed in master. Needs backport.

Thanks. Fixed in master.

In addition to what I said above - the patch comes with two small side-effects - The size of the content in the tab is constant over the tabs, so that even a page with not very many settings will show a scrollbar, even if it only makes it possible to scroll in empty space from below.

I have made a patch for this, that add scrollbars to scroll up and down in the settings. This adds the need to set a default window size, which I have set to 700 x 500, which seems fine. Tested on a relatively low-resolution machine (1366 x 768), where it seems to work fine for me.

There were two ways to access the registry and the config value load did not fallback to HKLM. I've removed the second way and I've tested it and it works now as it uses the codepath with the fallback.

Thanks for the quick reply!

Thanks. I've never seen that, so my test definitely did not test moving junk mails.

It doesn't work too.

Hi,
As for getting Help, we all speak German ;-P

Thank you for the feedback. Very strange, that should have been solved indeed and in my tests it works and I also got feedback from other reporters who had that problem with 3.1.3 that it works in 3.1.4.

I'm also seeing the same behaviour on a freshly installed Windows 10 1809 with Gpg4win v3.1.4. Have to kill dirmngr from task manager to be able to get into Kleopatra.

I am sorry about this but the hkps pool has load problems because only a few servers are left. You might have a better chance getting your key uploaded by configuring another pool. See https://sks-keyservers.net . The admins are aware of the problem but there won't be any short time solution.

Apparently, it is not the bug of gpg, but you just specified wrong line in your /etc/apt/souces.list.d/skypeforlinux.list, where filename extension .gpg is irrelevant.

It is propably related to decrypting large (single) tar-files. It works flawlessly when renaming the tar-files to another extension before encrypting and afterwards decrypting it again. But as long as it is named xyz.tar Kleopatra crashes. Could it be that untarring causes some "out of memory" failure? I recognized that while decrypting the tar there was no sign that the decryption process would allocate any disk space. There is just an empty randomly named folder being created upon decryption.

Thanks for taking the time to create this report. It should be fixed in Gpg4win-3.1.4 please try out that version. :-)

Related, the tab formatting (mixed first one tab and then space), as in lines 131 to 137 of src/icons.c _really_ causes headaches.

Nesting the op_genkey() calls inside try/except statements with the exceptions being caught as "oops" and otherwise "oops" being set to None provides a means of checking whether the 2099 expiration is a problem and 2037 is not.

Well, I guess this answers my question in T4192 regarding why op_genkey was in use.

In T3354#118876, @justus wrote:

This should already be possible, iirc the Arch Linux maintainer patched
it in. I believe there is a 'prepare' target that takes care of all the
preparations (duh), and then you can build for every Python version by
executing the Python build system with the Python version of your choice.

@werner, thanks for rMff6ff616aea6 -- i've backported it to debian's packaging and it lets us cleanly build against all installed versions of python.

Almost the same bug also happens with pinentry-tty.

Sorry, pressed enter too early. the bug report is complete so far. I guess it is a lot of work to reproduce, so I'd try to be very responsive instead.

Thanks for the reporting templates; would mind to fill in some bug details?

Here goes.

there should be clearer labelling of smartcards so that users can tell them apart more easily

That is up to @BenM

the error i'd seen earlier after reverting the change was an error due to running t-callbacks.py on its own, without the rest of the test suite framework. running it within the test suite framework (with the change reverted), it passes without a problem. I've uploaded 1.12.0-4 to debian with a patch to t-callbacks.py. I can apply it upstream, if you want me to.

See T4195 for the general problem

I have not looked at the new error but the year 2099 is clearly a y2k38 problem. gpg has some precautions but I have not checked the key generation code. The gpgme interface uses a signed long for the expiration time, although that it parses the dates received from gpg as an unsigned long. Right now, I am not sure why we did this because an unsigned long would just work. Maybe we can change or enhance the interface. But in any case this is a general problem and not specific to this bug.