Closed Bug 1732809 Opened 3 years ago Closed 2 years ago

Build system should support --with-system-rnp flag

Categories

(MailNews Core :: Security: OpenPGP, enhancement)

enhancement

Tracking

(thunderbird_esr91 wontfix)

RESOLVED FIXED
96 Branch
Tracking Status
thunderbird_esr91 --- wontfix

People

(Reporter: rjl, Assigned: rjl)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Adding this so it's tracked. I didn't see another bug for it.

Background:
For the initial integration into the build system, support for using a system librnp was left out intentionally as the vendored version was not a stable release.

Currently, the included RNP source is from 0.15.2 and it appears that the plan is to stick to release versions going forward. The Javascript wrapper code supports using librnp from a system location, but the build system does not support it and will always produce its own build.

The build system should support a --with-system-rnp option that skips building librnp altogether, but keep MOZ_OPENPGP defined so that PGP support is still enabled.

According to pkgs.org, as of Sept 2021 RNP is packaged only in Debian unstable (sid), openSUSE tumbleweed (devel/unstable), and FreeBSD 12 & 13. That being the case, I don't think there's any particular rush to implement this yet.

We should also keep in mind that there is the RNP patch for disabling some crypto algorithms that are too old to be considered secure anymore.

[edit - There's no compiled code on the Thunderbird side (js-ctypes only), so if --with-system-rnp is enabled, json-c, botan, zlib, and bzip2 would not need to be checked.]

i would definitely welcome this, as i'm planning to package RNP on OpenBSD too.

Landry, the RNP team would be happy to assist with OpenBSD packaging. We can always be reached with the issue tracker at https://github.com/rnpgp/rnp ;-)

Because Thunderbird patches RNP to disable some algorithms, it would be good to have a mechanism to disable that without having to patch, either (a) at build time using a configuration switch, or (b) at runtime using a cipher configuration call. Unless we have that, we risk that system packagers may ship unmodified RNP.

(In reply to Ronald Tse from comment #2)

Landry, the RNP team would be happy to assist with OpenBSD packaging. We can always be reached with the issue tracker at https://github.com/rnpgp/rnp ;-)

thanks :) will reach out if needed ..

(In reply to Kai Engert (:KaiE:) from comment #3)

Because Thunderbird patches RNP to disable some algorithms, it would be good to have a mechanism to disable that without having to patch, either (a) at build time using a configuration switch, or (b) at runtime using a cipher configuration call. Unless we have that, we risk that system packagers may ship unmodified RNP.

yes, definitely seconded! If we can build against a systemwide RNP but thunderbird has particular configuration needs, then it should be possible to have both.. eg --with-system-rnp should check that the systemwide RNP is installed/built with the required list, or the build goo should pass those requirements when building around RNP.

as of now if there are no other RNP consumers, we can build it with the thunderbird needs, but that only works if those needs fit the needs of other potential consumers to come :)

(In reply to Kai Engert (:KaiE:) from comment #3)

Because Thunderbird patches RNP to disable some algorithms, it would be good to have a mechanism to disable that without having to patch, either (a) at build time using a configuration switch, or (b) at runtime using a cipher configuration call. Unless we have that, we risk that system packagers may ship unmodified RNP.

We plan to address this in the RNP v0.16.0 release, so API user may configure some sort of security profile/manifest instead of default one.
Another major thing there would be initial support for OpenSSL backend.

As Nickolay mentioned, RNP should provide a configuration call where it can be initialised to adhere to a certain security profile and produce checks in accordance with that profile. There would likely be one or two available profiles by default: "currently safe", "accept all algorithms" (i.e. unsafe), and Thunderbird could use a custom profile to ensure that the algorithm security stance is maintained by the TB team itself.

There is no version checking or verification done at build time since the
library is loaded via ctypes at runtime.

Assignee: nobody → rob
Status: NEW → ASSIGNED

I went looking for some documentation about the plans for RNP to permit the type of fine-tuning described here. Is this where the API change is being discussed?

https://github.com/rnpgp/rnp/issues/1281

It looks like Kai has commented there, but the only reply since then from RNP upstream is Nickolay's suggestion that there might be some hard-coding done.

It'd be great to see a specific plan for the API, to see whether it meets Thunderbird's needs.

Thanks Daniel, the latest design is offered here: https://github.com/rnpgp/rnp/pull/1524#issuecomment-956019966 . This is supposed to be fully configurable on initialization.

Target Milestone: --- → 96 Branch

Needs rebasing.

Pushed by thunderbird@calypsoblue.org:
https://hg.mozilla.org/comm-central/rev/47a1dacd17a3
Add flag to disable building librnp shared library and tools. r=kaie
https://hg.mozilla.org/comm-central/rev/304b24d26798
Enforce minimum librnp version at runtime. r=kaie

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Regressions: 1742900

Why was it marked as wontfix? The patches to comm-central has been accepted, right?

It's marked "wontfix" for the 91.x branch. It is fixed in comm-central and comm-beta.

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

Attachment

General

Created:
Updated:
Size: