According to sks-keyservers.net both servers you mention run the very same software. Thus I would like to understand why you think they require the use of a legacy option.

No... In this situation, my atachment is a rar file

Interesting. Thanks for reporting this. This happened in the past because images had a "content-id" (so they were marked to be an embedded image) but were not really embedded. I did not have a very good fix then because it is hard for us to detect (easy for Outlook itself though) so there might be more special cases where this happens.

fwiw. Your patch is beautiful in which it follows our coding style and debug output. I'm confident that we will accept it but currently I have to read up on Job's a bit.

That is a very interesting problem that we did not have on our radar.

I would have thought this is a logical usage for gpg cards - seems this is harder to achieve as I thought.

Thanks.

Thanks.

Thanks.

I want to have this fixed for the next release so prio high.

Oops. Assignee removal was an accident. Sorry for the noise here ;-)

Just as a note: To workaround this you can also place "no-use-tor" into %APPDATA%\gnupg\dirmngr.conf (you might need to create that file) %APPDATA% expands to something like "c:\users\yourname\appdata\roaming"

In T3381#121973, @madhon wrote:

In T3381#121972, @Spiker wrote:

On Win 10 Pro it looks like File Transfer Server.exe is running on port 9050 which could be causing the issue. See screenshots.

That process is the one i killed which is part of Asus Wi-Fi Go

In T3381#121972, @Spiker wrote:

On Win 10 Pro it looks like File Transfer Server.exe is running on port 9050 which could be causing the issue. See screenshots.

On Win 10 Pro it looks like File Transfer Server.exe is running on port 9050 which could be causing the issue. See screenshots.

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.

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.

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".

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.

Since today, I cannot send any Signed email. Outlook is crashing.
I guess it is due to the new version of GpgOL I installed.

I've opened T4322 for the image embedding issue.

Thanks to the remediation.

I think I understand what is going on here:

@aheinecke the file is gpgolXXX.dat. I never got the winmail.dat (I think).