Closed Bug 1961106 Opened 1 year ago Closed 1 year ago

remove EnigmailFuncs.sync() usage where we easily can

Categories

(MailNews Core :: Security: OpenPGP, task)

task

Tracking

(thunderbird_esr128 wontfix, thunderbird_esr140 fixed, thunderbird139 wontfix, thunderbird140 fixed, thunderbird141 fixed)

RESOLVED FIXED
140 Branch
Tracking Status
thunderbird_esr128 --- wontfix
thunderbird_esr140 --- fixed
thunderbird139 --- wontfix
thunderbird140 --- fixed
thunderbird141 --- fixed

People

(Reporter: mkmelin, Assigned: mkmelin)

References

Details

Attachments

(5 external files)

EnigmailFuncs.sync() is an old and evil way of faking sync functionality where async functionality happens. Basically busy-wait...
Not sure we can easily remove all usage but many of the cases are fairly trivial to rework as much of the other code now uses real async.

Assignee: nobody → mkmelin+mozilla
Status: NEW → ASSIGNED

Also adding some tags to allow easier running of all the openpgp tests like

./mach xpcshell-test --tag=openpgp comm/
./mach mochitest --headless --tag=openpgp comm/
Target Milestone: --- → 140 Branch

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/0de231cb826b
use proper async for decryptMessage() and its callers. r=kaie
https://hg.mozilla.org/comm-central/rev/381e2ce8c4ab
Get rid of sync version of EnigmailKeyRing.importKey() in favor of the async version. r=kaie

A few of calls will be left after the above patch lands. Unfortunately it turned out those are not easy to replace. There's some libmime interaction with sync call assumptions, so leaving it for a future bug.

Pushed by brendan@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/0832b219daf1
remove EnigmailFuncs.sync() from message sending. r=edicharry

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Regressions: 1971472
Regressions: 1969033

Reopening until we have backed out the regressor patch.

The backout patch for c-c needs manual merging, because of context changes.
I'll work on that.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

The regressions issues lack automated test?

Attachment #9496523 - Attachment description: Bug 1961106 - Partially backed out changeset 0832b219daf1 (not restoring previously removed strings). r=edicharry → Bug 1961106 - Partially backed out changeset 0832b219daf1 (not restoring previously removed strings). TB 140 patch. r=edicharry

In phab attachment 9490051 [details]
I've found at least one bug, see my comment there.

Comment on attachment 9496523 [details]
Bug 1961106 - Partially backed out changeset 0832b219daf1 (not restoring previously removed strings). TB 140 patch. r=edicharry

Uplift Approval Request

  • Please state case for uplift consideration and ensure bug severity is set: Fixes functional regression
  • User impact if declined: Unable to send signed/encrypted messages, in some legitimate configurations.
    (While the related code is generally covered by automated tests, we don't cover the specific configuration that failed.)
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Daily?: No
  • Has the fix been verified in Beta?: No
  • Needs manual test from QA?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Restoring code that worked previously.
  • String changes made/needed: Patch deliberately doesn't restore old strings, but the string was very unlikely to be seen/experienced by users.
Attachment #9496523 - Flags: approval-comm-esr140?

Comment on attachment 9496529 [details]
Bug 1961106 - Partially backed out changeset 0832b219daf1 (not restoring previously removed strings). r=edicharry

EDIT:

I've removed the empty approval comment details, see above instead.

Attachment #9496529 - Flags: approval-comm-beta?

Comment on attachment 9496523 [details]
Bug 1961106 - Partially backed out changeset 0832b219daf1 (not restoring previously removed strings). TB 140 patch. r=edicharry

[Triage Comment]
Approved for esr140

Attachment #9496523 - Flags: approval-comm-esr140? → approval-comm-esr140+

Comment on attachment 9496529 [details]
Bug 1961106 - Partially backed out changeset 0832b219daf1 (not restoring previously removed strings). r=edicharry

[Triage Comment]
Approved for release, if this is landed after the merges. Or approved for beta if you want to land this before the merge.

Take your pick, as long as we meet the goal of getting this to be in 140-everything.

Flags: needinfo?(kaie)
Flags: needinfo?(daniel)
Attachment #9496529 - Flags: approval-comm-release+
Attachment #9496529 - Flags: approval-comm-beta?
Attachment #9496529 - Flags: approval-comm-beta+

Comment on attachment 9496523 [details]
Bug 1961106 - Partially backed out changeset 0832b219daf1 (not restoring previously removed strings). TB 140 patch. r=edicharry

[Triage Comment]
Approved for release

Attachment #9496523 - Flags: approval-comm-release+

I had assumed we'd back the regressor patch from comm-central, too.

I realize this hasn't happened yet. I guess it wasn't done immediately, because we had to fix while trees were closed using 140 branching/release preparations.

Now, with the patch, still present in c-c, Magnus has requested a remedy patch on top of the regressor patch in bug 1971472.

I had originally thought we'd back out everywhere, and then do a full patch, as that would allow me to cleanly review/comment on all aspects of the patch.

Flags: needinfo?(kaie)

Please land revision D254842 into comm-central to get us into the same state as on the 140/141 branches, and then we can work from there.

Please also backout from the new beta 142 branch as soon as it's possible.

(In reply to Kai Engert [:KaiE:] from comment #23)

Please also backout from the new beta 142 branch as soon as it's possible.

Comment was wrong.
141 beta already has the backout.

142 is comm-central.

Pushed by toby@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/360eac600146
Partially backed out changeset 0832b219daf1 (not restoring previously removed strings). r=edicharry

Status: REOPENED → RESOLVED
Closed: 1 year ago → 1 year ago
Resolution: --- → FIXED

This bug is quite a mess now. It should never have been reopened, and the backouts should have happened in the relevant bug found.
I'm going to clone this bug to start anew, as all the statuses are now wrong.

Flags: needinfo?(daniel)
See Also: → 1975367
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: