I don't think this works for me in that way.

Use that function as early as possible. The gpg-error tool has also be enahnced on Windows:

Thanks. In the meantime GpgOL takes it's language from the Outlook configured display language setting. I'll add support for override locale to gpgol so that the locale is set accordingly

Regession due to my commit 10 days after the last release. Thus no need to do a release.

Should we close this or do you want to investigate why the segfault happened after the error?

Thanks.

I ran it with GPGME_DEBUG and it errors out at
GPGME 2018-12-07 10:34:32 <0x19c43> gpgme_op_genkey_start:293: error: Invalid argument <GPGME>

Sorry, I am still not able to replicate it:

Just by going through the standard "new key wizard".

Can you give me a reproducer on Linux. I am not able to reproduce it. What versions of gnupg and gpgme are you using (see gpa's about)

I'll deploy one on AWS somewhere briefly once I've replaced a certain external keyboard, there will almost certainly be an existing image of some Linux distro in the AWS marketplace and I'd be very surprised if it took more than an hour or two of compute time to confirm.

I am not sure what text you reference. Can you please explain?

ImageMagick version with that regression?

One more semantic question about how folks think Context.decrypt(verify=True) should work: if the decrypted thing has no signature at all, should the function succeed without throwing an exception? it currently does, but the returned verify_result has its signatures member set to the empty list.

Ooh, nice catch @dkg, I just stepped through each of your changes and it all looks good. I'll tweak the relevant sections of the HOWTO dealing with this in the next few days (I need to replace a keyboard here before properly diving back in) and then close this case once done.

❤

since @aheinecke merged my changes, i think this bug is now resolved. I'll let @BenM close it though :)

@aheinecke thanks for the merge of my other branch! sadly, that branch does *not* address this issue yet. It doesn't even test for it. :( I can work on trying to fix it (and test it) if there's a consensus that we want this particular change in behavior.

I apologize for the wrong report.
Files to be encrypted should be at the end of the command.
It's my mistake.

Is this fixed now?

Ben is not even subscribed to this issue.
With the volatility of gpgme-python I think that this can easily be merged. I did a quick review and it looked good to me.

Thanks! Applied.

Needs to be merged. (Note that Phabricator does not show the branch in the tooltip for commit ids.)

note that the branch also updates the test suite to make sure the verify=False case is tested.

I've just pushed a branch dkg/fix-T4271 , currently at ac8d7238dbf165950c9844e5cb41da8eb4d37bc0 that resolves this problem.

In this case the data is taken from a byte buffer, (unsigned char *). I can't see why iobuf_readbyte should be invoked here.

@gniibe there seems to be one remaining issue.
Even with iobuf_get_noeof, we have to cast to an unsigned integer before shifting 24 places to avoid undefined behavior :

diff --git a/common/iobuf.c b/common/iobuf.c
index 5eeba8fe6..1b9722d0a 100644
--- a/common/iobuf.c
+++ b/common/iobuf.c
@@ -878,7 +878,7 @@ block_filter (void *opaque, int control, iobuf_t chain, byte * buffer,
                    }
                  else if (c == 255)
                    {
-                     a->size = iobuf_get_noeof (chain) << 24;
+                     a->size = (size_t)iobuf_get_noeof (chain) << 24;
                      a->size |= iobuf_get_noeof (chain) << 16;
                      a->size |= iobuf_get_noeof (chain) << 8;
                      if ((c = iobuf_get (chain)) == -1)
``

Regression introduced with 1.12.0.

This is a new bug, I believe, but perhaps it only appears with "broken"
S/MIME-messages of this type, So I'll first post it here:

fine with me

I'll leave the fallback to "just try to decrypt" in though because it is better then doing nothing like we did before.

Thanks, from that log I can understand the problem:

please add a unit to the test suite to make sure something like this doesn't happen in the future!

Ok, with the beta gpgol the mail is successfully decrypted. This is the debug.log:

You are running in a codepath that means "Outlook told us this was S/MIME, but we have not seen the proper message headers and neither does the data look like it is S/MIME."
Sadly your log does not help much in that case because it marked the mail as bad and aborts.
I've changed that "marking a mail as bad" so that future logs will be more helpful and that it will still try to treat this case as "encrypted" maybe that will already work, although I doubt it. The log will at least be a bit more helpful.

additional info: I have their certificate(s) and sending encrypted mails to them is successful.

I forgot the debug log:

Gets reported multiple times and should be fixed for the next Gpg4win release as it is a bad first impression. (Although it can convert users to Kleopatra ;-) )

not yet, I try to get to it this week.

i'd be happy to help you set up your own x86 32-bit guest VM for testing
if you like, even if you're running on x86_64 hardware. they're cheap
and easy to run, and have a delightfully small memory footprint :P just
let me know!

I'll look into it.

BTW I am aware that Git repository does not contain many files which are prebuilt in tarballs. I am okay with that, I know the difference. I am just reporting that pinentry's configure script is missing an option, which is clearly needed and which is present in other components.

I wasn't using tarballs. I have fetched code from Git (git clone git://git.gnupg.org/pinentry).

Well, that is a detailed bug report. Thanks.

Ok. If you can confirm that then it means that my analysis is right. Still unexpected to get an error there. I have to do some more tests with Exchange Online but that would be another issue. If this issue is fixed by turning of debugging then it will also be fixed by my patches.

You are right that Outlook behaves normally if debugging is deactivated.
I had major problems with 3.1.4 and never used it until 3.1.5 came
along, so I guess it might be an existing problem.

While I can't reproduce it myself (because I probably don't have the right mails in my exchange) looking at your log I think that I see the problem there might be an issue with the error handling in openProperty. So for old mails the openProperty probably fails because we have exchange online for that and the property is not yet available in Outlook and then the error is not correctly handled and it crashes.

This should be fixed in commit fd34415bdd57332424bd5a98d279e2331678a2fb

Was released with 3.1.5

Was released with 3.1.5

hm, adding: --with-tar=tar to my invocation of ./configure appears to leave gpg-zip with:

My problem isn´t linked to forwarding encrypted e-mails and / or attachments. It occurs by ordinary PGP mails WITH attachments which are not ASCII format. Encrypted e-mails without attachmoments or in ASCII format will be delivered.

oh! i suppose i underestimated the severity of it. apologies!

Form my understanding this needs to be fixed urgently.

So for me, sending encrypted attachments by selecting them from disk works fine for attachments. up to ~200k (I haven't tried larger ones).

Pretty obvious. Thanks.

I have a warning already in my working copy.

I fixed the gpgrelay link.

"Miranda ICQ [Unix] CHAT" also doesn't work. Maybe it would be a good idea to check all of them via script or something like that...

i don't see any active use of it in all of debian: https://codesearch.debian.net/search?q=gpg-zip

Thank you very much for the quick response and try-out in detail!

Bug or user error?

It is useful if you often log out and in, for example using remote remote ssh session. If you don't like it, you should "gpgconf --kill gpg-agent" in your .bash_logout. ~/.xsession or whatever your system uses. Instead of --kill you can also use --reload so that the passphrase cache is flushed immediately and not only at the end of the TTL.

Thanks. Just pushed the change to master.

Let me also note that gpg-zip was not installed since 2006 due a conflict with gpg1.