No reply to my question, thus it seems not to be important. Closing.
Note that replying to this will re-open the bug.

FWIW: In GnuPG we have for example this in the configure script

*-*-hpux*)
    if test -z "$GCC" ; then
        CFLAGS="-Ae -D_HPUX_SOURCE $CFLAGS"
    fi

IF it makes things easier we may add a simlar case for macOS. But we need to do
this for many packages, I think.

Thanks for the report. I can replicate this.

What you see are bogus subkey binding signatures. The clean function only
worked on user ID packets and their self signatures. A comment in the code
stated this. However, I see no reason why we should not remove those bogus
signatures.
Commit 3563237 does this now.

Thanks.

Thanks for the dumps. I was not able to get the permission denied errors. The
ENETDOWN errors on my site where due to a IPv6 not being enabled for Tor (during
most of my older tests I used the Torbrowser).

Anyway, With the patches from today, things are working much better now.
Please give it a try.

• Original Message ------

From: "Andre Heinecke via BTS" <gnupg@bugs.g10code.com>
To: aheinecke@intevation.de; dr_it@mailbox.org
Sent: 16-1-2017 15:35:25
Subject: [issue2892] GpgOL: Encrypt is selected on Reply/Forward

Fixed in 8e3aa3204e74e8d7a7538e0d0f04e555f140131b.

Well if my wife is representable for a lot of "ordinary" users (and i
think she is), it will be hard to explain it to them and after that let
them remembering it or the future :(
Also this will not be the solution (i think) for when i want to move a
lot of mails (use case: mailbox space full, so want to archive older
mail to local folder by moving them from imap folder)?

Oops wrong, 251 did not yet have it, 253 will have it. Forgot to push the change.

I've added the option. It's in the latest beta (251) from files.gpg4win.org
A beta installer containing this version will be published likely this or next week.

We are aiming for a stable release middle of march.

While this f.e. for my wife will not work, not user friendly enough :(

I'm really really sad to hear that. I was hoping this was acceptable to
"non-technical" users just one of the quirks users eventually get used too :-(

I tried to think about this more but I don't see another solution then:
a) Prevent Outlook from saving any changes after a message was decrypted

• This is the current behavior and leads to the problem.

b) When Outlook want's to save a mail remove the plaintext, restore the
encrypted contents and save the changes to the encrypted mail.

• This has a serious downside that it does trigger a full resync of the mail

because outlook thinks the attachments have changed. When closing Outlook this
also somehow brought Outlook in a state that it kept indefitely syncing a single
mail :-/. It also broke the signatures on singed only mails because the MIME
boundarys could not be restored. In general I found it much more unstable and
buggy then a clear "Sorry you can't do that". :-/

Ok, I found the problem, as we handle the selection changed event in the
messagelist we were trying to decrypt messages even if they were not loaded /
visible in the preview window. That caused a weird state and several errors.

I've fixed it now so that we only decrypt items when a selection changes in an
Explorer that has a visible preview pane. I'll let you know once a beta with
that fix is released.

Thanks again,
Andre

I'm assuming it is. Feel free to reopen this bug if this still causes problems
for you.

I tried to reproduce this problem, and failed. Can you provide more information
about your build environment, and how to reproduce this problem?

I would also be fine just to add -L to any call to /bin/pwd in our tests. Note
that most tests are in tests/openpgp, and that set of tests changed radically
since 2.1.7, and the new version should not be affected (tests/ and tests/pkits
are mostly stubs anyway).

Fixed in 0e242278dfaa64ce31a45b72f5fa0806a3dba898.

In the man page of gpg(1) it says:

--export-options parameters

export-minimal
    Export  the  smallest key possible. This removes all signatures except the

most recent self-signature on each user ID. [..]

If you actually do this to my key however, you will see that the resulting
output contains Nicolas' signature on my key, which is against what
"export-minimal" is supposed to do.

We configure the build with -D_DARWIN_C_SOURCE=900000L on our macOs box. Not
sure if this is the proper thing to do, and/or if we should just always set that
when we build on Darwin in configure.

Note that each of these outputs is preceded by a KEY_CONSIDERED lined (for the
same key). Since the TOFU conflict information is per key, I'd expect an
implementation to say: Oh, there is already some conflict information for key X.
This must be a more up to date version, so I'll delete that first instead of
appending to it. Is this an unreasonable expectation?

In my Opinion it is. There is a technical, (i guess) unintentional, reason for
the multiple outputs, they
don't convey useful information. So I would consider this Output a Bug and
implementations
working like you describe it to be a workaround for that bug.

Getting firs wrong information and later updating it with the correct
information makes implementations
more complicated and error prone and currently is not handled in GPGME.

Also in GPGME we just want to figure out the TOFU Info for all the UID's of the
key used
to check the signature. We don't want information about conflicting keys. We need
a reliable way to filter this out. So I have a patch that ignores all TOFU_USER
lines
that don't match the fingerprint of the signature but still that breaks because
the "Update"
is not handled.

Please describe exactly what you mean. I can't see from this report why it and
what does not work or leak information.

KEY_CONSIDERED is orthogonal to the TOFU stats. Thus GPGME thus not evaluate it
to learn about the TOFU state.

Attached example output after patch is applied. Now User4 has full validity like
expected, and the debug output shows a match for User4's email address (NOTE:
the debug output has 'YES' for no match and 'NO' for successful match)

D406: 944_example.patch

Attached example patch prevents escaping normal lowercase letters.

Note that this isn't a general solution, though it does solve the issue for me.
For example, some email addresses have numbers (I don't know if having backslash
before numbers is an issue like it is for letters)

Attached example are the following setup:

user1 tsign user2 with full trust, depth 1, domain="customer.com". User2 signs
user3 through user5 (regular signatures). User4 is at customer.com, users 3 and
5 are at example.com.

I had a chance to run this test against 2.1.17 today as that version has been recently
released via homebrew. The error is essentially the same, but the debug output is
indeed slightly different. Now the debug line numbers are different and there is the
addition of string=''; in the debug output. I didn't notice anything else that looked
significantly different.

/tmp$ gpg2 --verify TrueTimeStamp-certificate-4793.txt
gpg: Signature made Wed Nov 23 23:08:29 2016 PST
gpg: using DSA key 0x6F3B2E6AB748A8F8
gpg: Good signature from "TrueTimeStamp <signing-department@TrueTimeStamp.org>"
[marginal]
gpg: DBG: tofu.c:3068: strtoul failed for TOFU DB data; returned string (string='';
tail=''): Invalid argument
gpg: DBG: tofu.c:3070: strtoul failed for TOFU DB data; returned string (string='';
tail=''): Invalid argument
gpg: signing-department@truetimestamp.org: Verified 1 signature in the past

5 weeks.  Encrypted 0 messages.

gpg: Warning: we've only seen one message signed using this key and user id!
gpg: Warning: you have yet to encrypt a message to this key!
gpg: Warning: if you think you've seen more signatures by this key and user

id, then this key might be a forgery!  Carefully examine the email address
for small variations.  If the key is suspect, then use
  gpg --tofu-policy bad 83289060F40DED088CF246B56F3B2E6AB748A8F8
to mark it as being bad.

gpg: WARNING: This key is not certified with sufficiently trusted signatures!
gpg: It is not certain that the signature belongs to the owner.
Primary key fingerprint: 8328 9060 F40D ED08 8CF2 46B5 6F3B 2E6A B748 A8F8

It's true that the user is listed 4 times, but this is because tofu.c:get_trust
is called four times. For instance, the first time it is called to show the
"gpg: Good signature from "tofu_conflict@example.com" [marginal]" line, and the
second time is it called to register the signature (tofu_register_signature).
This also explains why the signature count increases between the first and
second versions.

