For GNU/Linux or GNU/kFreeBSD system, libgcrypt 1.8 with libgpg-error 1.36 has no problem in Debian build:
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.
# host keys.openpgp.org keys.openpgp.org has address 18.104.22.168 keys.openpgp.org has IPv6 address 2a00:c6c0:0:154:1::1 keys.openpgp.org mail is handled by 100 mail.keys.openpgp.org.
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"
$ ping keys.openpgp.org -c1 PING keys.openpgp.org (22.214.171.124) 56(84) bytes of data. 64 bytes from 126.96.36.199 (188.8.131.52): icmp_seq=1 ttl=48 time=24.1 ms
- Fix T4810: A key with only "C" capability cannot be selected as default key.
- Fix T4784: Remove referring a key by $AUTHKEYID, $ENCRKEYID, and $SIGNKEYID
- Apply a part of Tianjia Zhang patch to libgcrypt
- Improvement of selecting a private key by gpg (in case of: multiple subkeys and card):
- consider about more use cases:
- old RSA key on card, another new ECC key on card: want to use on-line card available
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.
Sun, Jan 19
but keys.openpgp.org resolves only to a v4 address.
Thanks for bug fix. I've prepared patch and send it to mailing list https://lists.gnupg.org/pipermail/gcrypt-devel/2020-January/004885.html. Let me know if Reported-by is ok/enough. I would have liked to put you as author of commit, but this Differential interface of quite horrible and does not give all the needed information (mainly "name <email>" format for git).
Fri, Jan 17
This is also https://bugs.debian.org/346241
It can force it on the outbound. https://support.symantec.com/us/en/article.tech164655.html
It also allow SIMME pass-through. https://support.symantec.com/us/en/article.tech166867.html
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/
Implemented in master.
It looks good.
Thu, Jan 16
thanks for the fix, @aheinecke ! can you post screenshots of the changes? or do you have a nightly build i could test?
BTW, I just pushed some new features to maste for the gpg-card tool. You can now do
Yes that is fine with me.
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.
Is this about any special version of Symantec? As far as I knew Symantec Endpoint Security Desktop (or whatever they call it nowadays) supports reading PGP/MIME and even sending it if forced.
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.
Well that is due to "--debug packet" (aka --debug 1). We have this code
With new "KEYINFO" command of scdaemon, finally, we can move on to support better selection of signing key.
(Note: having a private key on multiple cards had already been solved in T4301: Handling multiple subkeys on two SmartCards.)
In master, it has been implemented.
The first "SCD SERIALNO" command let scdaemon re-scan smartcards/tokens.
With new "KEYINFO" command in scdaemon, a list of card keys can be retrieved by:
There is no use cases for $SIGNKEYID.
$ENCRKEYID use case have been removed.
Fixed and backported.