Fixed with: https://commits.kde.org/libkleo/1318d2e13764e736d29c902500c21979e99eef9c

Looking again at this: There is a reason why I used the simple permissive license for _that_ file and didn't referenced the Program (GnUPG) here:

Do you have an example for this in our code?

BTW< you should add an SPDX-Licence-Identifier while you are changing the boilerplate.

See also T2448

I just took a look through assuan-socket.c and it appears that we just need to send the nonce and don't need to read anything back. We also found a bug on our side that was preventing the nonce from being sent, which has been fixed. The error message logged above no longer happens.

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.

The nonce is a string of octets thus it needs to be passed verbatim. I would need to study the code in libassun/src/assuan-socket.c to tell more.

@werner After sending the nonce value from the socket file, does anything need to be read back before ssh-agent commands can be sent? Are there any byte ordering requirements for sending the nonce or can they be sent in the same order as they are in the file?

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.

The chained status handlers are a problem in general. I will think about a more robust solution for 1.12

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.

My experience is that using a string is much easier and less error prone that to build up and allocate an error obj objects. A string leads to less code and bugs are easier to detect. There are enough patter on to handle strings in a safe way and key specs are in most cases already available in string form (e.g. hex fingerprints), be it from a mail interface, as a result of a database query or from the command line.

Linux, Ubuntu

I think i can understand why this decision was made, but i'm not convinced it's a great solution. In particular, string-based arguments for C libraries are asking for trouble, and compound string arguments of the type described above are even more risky.

Is that on Windows?

The use of --textmode is in general not a good idea. The GPA on Windows will work just fine regardless of line endings. Notepad.exe also does not care about line endings as does other proper text handling software. If there is a problem c+p from the GPA "clipboard" do the system clipboard we can fix that.

Just checked. This does not seem to be a regression.

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.