Well, I surely would agree (and this is only a proposal anyway), but my point here is, that OpenPGP Card does not support Curve 25519, so that one *have to* choose between those other two. Considering me a tinfoil hat person, I would rather not choose NIST, as many others wouldn't too.

Ok I tested with Exquilla. I configured an Exchange account once through Thunderbirds built-in account (IMAP) and once with Exquilla

Weel, you GnUPG version is actualluy the lates. Unfortunately I tested with a beta version. Let's wait a day to see whether there is more fallout and if not I will do a 1.11.1

Look like you are using an older GnuPG version and thus the test fails. I need to tweak the test.

Thanks for the report.
I clarified the title a bit to include exchange / exquila.

Let's use the new issue as the problem is described completely there and it makes it more clear.

No problem :).
Currently I cannot access this newer pinentry release.
My .bashrc is almost default, hence it doesn't have the line you requested.

I already created a new issue for this in the new version of gpg4win (v3.1.0) with GpgOL v2.1.0. This is the issue: T3917.

Thanks for looking into this issue :-)

Ben: We need to use a faked system time thing to make those tests more stable.

I backported the fix for 1.8.3.

Cherry-picked this for 1.8.3.

FIPS rules changed anyway and thus more rework will be needed anyway. I keep this open at low priorirty.

This is a build system setup problem with standard solutions.

@Beiri22: It was my fault to to tell you to use scdaemon.conf. The correct conf file is of course dirmngr.conf. However, with @BenM comments I don't think that it is a bug at all. I am thus closing this; please feel free to re-open if we were wrong

Do you have a chance to try with a more recent pinentry; ie. 1.10 ? This may give better diagnostics.
Another thing I would suggest is to debug the invocation of pinentry: Put

Ok, thanks for the reply

Thank you :)

Thanks. I only now noticed that this is the same as we already use for 32 bit MIPS. I have no more questions. Will push to master and the 1.8 branch.

That is all intended. You can always create broken messages which don't result in _one_ clear error code.

Clang doesn't support the "h" inline asm constraint and the C version of umul_ppmm() works on MIPS64.

Your patch indicates that all clang versions for MIPS64 support this feature. Is my reading correct?

With this example, the problem happens at
a->size |= iobuf_get (chain) << 8;
iobuf_get (chain)returns -1 and -1 << 8 is not well defined.

Sorry, I can replicate this with current 2.2 nor with master (on amd64 Linux):

We never tried to build gpgme with MSYS2 and I would also say this is not supported. A wild guess is that this mixes platform specific code.

To attach a file use the cloud-with-arrow icon in the edit toolbox.

I wonder if CACert intentionally sabotages X509 / CMS.

Did that help any?

You can close the report.
I'm working with a restricted user and I installed gpg4win-3.1.0 with admin rights, probably didn't work so well.

See also Filippo Valsorda's 32c3 talk about CSPRNGs.

@gouttegd : setting only-urandom at the distro level problematic due to two factors:

You are welcome :-) I did not know about that 39-Arigato

@dkg : Can’t this be solved at the distribution level? I assume the packager/maintainer for Libgcrypt on a given distribution should know whether the getrandom syscall is available on said distribution, so he could install a /etc/gcrypt/random.conf file with the only-urandom option.

Werner wrote:

we already use the getrandom system call if it is available

Neither Brainpool nor NIST curves make any sense unless there is an organizational policy requirement. Thus the --expert requirement is the Right Thing (tm).

3.1.0 is released and this issue is to our knowledge fixed.

( Apart from the part that was moved out to T3895 )

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

Thanks again. Good catch.
In Japanese 39 sounds like "Thank You!", that's indeed appropriate to your report. :-)

I think you are running in the infamous T3459 "As long as the decrypted content of a crypto mail is loaded a mail can't be moved" You have to unselect the mail and then move it without opening it. E.g. by right clicking it. I know this is horrible and it's a major problem but I don't see how we can fix it in our architecture. As we replace the mail content with the decrypted stuff we have to prevent "Write" Events by Outlook. For Move if you block a write event, the move fails. But we don't have any idea in our addon when a write comes from a move. I spent a lot of time on this and have not yet found a good solution. But I think the workaround is kinda ok.

The Bug is here that the Error is not shown properly. In the log:

When a command is invoked from Midnight Commander, pseudo tty is used.
You can confirm that by typing tty and see the output of the command after exiting from mc and again typing tty.

I am currently considering improvement of finalizer of libgcrypt, so, this matters.
Looking code, it would be better not to allocate and free the constant,
but use compile time constant data in .text section; Something like: const unsigned char ctr_null[DBRG_CTR_NULL_LEN].

Applied to STABLE-BRANCH-1-4, too.

Good catch. Thanks. Fixed in STABLE-BRANCH-2-2.

Apparently, your /lib/x86_64-linux-gnu/libgpg-error.so.0 is not the one you installed (I mean, libgpg-error version 1.27).
You need to install your new version of libgpg-error so that it is usable.
Please check your ldconfig or LD_LIBRARY_PATH, etc.

works just fine, thx!

I've opened T3895 for a permanent decryption / permanent removal of attachments. Maybe something for 3.2.0 ;-)

So I used a debugger to see if I could garner any additional info. Here's the log:

When an attachment of a crypto mail is removed it now leads to a warning.

In my tests it does work nicely now. We detect the "Send Again" state and correctly handle it. Sign / Encrypt is preselected depending on the state of the original mail. Even works with attachments.