Thanks for the report. Indeed a bug. Will be fixed in the next release.

yikes. Sorry for that one,..

No. Pinentry is always 32 bits for us.

Strange, even if they are missing in the Gpg4win insttall dir they should be picked up from GnuPG which is added to PATH.

I think we might accept this with low priority. As this is an unusual way to create a key.

This was fixed.

I don't see it as a priority right now. We should keep it in mind for T3811 .

I do not think that we should prioritize this right now. I had a talk with Michael and he said that we basically have the trademark because we are currently using it. To really register it and enforce it we would have to hire patent lawyers and that will easily go into 6 figure sums. Which I don't think we need right now. Let's keep it as "GnuPG is in use as a Product of g10cde".

Ping.

First of all I find PIN a very bad term. "Personal Identification Number" for example for my Gnuk token is confusing. I use a string there,... So let us use PIN only where it really has to be a number. Otherwise it is a Password.

There has been some progress here. At least we no longer use "passphrase" in new code. We still have not yet replaced all old occurances.

I've already sent jens a mail this morning.

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.

But to resolve this bug I also want to remove stuff like "ooooh you should use numbers or something like that" we have that in configuration but our default code is too dumb to be useful (afaik "password" is accepted with 90% quality). We also have a bug for the quality thingy, which I also find important because that is the first contact with our software.

Found it: T3724

No that bug is different. Nowadays you have to solve four dialogs to create a key without a passphrase.

No! That is not what I want with this issue. We should ask once for a passphrase and then shut up.

I know, I helped implementing that. Patrick changed it.

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"

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

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

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

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.

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.

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.

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.

I can reproduce it. For me the image is properly attached, I can access the file, but the embedded image does not work. This will be because the content_id is mixed up. I don't know why this happens yet.

I've opened T4322 for the image embedding issue.