Note that each of these outputs is preceded by a KEY_CONSIDERED lined (for the
same key). Since the TOFU conflict information is per key, I'd expect an
implementation to say: Oh, there is already some conflict information for key X.
This must be a more up to date version, so I'll delete that first instead of
appending to it. Is this an unreasonable expectation?

It should be possible to change the behavior to only output the TOFU_STATS lines
if a TOFU_STATS_LONG line is also output (but I need to think about it some
more). Would this be better?

Well if this works, i could live with it temporary, but not indefinitely. While
this f.e. for my wife will not work, not user friendly enough :(
So hopefully you can work this out somewhere in the future, but from you reply i
understand this is not something i should expect soon (or ever)...
I'm also testing EM Client which has promised to come with PGP support, so will
wait a little longer and then decide which (best available) way i'm going to use
(now temporary disabled online encryption).

Thank you for making this an optional setting! Any idea in what release this
will be planned?

Thanks for testing the beta and your report. I can reproduce some weird crashes
when the preview pane is disabled, too. It's not 100% for me but some times
after sending a crypto mail sometimes later it crashes, sometimes when switching
folders it crashes, very weird. Sometimes the decrypted contents of a mail are
not shown after opening it.

And with preview everything is fine.

Looking into it.

Yes, We fixed that. Sorry I didn't see your bugreport then.

Btw. You can also send such E-Mails encrypted with GpgOL nowadays :-)

http://files.intevation.de/users/aheinecke/gpgol-kitten.png

As a user are these workarounds acceptable to you. < This should have been a
question ;-)

Hi,

Again thanks for your feedback on the GpgOL-Beta. You might want to give the
latest one from http://files.gpg4win.org/Beta/gpgol/ (beta-246 currently) a try
it's much improved and there were several potential crashes fixed. I'm currently
working on an improved certificate selection and certificate details dialog and
then we will release a new gpg4win beta with that.

To your problem: Yes this is a serious problem, but we currently don't have a
solution for this, only a workaround. The workaround is to do the Copy / Move /
Modify while the mail is not shown decrypted. In the current beta:

If you unselect the crypto mail you can move / copy / modify (e.g. flag) the
message through right clicking it.

To save the message as .msg you can drag & drop it (even when opened) to a
target windows explorer folder.

An opened messaage can still be moved to trash. Any other moves will sadly
result in an "File name or directory name is not valid" error.

We inform the user about this only when he tries to modify a mail (see attached
screenshot) we should probably also do that for other things.

The underlying problem is pretty complicated and we spent a lot of time
struggling with that, but basically we must prevent outlook from saving the
decrypted content. Otherwise the mail will break and can no longer be shown in
other MUAs. And worse the Plaintext may be resynced to the server. One
workaround we had was to restore the crypto contents before outlook saved the
mail then decrypt it again. But this caused several other problems. E.g. Outlook
resynced the mail to imap and Signatures might be broken, and if we did this at
the wrong time outlook would do into an indefinite sync loop. So we decided
better to have clear workarounds and be otherwise stable then to have buggy /
strange behavior.

As a user are these workarounds acceptable to you.

Hi,

Thanks for feedback on the beta!

This was actually a feature request and I consider this a feature. Because it's
a security usability problem if someone replies to an encrypted mail in plain
text with a full quote of the originally encrypted mail. KMail for example does
the same preselection.

But I see your usecase. I'll make it optional (a config setting) but the default
will be "enabled".

For what it's worth i think WKD checks should be done even more regularly then
when they are explicitly triggered thorugh locate keys because we need to see
updates on key rollover / revocation of keys or uids. Something like the
parcimonie style auto-key-refesh that is currently planned.

But yes re fetching on locate-keys if the key / uid for key-locate is expired
would be a first step.

