Shipping HTTPS-Everywhere based on the new WebExtensions model broke its
functionality on higher security levels as our JavaScript blocking does
not whitelist `moz-extension:` which is needed.

It turns out that vanilla Firefox 52 ESR is affected as well but differently:
Backorting https://bugzilla.mozilla.org/show_bug.cgi?id=1329731 does not help
us as NoScript is regulating JavaScript related things.

This fixes #21270 as well.

 * FIXES #23166: https://bugs.torproject.org/23166

boklm authored Aug 08, 2017 and Georg Koppen committed Aug 09, 2017

Thanks to dcf for finding the cause of the problem.

Changelog update, version bumps, and config.yml update

This reverts commit e8178d13.

That's properly fixed in NoScript >= 5.0.7.1, thus removing our
workaround.

This fixes bug 22067.

We bump our GCC compiler to 5.4.0 as this fixes some bugs
in previous versions. It allows us in particular to build
debug builds for Windows with mingw-w64.

Found by boklm.

Whitelist about:tor so that NoScript does not block its JavaScript.

David Fifield authored Jul 05, 2017 and Georg Koppen committed Jul 14, 2017

I had to apply two tricks to get a reproducible snowflake-client.

The first is to use faketime to eliminate some timestamps. There were 11
variable timestamps in the file. Through experimentation, I found that
10 of them were dependent on the Go runtime (recompiling Go caused them
to change) and 1 was dependent on snowflake-client itself (recompiling
snowflake-client with the same runtime changed only that 1 timestamp).
The underlying issue has to do with clang 3.8.0 on Darwin embedding
timestamps, unsolved in the Go issue tracker as of 13 days ago.
https://github.com/golang/go/issues/9206#issuecomment-310476743

The second is a sed command to clobber embedded paths of the form
/tmp/go-buildXXXXXXXXX and /tmp/go-link-XXXXXXXXX. Their presence is
caused by some combination of Clang and Darwin, and there is as yet no
known workaround upstream.

David Fifield authored Jul 05, 2017 and Georg Koppen committed Jul 10, 2017

Object files from elsewhere under out/ should never have been included,
because they are not part of webrtc itself, but rather side-effect build
artifacts like gn. Including those extraneous .o files was mostly
harmless (except for library size), because on linux they happened to be
the same architecture as the webrtc.o files. However it won't work for
the mac build (because libwebrtc-magic.a would include a mix of linux
ELF and mac Mach-O objects). Additionally, build_time.o, part of the gn
build, embeds a timestamp with month resolution, causing a failure of
reproducibility, as found at https://bugs.torproject.org/22832.

"10.9" was the wrong `minSupportedOSVersion` for preventing OS X 10.7.x
and 10.8.x users from getting updated to Tor Browser 7. That it worked
for OS X 10.6.x was only by chance according to the release history table
(https://en.wikipedia.org/wiki/Darwin_(operating_system)#Release_history).

We fix that by choosing "13.0.0" (for OS X 10.9 as minimum).