Bug 887287 – net-misc/curl: .onion resolution behaviour differs with USE={-,}adns

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Kaizu Shibata 2022-12-20 07:15:41 UTC]

I run several Gentoo sytems behind a Tor transproxy which prevents DNS leakage, and I have been doing this for a long time. The latest curl package has had me update into a bug where it refuses to resolve onion addresses. It only resolves them now if a SOCKS hostname is specified to ensure onions are always resolved through Tor. I don't use SOCKS and can no longer resolve onion addresses which has broken my systems, and left me stuck in the water. 

I have this topic on Gentoo forums...

https://forums.gentoo.org/viewtopic-p-8765095.html#8765095

These are the bugs...
https://github.com/curl/curl/issues/543
https://datatracker.ietf.org/doc/html/rfc7686

I recommend with urgency that a patch be made for the curl ebuild for the 'transproxy' useflag so that I can disable this functionality. The bugfix to curl and RFC 7686 mentioned above only effects people using Tor via SOCKS and it prevents this kind of DNS resoltion being done through the system DNS servers.

This breaks my system, and I can't just fix it by changing things so curl uses SOCKS. SOCKS simply is not there, as I only have a transproxy available.

[Comment 1 Sam James 2022-12-20 07:30:59 UTC]

It's unclear to me:
1. Why this broke recently (the curl bug linked last has activity in 2020)
2. What configuration options we actually need to pass to curl in the ebuild? Do they exist...?

[Comment 2 Sam James 2022-12-20 07:31:21 UTC]

(In reply to Sam James from comment #1)
> It's unclear to me:
> 1. Why this broke recently (the curl bug linked last has activity in 2020)
> 2. What configuration options we actually need to pass to curl in the
> ebuild? Do they exist...?

(If they don't exist, please file a bug upstream asking them to add one.)

[Comment 3 Sam James 2022-12-20 07:34:13 UTC]

Right, re-reading your forum post, I see you don't know what change caused it.

You can then two things:
1. Report a bug upstream to curl explaining your use case and requesting an option, and
2. git bisect curl between a known good and known bad version.

[Comment 4 Kaizu Shibata 2022-12-20 07:41:47 UTC]

I decided to get the upstream tarball from curls website for version 7.86.0 and when I compiled it I could run the binary in that directory. This worked and was able to resolve the onion domain and so I installed it to /usr/local/bin/curl and I removed /usr/bin/curl on my testing system. After doing this it once again instantly fails to resolve onion addresses. Something has to be wrong with my environment or something!

Here is my environment for my testing system: http://dpaste.com/AHQYDPH8X

[Comment 5 Kaizu Shibata 2022-12-20 07:52:43 UTC]

I just took a wild stab in the dark and fixed it this way, and it now tests as working!

USE="-adns" emerge -1av curl

Sorry.

[Comment 6 Sam James 2022-12-21 19:25:51 UTC]

(In reply to Kaizu Shibata from comment #5)
> I just took a wild stab in the dark and fixed it this way, and it now tests
> as working!
> 
> USE="-adns" emerge -1av curl
> 
> Sorry.

Ah. See bug 699632 (and bug 853973) for the details there for why it's default on. Not sure we can do much about this then, but glad you're able to turn it off and keep things working on your end.

[Comment 7 Kaizu Shibata 2022-12-25 08:02:00 UTC]

I would recommend a global USE flag for people who are certain their system is safe from DNS leakage. It could be called 'dnssafe' or something like that, and it should prevent these kind of issues.

[Comment 8 Matt Jolly 2023-03-07 17:44:38 UTC]

This is a bit of a mess; I haven't actually tested or validated your results, but my suspicion is that the adns/c-ares backend was updated at some point to be RFC 7686-compliant. A quick google confirms this happened in 2018:

https://github.com/c-ares/c-ares/issues/196

As this is the default in Gentoo, curl/libcurl will send a request to c-ares and get back "NXDOMAIN" as per the RFC:

> Name Resolution APIs and Libraries (...) MUST either respond to requests for
> .onion names by resolving them according to [tor-rendezvous] or by responding
> with NXDOMAIN.

When you disable that, (as you have here) curl simply sends the request directly using system DNS.

TL;DR - this shouldn't have worked (RFC 7686) and I've submitted a patch upstream to make curl intentionally fail when any `.onion` tld needs to be resolved.

[Comment 9 Larry the Git Cow 2023-03-15 05:04:59 UTC]

The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f7a9dcc44364ee6ae07f6bfa4c48661736d3d05f

commit f7a9dcc44364ee6ae07f6bfa4c48661736d3d05f
Author:     Matt Jolly <[e-mail]>
AuthorDate: 2023-03-09 13:19:13 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2023-03-15 05:04:42 +0000

    net-misc/curl: add 7.88.1-r2
    
    cURL attempts to resolve .onion tlds and depending on USE flags
    may leak that you're using Tor.
    
    This commit adds the upstream patch for RFC7686 compliance a
    little early as it may not make the next cURL release.
    
    Closes: https://bugs.gentoo.org/887287
    
    Signed-off-by: Matt Jolly <[e-mail]>
    Signed-off-by: Sam James <[e-mail]>

 net-misc/curl/curl-7.88.1-r2.ebuild                | 307 +++++++++++++++++++++
 .../curl/files/curl-7.88.1-onion-resolution.patch  | 132 +++++++++
 2 files changed, 439 insertions(+)