Hi,
I'm pretty sure that I finally understood it and fixed it. There was a data mismatch between the IMAPISecureMessage and IMAPIMessage which somehow only happened for sent mails. This case is now handled.

There was indeed a problem. With a test card I could reproduce the issue and fix it.

in I think a related scenario we are having the pinentry window not spawn at all, leading to "no pinentry" errors
Win 10 latest patches Mar 2019
Version 3.1.4-gpg4win-3.1.5
We've tried a few hacks including adding the .conf file to C:\Program Files (x86)\GnuPG\bin with
pinentry-program "C:\Program Files (x86)\Gpg4win\bin\pinentry-qt.exe"

Can you please run

gpg --debug ipc -vK

which will also start gpg-agent and print some diagnostics. You may want to redact the output. You can also run

gpg-agent -v --daemon

which should also print some more info.

Thank you, it worked.

Because the rules for downcasing are way to complicate to yield any stable result, the I-D requires that only ASCII acharacters are downcases, that is A-Z to a-z. Here is an example:

I applied https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=patch;h=8d1b5982138c104f3c50663738892fa110193059 on top of 2.2.14.

We fixed that in master and 2.2. Can you please test this with the next release and report or close this bug?

Thanks.

It may be our McAfee, that’s the usual culprit when something is being blocked that we need. Thank you for your help, I’ll let you know if this works for us!

[Randall_Meredith_ESig_7.14.17]

From: aheinecke (Andre Heinecke) [mailto:noreply@dev.gnupg.org]
Sent: Monday, March 25, 2019 2:36 AM
To: Randall, Meredith <MRandall@hoosierlottery.in.gov>
Subject: [Task] [Triaged] T4419: GPG4win not installing on Windows 10 Laptops

• This is an EXTERNAL email. Exercise caution. DO NOT open attachments or click links from unknown senders or unexpected email. ****

aheinecke triaged this task as "Normal" priority.
aheinecke added a comment.

The step where it is hanging at is to register the GpgOL Addin with Windows.

Can you try the hanging command on an elevated command line maybe without the /s switch which is for "silent"

c:\windows\system32\regsvr32.exe "c:\program files (x86)\Gpg4win\bin_64\gpgol.dll

Maybe it gives an error or shows some more information. Alternatively maybe a security software jumps in there and blocks access to loading this dll. Any unusual security software installed?

TASK DETAIL
https://dev.gnupg.org/T4419

EMAIL PREFERENCES
https://dev.gnupg.org/settings/panel/emailpreferences/

To: aheinecke

Cc: aheinecke, mrandall, Rafixmod, ccharabaruk, gp_ast

This is an automated email from the GnuPG development hub. If you have registered in the past at https://bugs.gnupg.org/ your account was migrated automatically. You can visit https://dev.gnupg.org/ to set a new password and update your email preferences.

I'm changing this to testing as the original problem is now fixed with a good solution that properly detects the contents of ms-tnef wrapped messages.

Can you open the command line (cmd.exe) and execute there: "gpg --passwd 6B05B09F" ?

The step where it is hanging at is to register the GpgOL Addin with Windows.

I've recently moved from the Windows 7 system where I saw the problem to a Windows 10 system where Kleopatra works. As Windows 7 will no longer be supported by Microsoft, there seems little point in working on this issue, so I'd be happy if it was closed as Won't Fix.

This looks duplicate of https://dev.gnupg.org/T4317

Thanks for the report. underscore followed by an uppercase letter is actually reserved for the system; thus we should not have used that.

i don't think we need another column without the domain, i agree that it's easy enough to strip.

That keeps the interface the same just in case we ever change the format. It has also the advantage that you can use the tool to extract the mail address from the user id and thus see whether it is valid.

That seems plausible to me. I'm not sure why you'd include the @domain part in the output, since it's all strictly about the localpart. what happens if you provide some upper-case inputs?

