RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1837512 - [rhel] Do not ship botan library in the rebased Thunderbird 78
Summary: [rhel] Do not ship botan library in the rebased Thunderbird 78
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: thunderbird
Version: 8.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Jan Horak
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-05-19 15:14 UTC by Jan Horak
Modified: 2022-07-04 19:22 UTC (History)
11 users (show)

Fixed In Version: thunderbird-78.3.1-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-01 13:33:40 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Jan Horak 2020-05-19 15:14:26 UTC 
Since we don't want to ship botan library to the RHEL we need to disable it during build and possibly provide another way to allow users to get the opengpg working in the rebased Thunderbird 78.
Comment 1 Jan Horak 2020-05-19 15:21:07 UTC 
The openpgp support can be disabled during build by --disable-openpgp.
Comment 2 Simo Sorce 2020-05-19 16:55:59 UTC 
Would it be possible to patch thunderbird to provide opengpg support via a library like gpgme rather then botan ?
Comment 3 Martin Stransky 2020-05-21 10:16:11 UTC 
(In reply to Simo Sorce from comment #2)
> Would it be possible to patch thunderbird to provide opengpg support via a
> library like gpgme rather then botan ?

Sure, we can take any patches here, feel free to provide anyone.
Thanks.
Comment 4 Jan Horak 2020-05-21 10:17:59 UTC 
(In reply to Simo Sorce from comment #2)
> Would it be possible to patch thunderbird to provide opengpg support via a
> library like gpgme rather then botan ?
I have no idea but I doubt it will be an afternoon task. Maybe Kai knows more, I guess he considered that option.
Comment 5 kaie 2020-05-27 09:24:30 UTC 
I assume the majority of Thunderbird users will not use GnuPG by default, but will use RNP.

RNP doesn't (yet) offer trust management for public keys.
Thunderbird implements its own trust model and related user interface.
That won't be a copy of GnuPG's complex trust model, but will be a simpler approach.

This is one example why the Thunderbird user interface and integration code will be different from what you'd do when using GnuPG.

Initially we will NOT have two variations of that integration code, but only support RNP for public key and trust management.

In theory, a future version could be more flexible and could contain additional integration code to optionally support GnuPG for all OpenPGP aspects, but right now this isn't planned.

However, we already consider to offer a fallback to GnuPG for a subset of OpenPGP operations: For secret key operations, only (signing and decryption).
This could allow Thunderbird to be used with OpenPGP smartcards, because the RNP library doesn't support it yet.
Thunderbird would still use RNP and its internal code for trust and public key management.
Comment 6 kaie 2020-05-27 09:57:08 UTC 
Can you say why you don't want to ship Botan?
Comment 7 kaie 2020-05-27 10:25:45 UTC 
(In reply to kaie from comment #5)
> I assume the majority of Thunderbird users will not use GnuPG by default,
> but will use RNP.

That was badly written.
Of course they will not use GnuPG by default, because we don't offer that choice.

Thunderbird 78 users will use RNP, because that's what it bundles and supports.

Optionally, a small portion of Thunderbird 78 users might use GnuPG for secret key operations, which is an advanced mode that users would have to manually enable, and which is intended to support smartcards, only.
Comment 8 Tomas Mraz 2020-05-27 10:41:42 UTC 
(In reply to kaie from comment #6)
> Can you say why you don't want to ship Botan?

Because we really care about having all the crypto libraries (or other crypto code) in RHEL to be properly maintained, with support of downstream features such as system-wide crypto policies added, FIPS validation and compliance ensured, and so on. Any additional crypto code (even in form of bundled crypto library) breaks this story because we cannot fully support more than the existing 4 (plus kernel) RHEL core crypto libraries.
Comment 9 kaie 2020-06-15 22:26:41 UTC 
FYI: https://bugzilla.mozilla.org/show_bug.cgi?id=1645914
Comment 11 neal 2021-02-03 13:52:28 UTC 
(In reply to Martin Stransky from comment #3)
> (In reply to Simo Sorce from comment #2)
> > Would it be possible to patch thunderbird to provide opengpg support via a
> > library like gpgme rather then botan ?
> 
> Sure, we can take any patches here, feel free to provide anyone.
> Thanks.

We (Sequoia PGP, https://sequoia-pgp.org) have created an ABI compatible shim that implements the semantics that rnp implements.  You can find the code here: https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp .  The basic idea is: build it, replace TB's librnp with sequoia-octopus-librnp's RNP, restart TB.  No migration is required (the shim uses the same key stores as RNP and uses the same format), and it is possible to switch back at any time.

Note: there is still one function missing: we haven't yet implemented importing keys (existing keys are used), because it has a bit of a funky JSON API.

Several people on the Sequoia team are already using it, as it supports a greater variety of keys than rnp, for instance.

We'd like to hear from users impacted by this issue whether they are interested in this solution.
Comment 12 Tomas Popela 2021-02-03 14:31:52 UTC 
Hi Neal, thank you for the update! You can add a comment into https://bugzilla.redhat.com/show_bug.cgi?id=1886958 as well as there are other users asking for this functionality.
Comment 13 rhtse 2021-03-09 05:04:02 UTC 
(In reply to Tomas Mraz from comment #8)

Hi Tomas!

The RNP team has been working on a switch that allows RNP to rely on one of the RHEL core crypto libraries instead of Botan, so this issue will be fully resolved once that new version is released and incorporated into Thunderbird (i.e. the RHEL version would not depend on Botan). Kai and Simo are aware of this effort. Hope this helps. Thanks!
Comment 14 rhtse 2022-07-04 19:22:21 UTC 
Hello everyone,

Just a hark back from the past: RNP now works with RHEL OpenSSL out of the box without needing Botan. Look forward to contributing!
Note You need to log in before you can comment on or make changes to this bug.