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: 2020-11-18 19:00 UTC (History)
8 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:


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.


Note You need to log in before you can comment on or make changes to this bug.