See T4293

With GCRYCTL_AUTO_EXPAND_SECMEM we won't anymore run out of secure memory. This has even silent been backported to 1.8.x (using the numerical value of that constant) and is for long an option of gpg-agent. Thus closing.

Closing, given that we implemented a general solution; see the parent task.

I have seen no responses on your two mails to the ML and given th athere is no concrete protocol bug, I close this issue. If you can show a concrete bug please re-open this issue again.

I think that all that we can do is to improve documentation.

Apparently, it's an error from your installed /usr/local/opt/libgpg-error/lib/libgpg-error.0.dylib (you have some configuration to prefer this library), while your configure is for /usr/local/lib (because you specify no --prefix).

that error means that the message was somehow corrupted during transfer. Are you maybe using ftp in text mode on a binary message for example?
You could ask your communication partner to send you messages in text (ASCII Armor) mode which is more robust.
In Kleopatra you can change that in Settings -> Configure Kleopatra -> Crypto Operations -> Create signed or encrypted files as text files.
On the command line you need to add "--armor" option.

The usual reasons for corruptions of binary data are FTP transfers in text mode; or opening a file with a Windows editor.

Got another reliable report in the Wald Forum about this. https://wald.intevation.org/forum/message.php?msg_id=6371&group_id=11

Adding the patch here.

Thanks.

T3530 describes the solution. In short: Put "auto-expand-secmem" into gpg-agent.conf.

Fix was released with 2.2.11

In your second run you added the options after the argument (4E2C6E8793298290) so they won't have an effect. Anyway, I can't see anything from the output. My way to debug that would be to run gpg under strace:

The command -e does not require any further argument. As with most Unix tools you can either give a file or let the tool read from stdin or output to stdout.

In the texinfo document, which is opened, when invoking 'info gnupg', there is a subchapter called "Invoking GPG". In this chapter, commands and options are defined. This is the text I mean.

Thanks. That typo was already fixed in 2.2.7.

Hi, it's OpenPGP and the same Exchange server. Perhaps it has to do with
the "Unterhaltungsmodus" from the error message.

I'm pretty sure I tested this in the past using the Outlook.com web interface. The mails should show with an unknown attachment (the signature). I can't think of any changes recently that would have changed it. I'll check again.

Though apparently resolved back in May, this is what ultimately led to T4191 and was thus only properly resolved quite recently.

Confirmed that this is indeed fixed and made the (rather minor) change to the HOWTO that was needed. No changes were needed for the example script (decrypt-file.py).

This has now been tested on a 32-bit Gentoo VM and it behaves as expected with 32-bit system detection and creating keys with pre-2038 expirations working.

Most options are not explained with --help. Right before the examples you see

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