gpg: keybox '/home/dkg/tmp/tmp.0Ew9D45cz7/gpg/pubring.kbx' created
gpg: /home/dkg/tmp/tmp.0Ew9D45cz7/gpg/trustdb.gpg: trustdb created
gpg: key 7638D0442B90D010: public key "Debian Archive Automatic Signing Key
(8/jessie) <ftpmaster@debian.org>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1
S # hosttable (idx, ipv6, ipv4, dead, name, time):
S # 0 hkps.pool.sks-keyservers.net
S # . hkps.pool.sks-keyservers.net
S # . --> 15 14 13 12 11 10 19 18* 17 16 9 8 7 6 5 4 3 2 1
S # 1 6 [2a02:898:31:0:48:4558:73:6b73]
S # 2 6 [2a01:4a0:59:1000:223:9eff:fe00:100f]
S # 3 6 [2a00:14b0:4200:3000:27::27]
S # 4 6 [2606:9500:201:1::141]
S # 5 6 [2606:1c00:2802::b]
S # 6 6 [2001:bc8:4700:2300::10:f15]
S # 7 6 [2001:bc8:2515::1]
S # 8 6 [2001:720:418:caf1::8]
S # 9 6 [2001:470:1:116::6]
S # 10 4 216.66.15.2
S # 11 4 212.12.48.27
S # 12 4 209.135.211.141
S # 13 4 192.94.109.73
S # 14 4 163.172.29.20
S # 15 4 130.206.1.8
S # 16 4 94.142.242.225
S # 17 4 92.43.111.21
S # 18 4 51.15.53.138
S # 19 4 37.191.238.78
OK
2017-01-12 11:35:25 dirmngr[833] listening on socket
'/home/dkg/tmp/tmp.0Ew9D45cz7/gpg/S.dirmngr'
2017-01-12 11:35:25 dirmngr[834.0] permanently loaded certificates: 0
2017-01-12 11:35:25 dirmngr[834.0] runtime cached certificates: 0
2017-01-12 11:35:25 dirmngr[834.0] failed to open cache dir file
'/home/dkg/tmp/tmp.0Ew9D45cz7/gpg/crls.d/DIR.txt': No such file or directory
2017-01-12 11:35:25 dirmngr[834.0] creating directory
'/home/dkg/tmp/tmp.0Ew9D45cz7/gpg/crls.d'
2017-01-12 11:35:25 dirmngr[834.0] new cache dir file
'/home/dkg/tmp/tmp.0Ew9D45cz7/gpg/crls.d/DIR.txt' created
2017-01-12 11:35:26 dirmngr[834.6] handler for fd 6 started
2017-01-12 11:35:26 dirmngr[834.6] connection from process 831 (1000:1000)
2017-01-12 11:35:26 dirmngr[834.6] DBG: dns: libdns initialized (tor mode)
2017-01-12 11:35:27 dirmngr[834.6] DBG: dns:
getsrv(_pgpkey-https._tcp.hkps.pool.sks-keyservers.net) -> 0 records
2017-01-12 11:35:27 dirmngr[834.6] DBG: dns: libdns initialized (tor mode)
2017-01-12 11:35:28 dirmngr[834.6] DBG: dns:
resolve_dns_name(hkps.pool.sks-keyservers.net): Success
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2a02:898:31:0:48:4558:73:6b73]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2a01:4a0:59:1000:223:9eff:fe00:100f]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2a00:14b0:4200:3000:27::27]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2606:9500:201:1::141]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2606:1c00:2802::b]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:bc8:4700:2300::10:f15]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:bc8:2515::1]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:720:418:caf1::8]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:470:1:116::6]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '216.66.15.2'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '212.12.48.27'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '209.135.211.141'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '192.94.109.73'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '163.172.29.20'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '130.206.1.8'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '94.142.242.225'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '92.43.111.21'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '51.15.53.138'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '37.191.238.78'
2017-01-12 11:35:28 dirmngr[834.6] DBG: http.c:connect_server: trying
name='51.15.53.138' port=443
2017-01-12 11:35:28 dirmngr[834.6] DBG: dns: resolve_dns_name(51.15.53.138): Success
2017-01-12 11:35:31 dirmngr[834.6] DBG: http.c:1706:socket_new: object
0x00007f57e400a5d0 for fd 8 created
2017-01-12 11:35:34 dirmngr[834.6] DBG: http.c:request:
2017-01-12 11:35:34 dirmngr[834.6] DBG: >> GET
/pks/lookup?op=get&options=mr&search=0x126C0D24BD8A2942CC7DF8AC7638D0442B90D010
HTTP/1.0\r\n
2017-01-12 11:35:34 dirmngr[834.6] DBG: >> Host:
hkps.pool.sks-keyservers.net:443\r\n
2017-01-12 11:35:34 dirmngr[834.6] DBG: http.c:request-header:
2017-01-12 11:35:34 dirmngr[834.6] DBG: >> \r\n
2017-01-12 11:35:37 dirmngr[834.6] handler for fd 6 terminated
2017-01-12 11:35:37 dirmngr[834.6] handler for fd 6 started
2017-01-12 11:35:37 dirmngr[834.6] connection from process 841 (1000:1000)
2017-01-12 11:35:37 dirmngr[834.6] handler for fd 6 terminated

gpg: keybox '/home/dkg/tmp/tmp.swbfPRERsO/gpg/pubring.kbx' created
gpg: keyserver receive failed: Server indicated a failure
S # hosttable (idx, ipv6, ipv4, dead, name, time):
S # 0 hkps.pool.sks-keyservers.net
OK
2017-01-12 11:36:01 dirmngr[851] listening on socket
'/home/dkg/tmp/tmp.swbfPRERsO/gpg/S.dirmngr'
2017-01-12 11:36:01 dirmngr[852.0] permanently loaded certificates: 0
2017-01-12 11:36:01 dirmngr[852.0] runtime cached certificates: 0
2017-01-12 11:36:01 dirmngr[852.0] failed to open cache dir file
'/home/dkg/tmp/tmp.swbfPRERsO/gpg/crls.d/DIR.txt': No such file or directory
2017-01-12 11:36:01 dirmngr[852.0] creating directory
'/home/dkg/tmp/tmp.swbfPRERsO/gpg/crls.d'
2017-01-12 11:36:01 dirmngr[852.0] new cache dir file
'/home/dkg/tmp/tmp.swbfPRERsO/gpg/crls.d/DIR.txt' created
2017-01-12 11:36:02 dirmngr[852.6] handler for fd 6 started
2017-01-12 11:36:02 dirmngr[852.6] connection from process 849 (1000:1000)
2017-01-12 11:36:02 dirmngr[852.6] DBG: dns: libdns initialized (tor mode)
2017-01-12 11:36:12 dirmngr[852.6] DBG: dns:
getsrv(_pgpkey-https._tcp.hkps.pool.sks-keyservers.net): Server indicated a failure
2017-01-12 11:36:12 dirmngr[852.6] command 'KS_GET' failed: Server indicated a
failure <Unspecified source>
2017-01-12 11:36:12 dirmngr[852.6] handler for fd 6 terminated
2017-01-12 11:36:12 dirmngr[852.6] handler for fd 6 started
2017-01-12 11:36:12 dirmngr[852.6] connection from process 854 (1000:1000)
2017-01-12 11:36:12 dirmngr[852.6] handler for fd 6 terminated

