Alright, I will create a ticket with Exquilla to see with them if this could be fixed on their side.

Very strange behavior caused this. Outlook seems to detach from an object model call, handle a window message, and then return the object model call.

See also T2448

This for importing passwords using a somewhat heuristic approach to accommodate for all the weird things other PKCS#12 implementations do. I have not looked into the specs for a decade and thus can't tell you the reason for that limitations. There might have been one back then. In any case PKCS#12 is the most insecure things in the PKCS suite and it is questionable whether this can be called a standard.

Also confirming the workaround. Not sure whether it would have done me any justice to counter-sign the key after accepting it locally, since I only verified it against their web page. The web page is hard to find with a Google search, since Google does not turn the unspaced hexadecimal fingerprint into something that matches the space-every-four-digits format used on their PGP/GPG instruction page. Searching for "Facebook PGP key" works, though.

Thanks for the quick reply @aheinecke.

I (as the maintainer of pinentry-qt) fully agree with your sentiment. I changed it in pinentry-qt (since version 1.0.0) so that the keyboard input is only grabbed (which is a security feature) when the input focus is on the passphrase entry as I found it very annoying myself.

This task and Forum reports about CRL errors caused me to investigate a bit and we found a Bug with CRL's on Windows. T3923 which might be the root cause.

Looks ok now in my tests. I still want to test against more CA's with more CLRs (e.g. COMODO and CACert)

Was Okish in my last tests. But I did not fix anything compared to 3.1.0

The commit mentioned fixes the problem.

I can confirm the workaround. After importing the key from Facebook everything works as expected!
Thank you very much!

Thank you very much. It helped. I can reproduce the problem now.

Same here with Mails from Facebook, here's the log

"Invalid crypto engine" Means that there is some internal error in the signature verification / decryption.

I got an Idea how to improve the situation here. But its very complex and might break Outlook even for unencrypted mails. So it's very invasive.

Right now building the release.

@nitroalex Perhaps, creating new ticker is better for this topic.
In the current OpenPGP card specification, there is no way for an application (except having a list of card implementation information) to know wich algo and which curve is supported or not.
So, what an application does is try and error.
I don't like this situation, but I don't know how we can modify the specification.

Linux, Ubuntu

Is that on Windows?

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