Opened 7 months ago

Closed 6 weeks ago

#29818 closed defect (fixed)

adapt #13379 patch for 68esr

Reported by: mcs Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-update, ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201908
Cc: brade Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor44-can

Description (last modified by gk)

In https://bugzilla.mozilla.org/show_bug.cgi?id=1434033, Mozilla removed the use of LD_LIBRARY_PATH (which is used in non-macOS and non-Windows Firefox to ensure that the updater can locate NSS related shared libraries). Instead, the Firefox build now adds -rpath=$ORIGIN in LDFLAGS.

For Tor Browser, we need a similar solution for Windows and macOS because we define MAR_NSS on all platforms (we define MAR_NSS so that we use NSS for MAR-related crypto on all platforms rather than relying on OS-provided libraries). Therefore, we will need to adapt our #13379 patch to account for Mozilla's change.

Current (Tor Browser 8.5a9) patch:
https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-60.6.0esr-8.5-1&id=c17b8a3fbcd19230706f295a00ce955c1bcf90b9

Related Firefox bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1434033
https://bugzilla.mozilla.org/show_bug.cgi?id=1434666

Child Tickets

Change History (6)

comment:1 Changed 7 months ago by gk

Description: modified (diff)
Keywords: ff68-esr added; f68-esr removed

comment:2 Changed 2 months ago by pili

Sponsor: Sponsor44-can

Adding Sponsor 44 to ESR68 tickets

comment:3 Changed 2 months ago by mcs

Keywords: tbb-9.0-must-alpha added

comment:4 Changed 2 months ago by gk

Keywords: TorBrowserTeam201908 added
Priority: MediumHigh

comment:5 Changed 6 weeks ago by mcs

Testing on Windows 10 with both 64-bit and 32-bit Tor Browser builds shows that the updater is working and finding its dependent DLLs (things "just work" because the DLLs are in the same directory as updater.exe and on Windows the updater is not copied to a secondary location before it is launched). On Linux, Mozilla's rpath approach works fine. Finally, for macOS we included a fix in our rebased #4234 patch; see the AppendToLibPath() call here:
https://gitweb.torproject.org/tor-browser.git/tree/toolkit/xre/nsUpdateDriver.cpp?h=tor-browser-68.1.0esr-9.0-1#n731

The above is a somewhat long way of saying we can close this ticket. Georg, if you agree please resolve this as fixed.

comment:6 in reply to:  5 Changed 6 weeks ago by gk

Resolution: fixed
Status: newclosed

Replying to mcs:

Testing on Windows 10 with both 64-bit and 32-bit Tor Browser builds shows that the updater is working and finding its dependent DLLs (things "just work" because the DLLs are in the same directory as updater.exe and on Windows the updater is not copied to a secondary location before it is launched). On Linux, Mozilla's rpath approach works fine. Finally, for macOS we included a fix in our rebased #4234 patch; see the AppendToLibPath() call here:
https://gitweb.torproject.org/tor-browser.git/tree/toolkit/xre/nsUpdateDriver.cpp?h=tor-browser-68.1.0esr-9.0-1#n731

The above is a somewhat long way of saying we can close this ticket. Georg, if you agree please resolve this as fixed.

Looks good to me. Did you know what rstrong meant by saying to add support for this ticket on Mozilla's side? Do we need to take some action here (see last comment in 1434666)?

Note: See TracTickets for help on using tickets.