gpg: keybox '/home/dkg/tmp/tmp.vOaRFt7s4L/gpg/pubring.kbx' created
gpg: keyserver receive failed: Permission denied
S # hosttable (idx, ipv6, ipv4, dead, name, time):
S # 0 hkps.pool.sks-keyservers.net
S # . hkps.pool.sks-keyservers.net
S # . --> 15 14 13 12 11 10 19 18 17 16 9 8 7 6 5 4 3 2* 1
S # 1 6 [2a02:898:31:0:48:4558:73:6b73]
S # 2 6 [2a01:4a0:59:1000:223:9eff:fe00:100f]
S # 3 6 [2a00:14b0:4200:3000:27::27]
S # 4 6 [2606:9500:201:1::141]
S # 5 6 [2606:1c00:2802::b]
S # 6 6 [2001:bc8:4700:2300::10:f15]
S # 7 6 [2001:bc8:2515::1]
S # 8 6 [2001:720:418:caf1::8]
S # 9 6 [2001:470:1:116::6]
S # 10 4 216.66.15.2
S # 11 4 212.12.48.27
S # 12 4 209.135.211.141
S # 13 4 192.94.109.73
S # 14 4 163.172.29.20
S # 15 4 130.206.1.8
S # 16 4 94.142.242.225
S # 17 4 92.43.111.21
S # 18 4 51.15.53.138
S # 19 4 37.191.238.78
OK
2017-01-12 11:36:23 dirmngr[866] listening on socket
'/home/dkg/tmp/tmp.vOaRFt7s4L/gpg/S.dirmngr'
2017-01-12 11:36:23 dirmngr[867.0] permanently loaded certificates: 0
2017-01-12 11:36:23 dirmngr[867.0] runtime cached certificates: 0
2017-01-12 11:36:23 dirmngr[867.0] failed to open cache dir file
'/home/dkg/tmp/tmp.vOaRFt7s4L/gpg/crls.d/DIR.txt': No such file or directory
2017-01-12 11:36:23 dirmngr[867.0] creating directory
'/home/dkg/tmp/tmp.vOaRFt7s4L/gpg/crls.d'
2017-01-12 11:36:23 dirmngr[867.0] new cache dir file
'/home/dkg/tmp/tmp.vOaRFt7s4L/gpg/crls.d/DIR.txt' created
2017-01-12 11:36:24 dirmngr[867.6] handler for fd 6 started
2017-01-12 11:36:24 dirmngr[867.6] connection from process 864 (1000:1000)
2017-01-12 11:36:24 dirmngr[867.6] DBG: dns: libdns initialized (tor mode)
2017-01-12 11:36:26 dirmngr[867.6] DBG: dns:
getsrv(_pgpkey-https._tcp.hkps.pool.sks-keyservers.net) -> 0 records
2017-01-12 11:36:26 dirmngr[867.6] DBG: dns: libdns initialized (tor mode)
2017-01-12 11:36:27 dirmngr[867.6] DBG: dns:
resolve_dns_name(hkps.pool.sks-keyservers.net): Success
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2a02:898:31:0:48:4558:73:6b73]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2a01:4a0:59:1000:223:9eff:fe00:100f]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2a00:14b0:4200:3000:27::27]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2606:9500:201:1::141]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2606:1c00:2802::b]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:bc8:4700:2300::10:f15]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:bc8:2515::1]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:720:418:caf1::8]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:470:1:116::6]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '216.66.15.2'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '212.12.48.27'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '209.135.211.141'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '192.94.109.73'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '163.172.29.20'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '130.206.1.8'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '94.142.242.225'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '92.43.111.21'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '51.15.53.138'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '37.191.238.78'
2017-01-12 11:36:27 dirmngr[867.6] DBG: http.c:connect_server: trying
name='2a01:4a0:59:1000:223:9eff:fe00:100f' port=443
2017-01-12 11:36:27 dirmngr[867.6] DBG: dns:
resolve_dns_name(2a01:4a0:59:1000:223:9eff:fe00:100f): Success
2017-01-12 11:36:27 dirmngr[867.6] can't connect to
'2a01:4a0:59:1000:223:9eff:fe00:100f': Permission denied
2017-01-12 11:36:27 dirmngr[867.6] error connecting to
'https://[2a01:4a0:59:1000:223:9eff:fe00:100f]:443': Permission denied
2017-01-12 11:36:27 dirmngr[867.6] command 'KS_GET' failed: Permission denied
2017-01-12 11:36:27 dirmngr[867.6] handler for fd 6 terminated
2017-01-12 11:36:27 dirmngr[867.6] handler for fd 6 started
2017-01-12 11:36:27 dirmngr[867.6] connection from process 869 (1000:1000)
2017-01-12 11:36:27 dirmngr[867.6] handler for fd 6 terminated

