Apparently i had a ASUS Wi-Fi go process listening on that port (even though i thought had uninstalled it), killing the process also allows dirmngr to start

Thanks you very much for your help! I think we have it. \o/

Running with the --no-use-tor results in output ending with OK Dirmngr 2.2.11 at your service, attached is the procmon output , to clear up one thing q4master.idsoftware.com points to 127.0.0.1 in my hosts file (in addition to localhost also pointing to 127.0.0.1), but it seems the issue is with the tor check

I see some strangeness:
A TCP Connect: q4master.idsoftware.com:4862 -> q4master.idsoftware.com:9050
and TCP Send: q4master.idsoftware.com:4862 -> q4master.idsoftware.com:9050

Sorry for the mistake!
It seems related to the load of the cpu. I'm using win7 32 bit in a netbook. When cpu is heavy loaded corruption is worse. I don't know if it's really relevant, only seems!

I think that this is the name of the integration tool with the desktop, isn't it?

Using gpgme means selecting the folder and use secondary button of the mouse (I think that this is the name of the integration tool with the desktop, isn't it?). Also fails using Kleopatra menu.
I tried several times with the same folder and I obtained diferent results. If I zip the folder and encrypt a unique large file seems to work fine. It seems to fail in pack-encrypt phase. Decoding several times the same encrypted file gives the same wrong result. Decrypt using command line also gives a wrong result. I didn't try to encrypt-tar from command line.

Done, See attached

I was able to reproduce this. I tried it three times with a very large folder and it worked fine. The fourth try though created a corrupted archive and Kleopatra did not show an error either creating or extracting this archive!

Thanks for the confirmation and additional info. In that case I give this high priority as I agree with the potential for data loss.

I'm thinking of how to move this forward.
The problem is that we (the developers) can't reproduce this at all and the debug output does not show anything.

The problem only occurs with the gtk platformtheme.

Has anybody discovered a fix for this issue? I'm running Win 10 Pro with Gpg4win v3.1.5. Dirmngr is still not executing and just hangs.

Mnemonics can be made language independent by implementing wordlists for every language. In bip39, each word represents a number, 0 through 2047 (their index in the wordlist).

Thanks

Thanks, I don't think that it is a problem for our usecase but the fix is trivial and we should apply it.

Thanks!

Thanks, will be fixed before the next release.

Thank you. I was waiting your feedback.

No, thks. It's just a test to confirm this rare behaviour. I did the same test several times with several and diferent results. But I think that a data corruption occurs sometimes when encripting a folder with several and large files. Just aconfirmation of the bug for the developpers.

Hi jmrexach,

I can confirm this has the desired effect for me on master (f97dc55ff1b041071bc3cbe98aa761bf77bb7ac8). Should we mark this issue as 'resolved' or do you have another process for that?

Hi, jmanuel, I agree with you.

I almost forget. If I zip the directory and the encypher the .zip file through Kleopatra, everything goes ok.

Have you used a very old version (< 3 ) to create the directory? I know you said that you are currently using Gpg4win-3.1.5 but maybe you have used an older version to create the archive.

The cyphered directory is a Windows 10 directory.

Have you used a very old version (< 3 ) to create the directory? I know you said that you are currently using Gpg4win-3.1.5 but maybe you have used an older version to create the archive.
In the past we had a problem that Kleopatra would not see the errors from the archive program but that was fixed some time ago. The Archive problem had problems with non ASCII filenames but nowadays it only has problems with full unicode filenames and those errors are shown in Kleopatra.

Thanks for the report. Fix will be in the next release.

OK, I will add for OpenPGPcard 3.1 or later.

Thanks for the info. Yes, for the OpenPGP card we could use the ignore error approach.

OpenPGPcard 3.1 or later supports clearing authentication status or examining the status.
The problem is that implementations don't use version number for available features.
Specifically, Gnuk keeps using version 2.0 in application ID, and only supports specific features of 3.3.

I've developed a simple patch that sets the CREATE_BREAKAWAY_FROM_JOB flag when creating a new background process. This flag requires a special permission on the job object, which is tested first. This means that the patch only works if the parent process sets JOB_OBJECT_LIMIT_BREAKAWAY_OK on the job object, otherwise the behavior should be as without the patch.

Hi,
we have a rare situation where the Home directory of Kleopatras backend ( gnupg ) becomes corrupted. This results in undefined behavior and strange error states from which we do not yet recover.

I don't think the cause of the corruptions is user interference. Users which report that don't even know about the GnuPG home directory in advance. I think we have some kind of rare bug which causes the keyring to break.

Hello, I'm trying to create my key with Cleopatra. It does not work.
At first it looks like it will work. The normal dialogue comes:
F576314: 1.jpg
The following when saving a backup, the following error occurs:
F576316: 2.jpg
When updating the certificates comes the following dialog:
F576319: 3.jpg
Enclosed the log files:
F576313: kleopatra.log.8456
F576312: Cleo-log
F576311: kleopatra.log.7084
Looking forward to help. Many Thanks

BTW, did you manually define -DNDEBUG, or what caused -DNDEBUG?

Reading https://en.wikipedia.org/wiki/Fedora_version_history, I guess that your kernel/glibc doesn't have working mlock.
It may work if running by root, though.

It is fixed in master branch of the repo.

OK, it's a libc with no pthread_rwlock_t.

T4298: 'make check' with uninstalled library, which is building now (even if rpath doesn't work well) handles related issue, which was fixed for libgcrypt-1.9. Since this issue is for other libraries (libgpg-error, specifically), we could do something similar, but, it may be detecting LD_LIBRARY_PATH to fail with "Please remove LD_LIBRARY_PATH".

Applied.

I think Bash 5.0 is in sid, not testing yet. Are you sure it's related to Bash 5.0? Is there any possibility your upgrading some other software causing this?

Rebooting the system makes the issue disappear.

News for 1.34: