Closed Bug 1758626 Opened 3 years ago Closed 2 years ago

Uplift rlbox to esr91

Categories

(Core :: Security: RLBox, task)

Product:
Core
Component:
Security: RLBox
Type:
task

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: glandium, Assigned: glandium)

References

Details

Attachments

(13 obsolete files)

As discussed on matrix, we were too late in the cycle for esr91.7. This targets esr91.8.

Attached file Bug 1758626 - Import rlbox_wasm2c_sandbox code. (obsolete) (deleted) —

This is a cumulative patch for the rlbox_wasm2c_sandbox parts of
bug 1713735, bug 1721765, bug 1723447, bug 1726476, bug 1726474,
bug 1737700, bug 1739298, bug 1739762, bug 1742032, bug 1730394,
bug 1744460.

This is an uplift of bug 1720822.

Attached file Bug 1758626 - Bootstrap wasi-sysroot via configure. (obsolete) (deleted) —

This is a patch cumulating bug 1722439, bug 1738163 and parts of bug 1719229.

Attached file Bug 1758626 - Update wasi-sdk to the latest trunk. (obsolete) (deleted) —

This is an uplift of bug 1732824.

Attached file Bug 1758626 - Remove unused clang-linux64.json. (obsolete) (deleted) —

This is an uplift of bug 1724522.

Ryan, how do we go about this?

Flags: needinfo?(ryanvm)

My understanding is that the main need driving this work was a desire to harden TB before the next ESR train (102). How possible is it for these changes to be left off for Firefox builds while available for TB to make use of?

Flags: needinfo?(ryanvm) → needinfo?(mh+mozilla)

We're actually interested in enabling them in Firefox.

Flags: needinfo?(mh+mozilla)

I'm very uncomfortable backporting all this work to ESR91. While I appreciate the benefits we get from sandboxing these components, this seems like a very risky change to take on an ESR branch, especially this far into its lifecycle.

The RLBox work has only been on Release for a couple cycles now and we had a number of quality issues with it after landing. Furthermore, this goes far beyond the scope of the types of quality and security fixes we'd typically take on an ESR branch. Also, we have limited prerelease testing of ESR builds without Beta/Nightly channels and limited ability for QA to test in more typical enterprise-like environments where things are at the highest risk of breakage.

With the ESR102 train being less than 4 months away from shipping its first releases (with a long overlap with ESR91 to allow for enterprise users to test for compatibility issues in the field before EOL), I think this is safer to let ride the next train.

Bobby, do you want to weigh in?

Flags: needinfo?(bholley)

I don't think this is critical to take for Firefox. I do think the risk is lower than it may appear: the affected modules are pretty isolated and infrequently modified, so assuming glandium methodically gathered all the changesets that have been made to these areas, I'm less concerned than I would be with a large change to a higher-traffic area. That said, I will defer to relman's recommendation here.

Flags: needinfo?(bholley)
Attachment #9266970 - Attachment is obsolete: true
Attachment #9266965 - Attachment is obsolete: true
Attachment #9266966 - Attachment is obsolete: true
Attachment #9266967 - Attachment is obsolete: true
Attachment #9266968 - Attachment is obsolete: true
Attachment #9266969 - Attachment is obsolete: true
Attachment #9266971 - Attachment is obsolete: true
Attachment #9266972 - Attachment is obsolete: true
Attachment #9266973 - Attachment is obsolete: true
Attachment #9266974 - Attachment is obsolete: true
Attachment #9266975 - Attachment is obsolete: true
Attachment #9266976 - Attachment is obsolete: true
Attachment #9266977 - Attachment is obsolete: true

esr91 is not supported anymore.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: