Thanks.

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.

See T3505 for more in depth coverage of this issue. Essentially this is a duplicate under a slightly altered POV.

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.

Commit 8613727f1ee985c3cfa2c815523312914f033ffd adds considerable detail on both the issues affecting compiling and installing a Windows version of the bindings and what it would take to actually resolve it.

Thanks for the report.

Well, -Wno-macro-redefined should silence the warning but Iwill add an undef before our macro definition. The snprintf macro is used to make sure the libgpg-error's own printf implementation is used.

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

NEWS for 1.33:

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?

I decided not to backport UIF things.
Other fixes (KDF and memory leak) were done.
If this decision will be re-evaluated, remember the backport of the commit rG05d163aebc04: scd: Make "learn" report about KDF data object. doesn't have UIF change.

Perhaps, the changes for UIF (user interaction flag) is not needed to be backported now.
Because the feature is not yet used by any OpenPGP card implementation.
I am testing with Gnuk, but it's still experimental even for Gnuk.

That is good.

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.

Just a heads up to everyone, Fedora is moving forward with this change for Fedora 30 (currently rawhide). https://bugzilla.redhat.com/show_bug.cgi?id=1656282 is the bug tracking it.

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.

Sounds good! I give it to me for testing / documenting this.

Is this fixed now?