Closed Bug 1836634 Opened 2 years ago Closed 2 years ago

Treat plain RNP version numbers as official (in addition to version numbers containing ".MLZA")

Categories

(MailNews Core :: Security: OpenPGP, enhancement)

enhancement

Tracking

(thunderbird_esr102 fixed, thunderbird115 fixed)

RESOLVED FIXED
116 Branch
Tracking Status
thunderbird_esr102 --- fixed
thunderbird115 --- fixed

People

(Reporter: KaiE, Assigned: KaiE)

References

Details

Attachments

(1 file)

This is a follow-up to bug 1799874.

Currently, if a version string is the plain simply version number string (such as 0.16.3), our troubleshooting information claims it's an unofficial version. That's wrong.

We should use a better regexp that allows both original RNP version numbers and those with a .MZLA.* suffix as official versions.

My motivation is OS distributions that package RNP separately from Thunderbird, and which might use official RNP snapshots. We shouild show those as OK in TB's troubleshooting page.

As of today, RNP seems to always use
^[0-9]+.[0-9]+.[0-9]+$

Maybe it would be wise to also allow another subversion, just in case it might be necessary some day?

^[0-9]+.[0-9]+.[0-9]+(.[0-9]+)?

Thunderbird's code to load RNP snapshots adds a suffix to the version number, starting with .MZLA.

Combining that, I end up with the following regexp to match a version number that I think would match both official version numbers, and the ones from MZLA:

'^[0-9]+.[0-9]+.[0-9]+(.[0-9]+)?(.MZLA..*)?$'

Depends on: 1799874
Assignee: nobody → kaie
Status: NEW → ASSIGNED

I see the MZLA version strings look differently. So I suggest to either allow a version that contains .MZLA or matches ^[0-9]+.[0-9]+.[0-9]+(.[0-9]+)?$

Summary: Treat plain RNP version number, optional with suffix .MLZA.*, as official → Treat plain RNP version numbers as official (in addition to version numbers containing ".MLZA")

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

My motivation is OS distributions that package RNP separately from Thunderbird, and which might use official RNP snapshots. We should show those as OK in TB's troubleshooting page.

Well those would still be unofficial, no?
Even for official snapshots, some defines could be different, or we could have patched something.

(In reply to Magnus Melin [:mkmelin] from comment #3)

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

My motivation is OS distributions that package RNP separately from Thunderbird, and which might use official RNP snapshots. We should show those as OK in TB's troubleshooting page.

Well those would still be unofficial, no?

I'm ok with "official RNP version".

Even for official snapshots, some defines could be different, or we could have patched something.

I'm interested in "expected functional behavior".
Thunderbird knows about the RNP library behavior, and is fine with that.

If someone patches their system to allow additional algorithms, or disallows some algorithms, I think that's a policy decision that Thunderbird can allow.

Thunderbird should usually avoid patching for functional behavior changes, and rather use runtime API calls to define the desired behavior.

Thunderbird might use a patch to fix a bug, but in that scenario, it should be an upstream patch that we apply early. In that scenario, we could use the expected minimum version to enforce that a particular version is required. For example, let's assume RNP released 0.2.3 without a patch, and released 0.4.0 with a patch. If TB cannot use 0.4.0 yet, but decides to take a backported patch, then RNP could mark this patched version with an additional .1 version number suffix, e.g. 0.2.3.1 and could set that as a minimum required version.

In other words, the expected minimum version number check should be sufficient to check that the library is likely to contain a patch for a certain bug.

My intention is to distinguish original libraries of the RNP project from alternative implementations (which are expected to identify themselves in some way in the version string).

Target Milestone: --- → 116 Branch

Comment on attachment 9337350 [details]
Bug 1836634 - Treat simple RNP library versions as official. r=mkmelin

[Approval Request Comment]
Regression caused by (bug #): no
User impact if declined: incorrect information in troubleshooting page on some systems
Testing completed (on c-c, etc.):
Risk to taking this patch (and alternatives if risky): no risk, only affects information shown in the help/troubleshooting page

Attachment #9337350 - Flags: approval-comm-esr102?
Attachment #9337350 - Flags: approval-comm-beta?

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/eb5ee506e9bc
Treat simple RNP library versions as official. r=mkmelin

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

Comment on attachment 9337350 [details]
Bug 1836634 - Treat simple RNP library versions as official. r=mkmelin

[Triage Comment]
Approved for beta

Attachment #9337350 - Flags: approval-comm-beta? → approval-comm-beta+

Comment on attachment 9337350 [details]
Bug 1836634 - Treat simple RNP library versions as official. r=mkmelin

[Triage Comment]
Approved for esr102

Attachment #9337350 - Flags: approval-comm-esr102? → approval-comm-esr102+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: