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:

Hey. Are there any new regarding this ticket?

What terms in the man page are troublesome for you?

Despite my previous denial, I now think that you are correct: I now think that I did indeed follow a Debian wiki entry on separating the primary key. In my defense it was many years ago :-(. I have now managed to import a primary key, although unfortunately the wrong one.

Just to note that I did import the secret key, but there was no change. I have searched for the term designated box, but I found no hits. Where is this term defined or explained?

Thanks for the prompt reply. I did not explicitly move the primary key offline. Maybe there is something in the default debian configuration that does that?
$GNUPGHOME is pointing to a .gnupg which contains secring.gpg and also a directory private-keys-v1.d/ which contains two keys.

You are keeping your primary secret key offline. You need the primary secret key for most operations because it is required to bind user ids or new subkeys to the primary key. The "pub" indicates that you have only the public part of the primary key. There are several howtos on how to move a key offline and you seem to have followed on of them. The common advise is to have a designated box with the full key (including the primary key) and use that for key maintenance. Of course you can also import the primary secret key.

I should have added, in case it wasn't obvious, that I changed some ids etc in the report just to protect precise details.

Similar issue with ntbtls:

I reviewed the multibyte handling in GnuPG and you are right, there is a general problem because we use ReadConsoleA and basically GetCommandLineA, so there is no way for multibyte input unless a parameter file is used. Output is also broken, but that is easier to fix iff the input case has been fixed.

FWIW:
The first config.log is from a gnutls build.
The second for libassuan 2.5.3 and has been configured:

./configure --enable-shared --prefix=/var/tmp --libdir=/var/tmp/lib64

Libassuan 2.5.3 has a similar problem:

Changes backported to 2.2

Hello,
I've opened T4395 for this to keep better track of it as this task was about another issue.

Hi，aheinecke。my kleopatra version is "kleopatra Version 3.1.4-gpg4win-3.1.5".and when change expiry date, i enter a wrong passphrase or choose "cancle". it shows successfully. what can i do for solve this question. thanks.

And attached is a test key.

Ok here is the output:

C:\Users\croll>gpg --import "Desktop\Charles Rollins.asc"
gpg: key C7EE3D25FF2E5EF5: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: key C7EE3D25FF2E5EF5: failed to re-lookup public key
gpg: key C7EE3D25FF2E5EF5: public key "Charles Rollins
<crollinsphoto@gmail.com>" imported
gpg: Total number processed: 2
gpg: w/o user IDs: 1
gpg: imported: 1
gpg: secret keys read: 1
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 4 signed: 9 trust: 0-, 0q, 0n, 0m, 0f, 4u
gpg: depth: 1 valid: 9 signed: 0 trust: 1-, 0q, 0n, 0m, 8f, 0u
gpg: next trustdb check due at 2019-11-05

C:\Users\croll>

What is meant by missing self signature? I signed it before exporting it.

Further testing leads me to believe that this is probably a Kleopatra / QGpgME / Qt issue. I can pretty reliably reproduce this when using Kleopatra but never have I gotten this with gpgtar only, and I tested it a lot of times.

The difference is between: 0x01035400 and 0x01034600 where 7 blocks of zero bytes are in the broken archive which are not present in the original file.

Kleopatra now shows an error in this case when extracting. So now we only need to fix that this happens at all.

We are currently not aware of any bugs that would prevent the import of valid secret keys.

Ouch indeed. Looks like you run into a "hanging" gpg-agent situation in that case our main background process is blocked and all other processes wait for it to respond and nothing works anymore.
This should never happen and we need to fix it. But so far we have not found a way to reproduce it.

There was indeed a missing dependency. libgpg-error and libassuan were only installed if GPGME was installed, so only if Kleopatra or GPA were selected.

Hi,
sorry for the late reply. I cannot reproduce the issue.

Also reported for Contacts in T4161.

I think that this is the same as T4388 So I'm merging it in.