Here's the reproducer script i'm using:

--------

#!/bin/bash

WORKDIR=$(mktemp -d)
export GNUPGHOME="$WORKDIR/gpg"
mkdir -p -m 0700 "$GNUPGHOME"
cat > "$GNUPGHOME/dirmngr.conf" <<EOF
debug dns,network
verbose
use-tor
log-file $WORKDIR/dirmngr.log
EOF

gpg --recv 126C0D24BD8A2942CC7DF8AC7638D0442B90D010

gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye

cat "$WORKDIR/dirmngr.log"

rm -rf "$WORKDIR"

I just ran it three times in a row, and i got three different results, which
i'll paste as separate messages for easier visibility.

Can you run dirmngr with

debug dns,network
verbose

I don't think that gnutls debug is required.

They don't solve the bug for me, unfortunately. with those patches applied, i
now get "permission denied" errors:

an 11 15:57:18 alice dirmngr[20203]: DBG: gnutls:L3: ASSERT:
mpi.c[_gnutls_x509_read_uint]:246
Jan 11 15:57:18 alice dirmngr[20203]: DBG: gnutls:L5: REC[0x7f07c0008640]:
Allocating epoch #0
Jan 11 15:57:18 alice dirmngr[20203]: can't connect to
'2a02:898:31:0:48:4558:73:6b73': Permission denied
Jan 11 15:57:18 alice dirmngr[20203]: error connecting to
'https://[2a02:898:31:0:48:4558:73:6b73]:443': Permission denied

which also don't mark the IPv6 address as dead, so they're effectively permanent
until i clear them out.

As a workaround, i've been clearing out all IPv6 addresses with this terrible hack:

0 dkg@alice:~$ cat bin/dirmngr-flush-ipv6
#!/bin/bash

drop all IPv6 keyservers from dirmngr:

gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye |\

awk '/\[.*:.*\]/{ print "keyserver --dead " $5 } ' |\
gpg-connect-agent --dirmngr

0 dkg@alice:~$

I just pushed two patches:
76fb2fe dirmngr: Mark hosts dead on ENETDOWN.
09aeac4 dirmngr: Fix Tor access for v6 addresses.
which should solve this bug.

It seems like indeed it should have been resolved. I have also resolved the issue
by moving the old headers from KDEPIMLibs 4 to a private location, and KF5
projects have apparently been updated to work with gpgme++ installed in
$prefix/include/gpgme++ .

I think this was already resolved by:

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=7302791c0d308c3284ac24a743035d27a0c0b6ba

Please let me know if it still does not work for you.

I am very sorry for this problem, was a bad mistake.

This was fixed immediately after the release but we need a new release to roll
it out.

Thanks, applied!

Forgot to give you credit / mention this bug in the commit message. Apologies
for that.

The reason why we see an EINVAL for a v6 address is that
we create the socket for AF_INET6 but then use that very socket with AF_INET to
sonnect to the socks5 proxy. Cleary a socket for v6 can't be used to connect to
a v4 address.

Good point.

Please try current master where I hopefully fixed T2451. This may also fix
this issue.

Fixed in master:

0cc975d dirmngr: Use "pgpkey-hkps" and "pgpkey-hkp" for SRV record lookups.
c2cbe2f dirmngr: Do not use a SRV record for HKP if a port was specified.

This seems to be closely related to T2451.

The ML discussion started during my fall vacation and thus scrolled out of my
sight :-(. While doing some unrelated SRV experiments yesterday, I figured the
problem myself and K_F pointed me to the discussion.

The actual cause for the bugs might be that I missed to forward-port David's
patch from 2009 for changing the service name to the 2.1 branch. I will further
investigate. The move to libdns introduced other bugs and covered the actual bug.

We should use the wrapper as long as we don't have full control over libldap
(select, timeout, etc.)