Skip to content

Bug 40606&40900: Use Clang to compile NSIS and update it to 3.09

Pier Angelo Vendrame requested to merge pierov/tor-browser-build:bug_40606 into main

Merge Info

Related Issues

Backporting

Timeline

  • Immediate: patchset needed as soon as possible
  • Next Minor Stable Release: patchset that needs to be verified in nightly before backport
  • Eventually: patchset that needs to be verified in alpha before backport
  • No Backport (preferred): patchset for the next major stable

(Optional) Justification

  • Emergency security update: patchset fixes CVEs, 0-days, etc
  • Censorship event: patchset enables censorship circumvention
  • Critical bug-fix: patchset fixes a bug in core-functionality
  • Consistency: patchset which would make development easier if it were in both the alpha and release branches; developer tools, build system changes, etc
  • Sponsor required: patchset required for sponsor
  • Other: please explain

Issue Tracking

Review

Request Reviewer

  • Request review from an applications developer depending on modified system:
    • NOTE: if the MR modifies multiple areas, please /cc all the relevant reviewers (since gitlab only allows 1 reviewer)
    • accessibility : henry
    • android : clairehurst, dan
    • build system : boklm
    • extensions : ma1
    • firefox internals (XUL/JS/XPCOM) : ma1
    • fonts : pierov
    • frontend (implementation) : henry
    • frontend (review) : donuts, richard
    • localization : henry, pierov
    • macos : clairehurst, dan
    • nightly builds : boklm
    • rebases/release-prep : boklm, dan, ma1, pierov, richard
    • security : ma1
    • signing : boklm, richard
    • updater : pierov
    • misc/other : pierov, richard

Change Description

With this MR we start building NSIS with Clang instead of GCC. The trick I was missing the previous time I tried was adding binutils to the container.

Updating it to 3.09 allows us to drop our patches... Except that we need a new one: one of the patches was for reproducibility, which upstream said they fixed with SOURCE_DATE_EPOCH. However, they don't apply SOURCE_DATE_EPOCH to an example DLL, so the intermediate artifacts cannot be easily checked (one example file contains a file that has the timestamp at which you actually built it).

I've opened https://sourceforge.net/p/nsis/patches/312/ to get that solved, and in the meantime I thought of still keeping that patch in our codebase, even though I expect we could do without it.

How Tested

Ran:

rbm/rbm build nsis --target torbrowser-windows-x86_64 && rbm/rbm build nsis --target torbrowser-windows-i686

Checked that they succeed and that the output matches in my local machine and in our build servers:

835d10b2eb420989d50fbfdc60db35390f554283f0d6ec4ea4f33f25ea77ab46  out/nsis/nsis-3.09-windows-i686-ea2664.tar.zst
2dc1dcb12c096c41f48849a159182f4b1a8a1c4a3daad26964fc372998c02fd3  out/nsis/nsis-3.09-windows-x86_64-11c693.tar.zst

I didn't try to build a full browser to check reproducibility, but I hope that since the artifacts are matching we are okay (i.e., no regressions in NSIS itself).

I haven't tried to build a browser at all, I'll leave a build going and test it later.

Merge request reports