I don't mind a workaround that avoids an ABI/API fix as long as it defers actual failures until 2038.

I'm reopening this because i think users of these 32-bit platforms are going to run into issues before 2038 happens. Certs could appear expired before they are actually expired, for example, because of the wraparound time.

I would prefer to have a procedure that do not reset PINs to their default values, but as long as all PINs are set to known and valid values when KDF is setup it will not make the token unusable after that, so it seems reasonable to me.

Or, #5 would be:

Hi Andre,

1. I am the sender, and can guarantee both correct keys were used. The same two keys do work in the Kleopatra clipboard tool (with recipient tool's email parser) , just not with standalone files (at least not with his file decryption be tool).

1. It could be a user error on my part, but the Kleopatra GUI is showing both keys with check marks, so I have trouble imagining what I could do different.

1. Recipient is not using Kleopatra, as noted in the original ticket. It is possible (and I suspect, likely) that the problem is an incompatibility between these two tools. If this is the case, then we need to find which tool is not following the standard, or perhaps the standard is ambiguous.

1. Since filing the ticket I have discovered that if I (sender) use command line GPG (ugh!), the recipient can decrypt the file with his tool. This seems to point the finger towards Kleopatra as the more likely cause of the problem.

1. There was a screenshot included in the original ticket showing very clearly the recipients tool doesn't recognize the presence of a second (i.e. recipient's) key.

I am attaching the screen shot from the recipient’s tool again, for your convenience.
I am also adding a screen shot of the my (i.e., sender’s) set-up in Kleopatra.
Rich

G. Richard Newell
Assoc. Technical Fellow, FPGA Business Unit, Microchip Technology
(408) 643-6146 (office), (408) 882-4785 (mobile), +1 (925) 478-7258 (Skype)
PGP: (2009 DSA-1024, ELG-4096) B751 FC13 8B4E 49DA 2270 35A2 20E4 E66A D0D0 2E34

     (2016 SSA-4096, RSA-4096) 65F5 CCD6 23B3 BD3D CEDE AB58 171F F4DE E7D0 3ECA

From: aheinecke (Andre Heinecke) [mailto:noreply@dev.gnupg.org]
Sent: Monday, January 27, 2020 12:37 AM
To: richard.newell@microsemi.com
Subject: [Task] [Closed] T4824: Encrypted file appears to not be encrypted by recipients public key

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
aheinecke closed this task as "Invalid".
aheinecke added a comment.

Hi,

I have difficutlty to accept that as an issue in our tracker. Somehow the GUI for Kleopatra appears to be confusing for your "Sender" which apparently is not you, correct? This results in the wrong keys selected for encryption.
With this amount of information I cannot see any path of change for our software.
Could you maybe provide a screenshot how the recipient selection looks for your user in Kleopatra, so that we can discover why it might be confusing or why the recipients key is not selected correctly?

I'm setting this issue as "Invalid" in the meantime. Not out of disrespect or so, only because I don't see how the information from this issue can currently lead to a change in our software. I can change the status later again.

Thanks,
Andre

TASK DETAIL
https://dev.gnupg.org/T4824

EMAIL PREFERENCES
https://dev.gnupg.org/settings/panel/emailpreferences/

To: aheinecke

Cc: aheinecke, grichardnewell, Neurone, Rafixmod, ccharabaruk, gp_ast

This is an automated email from the GnuPG development hub. If you have registered in the past at https://bugs.gnupg.org/ your account was migrated automatically. You can visit https://dev.gnupg.org/ to set a new password and update your email preferences.

thanks for looking at this, @aheinecke ! if you or @werner know of any internal side effects where this does matter, it would be great to add a test that documents them.

Thanks! I would merge your commits but I'll like to talk to werner tomorrow about the always adding "--with-keygrip" I also think its useful but it might have expensive internal side effects that I am not aware of.