(fwiw, all of this testing is done with GnuPG 2.2.14-1, using the package that is in debian/experimental right now; i'd welcome any corroboration with other versions)

as i experiment with this, i find an even weirder result with certificate re-ordering: the function above is not idempotent.

Here is a horrible bash function for doing the kind of stripping and re-importing that *does* cause signature re-ordering:

Hi - that did the trick. The linked gpgol.dll loads without any issues. However the decryption of e-Mails don't work. I get the
"OpenPGP Encrypted message (decryption not possible) Could not decrypt the data: Unsupported protocol" error.

Yeah, that worked halfways. Meaning, if I try to send the forwarded mail
from inline / reader / docked mode, the Button lights up but no sending
happens. If I send it from undocked window, it works and the original
problem doesn't happen.

So what about this:

With gcc-9 in Debian experimental, everything goes well.
Yes, the use of pragma is questionable, but let's see.

I think that a small tool or feature for gpg-wks-client would be better than extending the --with-colons format. A --dry-run option for example could list the filenames which would be created.

Thanks for the confirmation. Although I still don't really know how to fix it :-(

I can also confirm this bug!

Maybe we should get rid of the _Pragma operator in particular because it is not used often and we cond on compiler type later anyway.

Will you be so kind and look into this?

Thanks.

Applied to master. This is not suitable for 1.8

for whatever reason, i don't seem to be able to push to the branch on playfair, so i've also pushed the same commit over at https://gitlab.com/dkg/libgcrypt

@dkg If you propose a patch here I'm pretty sure that we will accept it. As one of our Python binding users you know better then us how the API should behave.

see: https://wiki.gnupg.org/TroubleShooting#Manually_update_GpgOL_to_a_beta

This is very strange, common to all the crashes in the log is that they happen while a keylisting is running and before the first key from that keylisting is returned. But this could be a red herring because the keylisting is always started immediately in a background thread and so it would be normal that if the crash occurs immediately that it would still be running. The keylisting code is extremely similar to Kleopatra though. So I don't understand why Kleopatra would then work for you.

Running
valgrind --leak-check=full ./g10/gpg --import clusterfuzz-testcase-minimized-fuzz_import-5751600352591872.dms
gave me at commit f799e9728bcadb3d4148a47848c78c5647860ea4

==11882== 232 (16 direct, 216 indirect) bytes in 1 blocks are definitely lost in loss record 290 of 333
==11882==    at 0x1001C32C5: malloc (vg_replace_malloc.c:302)
==11882==    by 0x100B211B9: do_malloc (in /usr/local/Cellar/libgcrypt/1.8.3/lib/libgcrypt.20.dylib)
==11882==    by 0x100B214D5: _gcry_xmalloc (in /usr/local/Cellar/libgcrypt/1.8.3/lib/libgcrypt.20.dylib)
==11882==    by 0x100058A1D: read_block (import.c:929)
==11882==    by 0x10005B772: import (import.c:584)
==11882==    by 0x1000597FF: import_keys_internal (import.c:486)
==11882==    by 0x1000596FE: import_keys (import.c:526)
==11882==    by 0x10000727B: main (gpg.c:4675)

Thanks. Actually the same as arm7-unknown-linux-gnueabihf. I have added it to the alias table to be released with 1.36.

This file is readable. You must have changed the former one's visibility so that only you can view it.

Ok, I will wait longer next time.
How do I make the file accessible ? (I can download it)

We can't replicate that and got no more response for 9 months.

That was an intermediate commit on master - it is likely that there are memory leaks.
Moving the test around is not a solution. BTW {F630817} is not accessible.

Since I configured call tracing the running O365 Client dies immediately after activating the addin. Same happens now if I activate the addin.
Anyways, here is the log.

Thanks for the report. Log looks not unusual.

I think that this might have the same underlying reason as the fixed T4321 (still open because it was not yet released).

Just for history if I ever need it again here is a patch I wrote debugging QIODeviceDataprovider. I have not commited it for fear of regressions and apparently the code is correct for Linux and that it did not work as expected on Windows had other reasons.

Additionally that workaround is a bad idea because on closing Outlook it
leads to the GPG4Win error "Not all plain text could be removed, it's
possible that plain text from decrypted mails was transferred to your
server." (roughly remembered text-wise)

Thanks.

After further debugging it showed that it had to be an issue in how we use QProcess. So I've rewritten the way we call gpgtar on Windows and replaced it with a simple anonymous pipe solution. I've tested more then ten times with various directories that the data corruption no longer occurs.
The performance is slightly better, but we still use GPGME so it's not as good as if we would pipe it directly. But not using GPGME was not really an option because otherwise I would have had to implement a full blown "how to call gpg" with error handling etc. for Kleopatra and I really did not want that.

Hi there,

thanks for the report. Yes this is a known issue. This pinentry is so basic that it does not have dynamic layout as we don't include GUI libraries in the basic installer. For a better pinentry you can install Gpg4win.
In the future we are thinking about adding a pinentry based on the small "FLTK" toolkit, with dynamic layout.

The man page also needs to be updated (or reference) whats-new-in-2.1 ,especially the New format for key listings. The "missing" KeyIDs in the listing is extremely confusing to someone used to the old system. I wasted much time trying to discover what I was missing.

OK. Designated box wasn't a technical term, so obvious in retrospect.

By the way. As I see the domain in the screenshot ;-) let me just say that there is commercial support for GnuPG (https://gnupg.com) available and through which we could much better and quicker help you to find a solution that works for you if this is a problem in your organisation.

I think I know what the problem is. T4038 only works for "legacy algorithms" this means old ciphers where MDC was not the default are handled by this error. New algorithms like AES which should have MDC in all implementations were not affected by this because this is much rarer and points to a broken implementation / a real attack.

That is correct according to the specs: