1634053 - On Linux, DNS resolution (DNS.jsm) of addons and OpenPGP code fails, because the code looks for libresolv.so which isn't present in most user installs

Status: RESOLVED FIXED

(Thunderbird :: Add-Ons: Extensions API, defect, P1)

Description

[strassenbahn]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

If shared library libresolv.so (symlink) does not exist add-on name resolution via DNS.jsm does not work.

Actual results:

Using the latest Ubuntu 20.04 Version I installed thunderbird and the two addons TBSync and "Provider for CalDav and CardDav). On some installations The Addons refused to connect to a Nextcloud server.
After some investigation it was found that DNS resolving did not work (Error thrown by DNS.jsm). - On some installations it did work.
The issue is that the library-symlink libresolv.so not not part of the libc6 package that is usually installed but is part of the libc6-dev package which - by default is not installed. It could also be considered as an Ubuntu-bug, however Thunderbird itself seem to use a different name resolution - so basically adding imap/smtp servers did work so obviously a different name resolution technique is used. This should be harmonized.

Expected results:

The name resolution technique should be the same as of the main Thunderbird - which worked fine without libresolv.so

Comment 1

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (non,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 2

[John Bieling (:TbSync)]

In case you are a developer:
Can you check if this issue remains using the DNS API? That API is not using the same DNS.jsm but nsIDNSService

DNS API: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/dns
Works in TB as well.

Regarding the lib issue, I tried contacting the package maintainers, so they can set it as a dependency. I do not think we can do anything about that.

Comment 3

[Kai Engert [:KaiE:]]

John, it seems this is a complaint about a part of Thunderbird that doesn't use the official DNS APIs, but rather tries to open an external shared library directly, using ctypes - legacy code we inherited when integrating OpenPGP

Comment 4

[Kai Engert [:KaiE:]]

Wait, I might have misunderstood, too.
That DNS.jsm isn't part of OpenPGP, it's in mail/base.

We're talking about comm/mail/base/modules/DNS.jsm right?

This file has references to shared libraries, using a list of potential filenames that's apparently incomplete.

If systems may legitimately use filenames that we don't attempt to open, then it's a bug on our side.

Comment 5

[Emerson Bernier]

The core issue here is that DNS.js searches for "libresolv.so" filename which is a development symlink used only at build-time so it's not guaranteed to exist on end user system. The proper filename to search is "libresolv.so.2" which is a symlink used at runtime and what all glibc based distros must have available.

Se downstream issues reported about to DNS.jsm this behavior and thta affects opengpg:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973697
https://github.com/flathub/org.mozilla.Thunderbird/issues/157

Comment 6

[Emerson Bernier]

Ultimately you may keep searching for libresolv.so but add libresolv.so.2 to the search list. Perhaps that would be the safest change.

https://hg.mozilla.org/releases/comm-esr78/file/7bfb6e5797a4120c798eaa67a9cddd2846badcee/mail/base/modules/DNS.jsm#l41

Comment 7

[Kai Engert [:KaiE:]]

I confirm that on my Linux system, libresolv.so is contained in a development package, which isn't installed for most users.

libresolve.so.2 is the standard filename.

Comment 8

[Kai Engert [:KaiE:]]

Attachment: Bug 1634053 - Fix DNS.jsm lookups on Linux systems that don't have development libraries installed. r=mkmelin

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/b7f6c01ac69d
Fix DNS.jsm lookups on Linux systems that don't have development libraries installed. r=mkmelin DONTBUILD

Comment 10

[Kai Engert [:KaiE:]]

That was too quick. I had not tested the patch, and Emerson correctly pointed out - it doesn't work.

The first patch would attempt to load resolv.2.so but we must look for resolv.so.2 - we need code similar as in OTRLib.jsm

Comment 11

[Kai Engert [:KaiE:]]

Attachment: Bug 1634053 - Fix DNS.jsm to correctly combine candidate libname and version suffix. r=mkmelin

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/42ed0ced938b
Fix DNS.jsm to correctly combine candidate libname and version suffix. r=rjl DONTBUILD

Comment 13

[Kai Engert [:KaiE:]]

Attachment: combined.patch

This is a combined patch for uplifting.

Comment 14

[Kai Engert [:KaiE:]]

Someone should test tomorrow's nightly build on macOS, and verify that DNS.jsm code still works, for example by using openpgp key manager, keyserver, lookup by an email address, and ensure there's no exception related to DNS.jsm on the error console.

Comment 15

[Kai Engert [:KaiE:]]

I have applied this patch to a local macOS comm-esr78 build, and WKD/keyserver downloading still works (which depends on this DNS code).

Comment 16

[Kai Engert [:KaiE:]]

Comment on attachment 9191200 [details] [diff] [review]
combined.patch

[Approval Request Comment]
Regression caused by (bug #): no
User impact if declined: failing DNS lookup in Add-ons and in OpenPGP keyserver searching
Testing completed (on c-c, etc.):
Risk to taking this patch (and alternatives if risky): low

Comment 17

[Wayne Mery (:wsmwk)]

Comment on attachment 9191200 [details] [diff] [review]
combined.patch

[Triage Comment]
This didn't/won't make a beta uplift. But seems extremely low risk so ...

Approved for esr78

Comment 18

[Kai Engert [:KaiE:]]

https://hg.mozilla.org/releases/comm-esr78/rev/0c197a79bf56e9dd366ca23e60590c5b726a69fc