I have difficutlty to accept that as an issue in our tracker. Somehow the GUI for Kleopatra appears to be confusing for your "Sender" which apparently is not you, correct? This results in the wrong keys selected for encryption.
With this amount of information I cannot see any path of change for our software.
Could you maybe provide a screenshot how the recipient selection looks for your user in Kleopatra, so that we can discover why it might be confusing or why the recipients key is not selected correctly?

@Amaud, I read your code in Python. IIUC, it asks users PW1, Reset Code, and PW3 to setup, just before registering KDF DO (as you describe in https://dev.gnupg.org/T3891#114950).

(if you don't want to publish the full strace output here because you're concerned it might leak some information about your machine or your network, but you're ok sharing it with me personally, you can send it to me privately by e-mail, encrypted to the OpenPGP certificate with fingerprint C4BC2DDB38CCE96485EBE9C2F20691179038E5C6, and sent to one of the e-mail addresses associated with that certificate. please make a note here if you do that)

ok, that's deeply weird. i'm assuming that this machine has IPv4 connectivity. I have no idea why dirmngr would be returning EAFNOSUPPORT in that case.

Right after the failed connection I see:

$ gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye
S # hosttable (idx, ipv6, ipv4, dead, name, time):
S #   0   4 d keys.openpgp.org (37.218.245.50)  (5s)
OK

Regarding Cygwin: The sources are a bit hard to find.
https://cygwin.com/packages.html
-> https://cygwin.com/packaging/repos.html
-> https://cygwin.com/git-cygwin-packages/
-> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/libgcrypt.git;a=summary

Regarding GNU/kFreeBSD, my machine is using the FreeBSD 9.0 kernel, which does not yet have the security.bsd.unprivileged_mlock oid. Like what was mentioned here: https://lists.debian.org/debian-bsd/2014/08/msg00092.html

For Cygwin, I can't find how its libgcrypt package is built.
I found this for MSYS2: https://github.com/msys2/MSYS2-packages/tree/master/libgcrypt
This for Mingw-w64: https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-libgcrypt

I tested on FreeBSD. Same errors (t-secmen and t-sexp) are reproducible when we set:

in particular, c4cf527ea227edb468a84bf9b8ce996807bd6992 and f2aeb2563ba2f55eea7f52041e52062fdc839a64

The dkg/fix-4820 branch now has these two fixes.

Thanks for concrete cases. Sorry, not responding earlier. It was an experimental feature, firstly only available in Gnuk Token.

For easier reference or searchability, the test error looks like this:

I implemented the script described previsouly (https://dev.gnupg.org/T3891#114950) in the smartpgp-cli utility provided in the SmartPGP repository (see commit https://github.com/ANSSI-FR/SmartPGP/commit/4be0fa442b43c2bafd5f0171417ff68fd88cbe2d).

This appears to be a different error than above. here we see:

With tls-debug 16:

dirmngr[9162.6] DBG: chan_6 <- END
dirmngr[9162.6] DBG: dns: libdns initialized
dirmngr[9162.6] DBG: dns: getsrv(_pgpkey-https._tcp.keys.openpgp.org) -> 0 records
dirmngr[9162.6] DBG: dns: resolve_dns_name(keys.openpgp.org): Success
dirmngr[9162.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known]
dirmngr[9162.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known]
dirmngr[9162.6] DBG: gnutls:L3: ASSERT: /var/tmp/portage/net-libs/gnutls-3.6.11.1-r1/work/gnutls-3.6.11.1/lib/x509/common.c[_gnutls_x509_get_raw_field2]:1575
dirmngr[9162.6] DBG: gnutls:L3: ASSERT: /var/tmp/portage/net-libs/gnutls-3.6.11.1-r1/work/gnutls-3.6.11.1/lib/x509/x509.c[gnutls_x509_crt_get_subject_unique_id]:3902
dirmngr[9162.6] DBG: gnutls:L3: ASSERT: /var/tmp/portage/net-libs/gnutls-3.6.11.1-r1/work/gnutls-3.6.11.1/lib/x509/x509.c[gnutls_x509_crt_get_issuer_unique_id]:3952
dirmngr[9162.6] DBG: gnutls:L3: ASSERT: /var/tmp/portage/net-libs/gnutls-3.6.11.1-r1/work/gnutls-3.6.11.1/lib/x509/dn.c[_gnutls_x509_compare_raw_dn]:990
dirmngr[9162.6] DBG: gnutls:L3: ASSERT: /var/tmp/portage/net-libs/gnutls-3.6.11.1-r1/work/gnutls-3.6.11.1/lib/x509/dn.c[_gnutls_x509_compare_raw_dn]:990
dirmngr[9162.6] DBG: gnutls:L3: ASSERT: /var/tmp/portage/net-libs/gnutls-3.6.11.1-r1/work/gnutls-3.6.11.1/lib/x509/dn.c[_gnutls_x509_compare_raw_dn]:990
dirmngr[9162.6] DBG: gnutls:L3: ASSERT: /var/tmp/portage/net-libs/gnutls-3.6.11.1-r1/work/gnutls-3.6.11.1/lib/x509/dn.c[_gnutls_x509_compare_raw_dn]:990
dirmngr[9162.6] number of system provided CAs: 142
dirmngr[9162.6] DBG: gnutls:L5: REC[0x7fd5a400c360]: Allocating epoch #0
dirmngr[9162.6] DBG: gnutls:L2: added 6 protocols, 29 ciphersuites, 18 sig algos and 9 groups into priority list
dirmngr[9162.6] DBG: Using TLS library: GNUTLS 3.6.11
dirmngr[9162.6] DBG: http.c:connect_server: trying name='keys.openpgp.org' port=443
dirmngr[9162.6] DBG: dns: resolve_dns_name(keys.openpgp.org): Success
dirmngr[9162.6] error creating socket: Address family not supported by protocol
dirmngr[9162.6] error connecting to 'https://keys.openpgp.org:443': Address family not supported by protocol
dirmngr[9162.6] DBG: gnutls:L13: BUF[HSK]: Emptied buffer
dirmngr[9162.6] DBG: gnutls:L5: REC[0x7fd5a400c360]: Start of epoch cleanup
dirmngr[9162.6] DBG: gnutls:L5: REC[0x7fd5a400c360]: End of epoch cleanup
dirmngr[9162.6] DBG: gnutls:L5: REC[0x7fd5a400c360]: Epoch #0 freed
dirmngr[9162.6] marking host 'keys.openpgp.org' as dead
dirmngr[9162.6] host 'keys.openpgp.org' marked as dead
dirmngr[9162.6] command 'KS_PUT' failed: No keyserver available
dirmngr[9162.6] DBG: chan_6 -> ERR 167772346 No keyserver available <Dirmngr>
dirmngr[9162.6] DBG: chan_6 <- BYE
dirmngr[9162.6] DBG: chan_6 -> OK closing connection
dirmngr[9162.6] handler for fd 6 terminated

Could it be that the system installed CAs are not sufficient for the TSL handshake? But then also curl should fail on that host. But curl https://keys.openpgp.org is fine.

On Solaris, the test errors are because of:

USAGE
       Because of the impact on system resources, the use of mlock() and
       munlock() is restricted to users with the {PRIV_PROC_LOCK_MEMORY}
       privilege.

OK, I identified the problem on OpenIndiana. The inclusion of <unistd.h> causes inclusion of <sys/types.h> before config.h. I'm going to fix this.

this looks to me like a problem with the TLS handshake -- it looks like this is a response coming from the TLS stack -- as rfc 8446 says, alert 49 is access_denied:

Some users of ours wanted to use KDF with their OpenPGP smart cards. Could you tell when solution to this issue could be expected?
Additionally, is there any workaround for the current state? Perhaps based on T3823, or on derived [1]? To which values the PINs had to be set?

I have added standard-resolver and debug network to the dirmngr.conf, killed the running dirmngr:

I believe "geometry" field value from [SignEncryptFilesWizard] can help in debug.
But I'm not sure about posting it here: does it contain any sensitive info?

Result of renaming:
It helped, but only for 1st run. Then problem occurs again.
I've tried to restart the app, but it doesn't help.

Thanks for the report. I have observed that the Window is sometimes opened in the background so I accept that this is an issue for Kleopatra somehow and we need to look into it. I know that your problem is a bit different but that is related.

I've downgraded to gpg4win-3.1.10 - still be reproducible...

FWIW, I found an open xterm with my query from last week:

For GNU/Linux or GNU/kFreeBSD system, libgcrypt 1.8 with libgpg-error 1.36 has no problem in Debian build:
https://buildd.debian.org/status/package.php?p=libgcrypt20

In solaris11openindiana-log2, we have two errors: one for ulong, and another for ushort.
I fixed the former. It is because of our mistake of using ulong before it is handled by libgcrypt/src/types.h. In the first place, it is implemented by "unsigned long", so, there is no need to use ulong here.

@Valodim: I am pretty sure that last week it resolved only to a v4 address; today (and from another network and resolver) I get the same addresses as you.

that does look like your host can resolve domains for ipv6 addresses, but can't actually connect to them. what does host keys.openpgp.org say? And ip a?

Thanks. I see the situation for Solaris 11 Openindiana. In master (will be 1.9.0), it has no problem.
We need to fix in 1.8. I will.

Here are the logs. The package was configured with
CC="gcc -m64 -O2 -D_XOPEN_SOURCE=700"

Please give us log for Solaris 11 Openindiana.

I think that this ticket and https://bugs.debian.org/346241 handle different things, although both do key selection.

but keys.openpgp.org resolves only to a v4 address.

This is also https://bugs.debian.org/346241

ping keys.openpgp.org

As far as I know this is a v4 only network. I tried what you said and get this log:

2020-01-17 15:39:33 dirmngr[18656.6] DBG: chan_6 <- END
2020-01-17 15:39:33 dirmngr[18656.6] DBG: dns: libdns initialized
2020-01-17 15:39:33 dirmngr[18656.6] DBG: dns: getsrv(_pgpkey-https._tcp.keys.openpgp.org) -> 0 records
2020-01-17 15:39:33 dirmngr[18656.6] DBG: dns: resolve_dns_name(keys.openpgp.org): Success
2020-01-17 15:39:33 dirmngr[18656.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known]
2020-01-17 15:39:33 dirmngr[18656.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known]
2020-01-17 15:39:33 dirmngr[18656.6] number of system provided CAs: 142
2020-01-17 15:39:33 dirmngr[18656.6] DBG: dns: resolve_dns_name(keys.openpgp.org): Success
2020-01-17 15:39:33 dirmngr[18656.6] error creating socket: Address family not supported by protocol
2020-01-17 15:39:33 dirmngr[18656.6] error connecting to 'https://keys.openpgp.org:443': Address family not supported by protocol
2020-01-17 15:39:33 dirmngr[18656.6] marking host 'keys.openpgp.org' as dead
2020-01-17 15:39:33 dirmngr[18656.6] host 'keys.openpgp.org' marked as dead
2020-01-17 15:39:33 dirmngr[18656.6] command 'KS_PUT' failed: No keyserver available
2020-01-17 15:39:33 dirmngr[18656.6] DBG: chan_6 -> ERR 167772346 No keyserver available <Dirmngr>
2020-01-17 15:39:33 dirmngr[18656.6] DBG: chan_6 <- BYE
2020-01-17 15:39:33 dirmngr[18656.6] DBG: chan_6 -> OK closing connection
2020-01-17 15:39:33 dirmngr[18656.6] handler for fd 6 terminated

The problem is likely that you don't have IPv4 support but keys.openpgp.org resolves only to a v4 address.
You should also use

An updated build is available here: https://files.gpg4win.org/Beta/gpgol/2.4.6-beta3/

thanks for the fix, @aheinecke ! can you post screenshots of the changes? or do you have a nightly build i could test?

I have checked the eMail header of the eMail from Sender X in the Exchange mailbox of User A and I see Sender X is using Mozilla Thunderbird and I tested it with Thunderbird also, but it works for me.
I cannot provide all details of the eMail from Sender X because it's a customer of another customer, but I have replaced the IP addresses and other private information in the eMail header and this is the result:

thanks for the report. This is definitely a sore spot and we need to look at it again. I did some experiments a while a go trying to fix this issue but so far I was unable to get to stable results so for now this is a known issue.
I'm a bit suprised that the workaround with not having the mail open does not work for you.

This again,...
That error always occurs when the Exchange Server is unhappy with the structure of our PGP/MIME Mails. It has nothing to do with S/MIME, that is only because Exchange only knows about S/MIME, so our PGP/MIME Mails also claim to be S/MIME mails.

Display now looks good to me in all cases. We still keep the subject when a reply / forward is done, but that is the same as before. To do this properly I would have to actually do the protected headers sending,.. as then I could automatically flag such a message to be sent with protected headers. But that would be a new feature and I rather work on properly doing BCC sending as the next privacy enhancing feature.

Reported.

You may.. Comments were relevant. Bye.

FWIW, the GTK and QT pinentries do have a qualitybar. However is is only enabled:

At least one configuration error I could identify by myself: Kleopartra -> GnuPG-System -> Smartcard -> Connecting Reader with port N. If it is written: Yubico YubiKey OTP+FIDO+CCID 0 then Yubikey is recognized. I forgot to write "Yubico Yubikey" at the beginning and the "0" at the end. Now smart cards and Yubikeys are working for gpg. What is still a problem is SSH. A SSH key is on smart card or the Yubikey.

In T4809#131931, @werner wrote:

BTW, the qualitybar is not shown by default, only if you configure sme of the extra password checks. We may even remove it completely because it leads to wrong assumption on why a passphrase is required.

@Rycky_Tigg cases 1, 2, and 3 that you document here each show the behavior that i would expect from pinentry-gnome3, given the definition of its Assuan-based API and its use of gcr-prompter. (i'm assuming that in case 3 the user just waited longer than the allowed timeout)

Thank you for resolving this issue! I am successfully using version 2.2.19 from the gnupg (2.2.19-1~bpo10+1) package of Debian Backports.

"more specific about what you think is wrong"; From https://bugs.kde.org/show_bug.cgi?id=412569 copied)/pasted:

BTW, the qualitybar is not shown by default, only if you configure sme of the extra password checks. We may even remove it completely because it leads to wrong assumption on why a passphrase is required.

pinentry-gnome uses gcr's gcr_prompt_set_password_new to prompt for a new password, and ignores the SETQUALITYBAR assuan command.

It seems that gnome-keyring-daemon has some incompatible changes which breaks that version of pinentry-gnome. Or GKR has not been setup properly. I'd suggest to use pinentry-gtk until folks with knowledge about Gnome folks have figured out what is going wrong.

Hey. As reference – Complete set of features while run in Windows.

Please describe which features are missing.

Werner, no silly questions exist, only silly answers are existing. However, Yubikey is enabled for usb. I using Yubikey Manager a GUI, for the USB interface it is enabled: OTP, FIDO, FIDO U2F, OpenPGP, PIV and OATH. Thanks also for the suggested command line test. Indeed an error code shows up:

Maybe a silly question, but let's be sure: Is the Openpgp app enabled on that Yubikey and is it enabled for usb? I can't remember the Yubikey commands on how to check this but tehre should even be a GUI. These days I use the new gpg-card tool to manage my Yubikeys (from GnuPG master).

Please, note the following uncommon behavior:

I'll keep this on needs triage because I don't know what the issue could be. I have a yubikey 5 at hand and just tested it with Gpg4win 3.1.11. It works without problems.

note that it *does* sometimes hide the legacy display part, for some messages, including unfortunately-complex -- that's good! -- but maybe this points to some internal inconsistency:

Sorting the table is a good idea for reproducibility, since otherwise the tree depends on the order of the arguments to asn1-gentables, which are generated with a wildcard expansion that might be shell or file system dependent.

Frankly, I am not sure why we sort that table at all. Your patch does not harm, though.