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

Steps to reproduce:

I want to create a clean and robust mechanism to replace the OpenPGP library that Thunderbird uses. Currently, the only way to achieve that is to overwrite rnp.so, but that has several disadvantages:

• Replacing RNP in the system's library path would also affect
  other programs.

• Replacing RNP shipped with Thunderbird is not robust as it is
  undone when Thunderbird is upgraded.

• Reverting to RNP is tricky because the original library might
  have been overwritten without having created a backup.

Instead, we first look for the library under a different name.
This gives users and integrators a replacement slot and has
several advantages:

• It makes it easy to install a replacement library in a way
  that clearly states intent and is scoped to Thunderbird.

• It makes it easy to revert to the stock RNP.

Because we might need our own rules to identify the correct RNP library, as shipped with Thunderbird, I wouldn't encode the standard RNP library name in a preference.

If we want to support the ability to load a different library at runtime, we could use an "override" pref. For example

mail.openpgp.override_rnp_library_filename

By default, the string would be empty. If empty, Thunderbird uses its own strategy for finding the RNP library.

If the pref is set, TB would attempt to load exactly this library name. If it cannot be found, it could treat it as a runtime failure.

I sugguest that build's options should add extra flag --with-librng-path. It will make autobuild system easier.

Hello! I am packaging Sequoia PGP and its "Octopus" librnp backend for Fedora Linux, and was asked to provide my perspective here.

A compile-time option might work fine if there was only ever one option available on a system, but, for example, on a Linux distribution, users will use either the Thunderbird package provided by their distribution, an upstream package, or something like a flatpak or snap, but will not re-compile it themselves. Most users probably also do not have computational resources to do that, given the CPU and RAM requirements for compiling Thunderbird. Which results in users not being able to choose to use the PGP backend they want to use in this scenario, only the "provider" of their Thunderbird package (be that a Linux distribution, Thunderbird developers, or flatpak / snap maintainers) can.

So while I appreciate that "just add another preference" adds more code that needs to be maintained, I think it is the best solution here, because it makes it possible to make both PGP backends available to users, with them being able to choose one via a preference, without users having to re-compile code.

I'm in the same situation as Fabio above but for Arch Linux. I'm packaging Sequoia PGP "Octopus" and need a way to overwrite the PGP backend. My preference would be a config option instead of compile-time option.

It's a reasonable patch.

Just one point, I agree 100% with Magnus' comment 1:

If someone wants to do that, I think they would need to set a pref.
I would expect needlessly trying to load a library somewhat of a performance hit. Something like

let rnp = Services.prefs.getCharPref("mail.opengpp.rnplib", "rnp");

a) The alternative library should not be preferred over the stock lib, but there should be an explicit choice. I'd be surprised, if there's a library with a certain name in the lib path anywhere in the system, and it automatically overrides my normal PGP lib.
b) The library name should not be hardcoded. A configurable name allows for multiple alternatives, not just one.
c) As Magnus said, it's faster to read a pref than search for a library in the whole lib path. That's a penalty that all users would have to pay, even those who use the stock lib. Whereas a pref read is neglible and fast.

Other than this, I think the patch in general makes sense.

Hello all,

as a user of Thunderbird and the Octopus alternative RNP backend, I'd like to try and move this issue forward.

I think the discussion above touches on two different goals:

1. A mechanism to change the RNP library system-wide, e.g. by installing a different RNP library with a package manager, that Thunderbird then automatically picks up.
2. Allowing an individual user to explicitly change the RNP library Thunderbird loads, in their profile (e.g. with a preference in the user's Thunderbird config).

As I understand it, Justus' main concern (and the goal of his patch) was to address 1).
I think that a solution for this goal would be useful (but I haven't yet seen any suggestions for how to approach this, that seem to have a chance of consensus).

So, independently, I would like to propose this patch to solve at least goal 2).
I follow the approach suggested by Magnus as clarified by Kai, and Kai's naming scheme.
Based on the discussion above, I hope this change is incontroversial.

Thanks everyone for your time,
Heiko

PS: I'd personally be very happy to see a change like this merged: I've been manually replacing librnp.so for the last two years, and after every TB update I need to replace it again. Which is not great.

Thunderbird has documented and supported behavior.
If a replacement library is used for an internal component, which changes that behavior, there is risk that users don't understand why official documentation doesn't match the application's functionality. They might be confused, for example when two users of Thunderbird talk to each other, but they don't know that one of them uses a replacement component. The users might report bugs to the wrong place.

In my opinion, if a replacement OpenPGP component is being used, which isn't officially endorsed by the Thunderbird project, (either caused by distribution packages or by settings made by e.g. a system administrator), but the application is running under the Thunderbird branding, then the application must make it discoverable in the user interface that a replacement component is being used.

I consider such a UI notification a precondition for implementing the enhancement suggested in this bug.

When discussing this request with Alessandro in the past, we had considered the idea to add reminder notifications in the secondary dialogs that are used to configure the OpenPGP functionality of Thunderbird.

For example, in the end-to-end encryption settings in account settings, and also in the OpenPGP key manager window, we could have a notification bar, which makes the user aware of the alternative OpenPGP backend being used.