Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-16T01:24:29Zhttps://gitlab.torproject.org/legacy/trac/-/issues/2340protect users against freeze, replay and version-rollback attacks2020-06-16T01:24:29ZRobert Ransomprotect users against freeze, replay and version-rollback attacksCurrently, [we tell users](https://www.torproject.org/docs/verifying-signatures) that the GPG signatures linked to from the download page 'allow you to verify the file you've downloaded is exactly the one that we intended you to get. For...Currently, [we tell users](https://www.torproject.org/docs/verifying-signatures) that the GPG signatures linked to from the download page 'allow you to verify the file you've downloaded is exactly the one that we intended you to get. For example, tor-browser-1.3.15_en-US.exe is accompanied by tor-browser-1.3.15_en-US.exe.asc.' This is false.
The GPG signatures only prove that a particular person associated with The Tor Project has signed a particular file; they do not authenticate the filename, thus they do not authenticate the package name or the package version, and they do not prove that a particular package file is the final build of a package version which we want to distribute to users. This leaves our users vulnerable to version-rollback attacks and package-substitution attacks if they download packages from mirrors or over non-HTTPS connections.
We should:
* switch to signing the output of `sha256sum` on a package file, which includes the filename and a hash of the file, rather than signing the package file directly, and
* explain on the verifying-signatures page how to verify downloaded packages using the signed SHA256SUM files, including explaining that unless there is a blank line after the '`Hash: `' line and before the hash-and-filename lines, the SHA256SUM file has been tampered with.https://gitlab.torproject.org/legacy/trac/-/issues/5184Spanish TBB contains all Torbutton and Tor Launcher locale files2020-06-16T01:24:30ZRobert RansomSpanish TBB contains all Torbutton and Tor Launcher locale files(Presumably the English TBB contains all of Torbutton's locale files, too.)
Surely we don't need to ship _all_ Torbutton locale files in _all_ TBBs. I wonder how much they enlarge the tarball -- if they're worth shipping, they should b...(Presumably the English TBB contains all of Torbutton's locale files, too.)
Surely we don't need to ship _all_ Torbutton locale files in _all_ TBBs. I wonder how much they enlarge the tarball -- if they're worth shipping, they should be significant.
This is a Bundle build-script issue, not a ...Button issue.https://gitlab.torproject.org/legacy/trac/-/issues/10980Build the Tor Browser User Manual when building Tor Browser2020-06-16T01:24:31ZLunarBuild the Tor Browser User Manual when building Tor BrowserThe Tor Browser User Manual should be built during the Tor Browser building process in order to be included in the bundles.The Tor Browser User Manual should be built during the Tor Browser building process in order to be included in the bundles.https://gitlab.torproject.org/legacy/trac/-/issues/11506Users are confused by the 2000-01-01 00:00 UTC timestamp2020-06-16T01:24:32ZLunarUsers are confused by the 2000-01-01 00:00 UTC timestampPicture yourself: your browser tells you that there is an update. You go get the new shiny thing. And then, when you look at the date on it, it says more than 14 years ago. Confusing, neh?
I guess using the date of the latest Git commit...Picture yourself: your browser tells you that there is an update. You go get the new shiny thing. And then, when you look at the date on it, it says more than 14 years ago. Confusing, neh?
I guess using the date of the latest Git commit would just work great.https://gitlab.torproject.org/legacy/trac/-/issues/11751Add documentation for using TBB with Windows Tor expert bundle2020-06-16T01:24:33ZcypherpunksAdd documentation for using TBB with Windows Tor expert bundleOn Windows, I installed the expert bundle to have a single tor process to be used by multiple applications, including multiple Tor Browsers.
I can configure Tor Browser by creating a user.js file with extensions.torlauncher.start_tor se...On Windows, I installed the expert bundle to have a single tor process to be used by multiple applications, including multiple Tor Browsers.
I can configure Tor Browser by creating a user.js file with extensions.torlauncher.start_tor set to 0. But this config also leads to this message:
"Something Went Wrong!
Tor is not working in this browser."
Other than that, I can use the browser normally.
Can you fix this?https://gitlab.torproject.org/legacy/trac/-/issues/12113Building libevent/openssl on Windows without exception handling would reduce ...2020-06-16T01:24:34ZTom Rittertom@ritter.vgBuilding libevent/openssl on Windows without exception handling would reduce dependenciesI believe that in the Tor Browser Bundle on Windows, for the tor.exe component, libgmpxx-4.dll is built using MinGW with exception handling enabled. (Omits -fno-exceptions). MinGW has an archaic exception handling mechanism on Windows, ...I believe that in the Tor Browser Bundle on Windows, for the tor.exe component, libgmpxx-4.dll is built using MinGW with exception handling enabled. (Omits -fno-exceptions). MinGW has an archaic exception handling mechanism on Windows, using setjmp/longjmp based exceptions and necessitates the extra dll libgcc_s_sjlj-1.dll.
If libgmp was build without exception handling (it appears to only use it 3 or 4 places in the dll), it'd be possible to eliminate libgcc_s_sjlj-1.dll entirely.
EDIT: This is not about libgmp anymore as we don't ship the libgmpxx any longer. Rather, libevent/openssl are affected by that problem, too.https://gitlab.torproject.org/legacy/trac/-/issues/12631Tor Browser for ARM architecture2020-06-16T01:24:36ZMatt PaganTor Browser for ARM architectureThe Tor Project should provide a Tor Browser compatible with the ARMv7 processor. This would provide a safe way of using Tor for users of the Samsung ARM Chromebook, the Samsung Chromebook 2, the Raspberry Pi, the Novena Open Laptop, and...The Tor Project should provide a Tor Browser compatible with the ARMv7 processor. This would provide a safe way of using Tor for users of the Samsung ARM Chromebook, the Samsung Chromebook 2, the Raspberry Pi, the Novena Open Laptop, and probably other platforms too.https://gitlab.torproject.org/legacy/trac/-/issues/12968Specify HEASLR (High Entropy Address Space Layout Randomization) in MinGW-w642020-06-16T01:24:37ZMike PerrySpecify HEASLR (High Entropy Address Space Layout Randomization) in MinGW-w64Mozilla patched mingw-w64 to allow the specification of "high-entropy" ASLR, which is an extra hardened ASLR option on Windows. Not sure if this flag only applies to 64bit builds. I think it might.
Here's their ticket:
https://github.co...Mozilla patched mingw-w64 to allow the specification of "high-entropy" ASLR, which is an extra hardened ASLR option on Windows. Not sure if this flag only applies to 64bit builds. I think it might.
Here's their ticket:
https://github.com/rust-lang/rust/issues/16593
and the patch:
https://sourceware.org/ml/binutils/2014-08/msg00167.html
and it's approval by the Binutils team:
https://sourceware.org/ml/binutils/2014-08/msg00177.htmlhttps://gitlab.torproject.org/legacy/trac/-/issues/13373Get rid of LD_LIBRARY_PATH and use a relative RPATH/RUNPATH in Linux bundles2020-06-16T01:24:39ZGeorg KoppenGet rid of LD_LIBRARY_PATH and use a relative RPATH/RUNPATH in Linux bundlesRelying on LD_LIBRARY_PATH in our start script can cause all sorts of pain (see #13359 for an example). We should take the cleaner approach to compile the binaries that need it with a relative RPATH/RUNPATH and get rid of LD_LIBRARY_PATH...Relying on LD_LIBRARY_PATH in our start script can cause all sorts of pain (see #13359 for an example). We should take the cleaner approach to compile the binaries that need it with a relative RPATH/RUNPATH and get rid of LD_LIBRARY_PATH. We need to adapt our tests as well to make the pass if a RPATH/RUNPATH with ${ORIGIN} is showing up.https://gitlab.torproject.org/legacy/trac/-/issues/13770BusyBox-style bundling of Go programs can save space2020-06-16T01:24:40ZDavid Fifielddcf@torproject.orgBusyBox-style bundling of Go programs can save spaceMike suggested that compiling all the Go programs into one executable à la BusyBox could save space because there would be only one static copy of the Go runtime.Mike suggested that compiling all the Go programs into one executable à la BusyBox could save space because there would be only one static copy of the Go runtime.https://gitlab.torproject.org/legacy/trac/-/issues/13890Provide support for urdu language in Tor Browser2020-06-16T01:24:40ZArturo FilastòProvide support for urdu language in Tor BrowserCurrently Tor Browser does not support the urdu language.
Implementing this feature, though, is blocking on having an ESR of Firefox that supports such language, that will probably not happen before August 2015.
Support for urdu in Fir...Currently Tor Browser does not support the urdu language.
Implementing this feature, though, is blocking on having an ESR of Firefox that supports such language, that will probably not happen before August 2015.
Support for urdu in Firefox was just recently announced: http://mozilla-pakistan.org/2014/05/12/new-firefox-launch-event-pakistan/ and xpi's for it are only shipped in their alpha builds: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora-l10n/mac/xpi/.
When that is done the TorButton and TorLauncher components would need to be translated.
It's probably a good idea to implement this as part of #12967.https://gitlab.torproject.org/legacy/trac/-/issues/15710Consider enabling the BCJ filter when packaging bundles.2020-06-16T01:24:41ZYawning AngelConsider enabling the BCJ filter when packaging bundles.xz (and xz embedded) supports branch/call/jump filters that is supposed to reduce compressed executable size. The documentation hints that the compression ratio can end up being worse in certain situations, but as far as I can tell, it ...xz (and xz embedded) supports branch/call/jump filters that is supposed to reduce compressed executable size. The documentation hints that the compression ratio can end up being worse in certain situations, but as far as I can tell, it helps.
Numbers (tested with `tor-browser-linux64-4.5a5_en-US.tar.xz`):
* Current settings: 43667412 (1.0)
* `xz -9`: 43463244 (0.99)
* `xz --x86 --lzma2`: 42621816 (0.976)
* `xz --x86 --lzma2=preset=9`: 42402308 (0.971)
The "extreme" setting doesn't help the bundle compression enough to be worth it, and it would increase the already long build time even further.
The improvement isn't absolutely massive, but ~1 MiB is ~1 MiB. Since we only currently build x86(_64) bundles, adding `export XZ_OPT="--x86 --lzma2"` or similar to the top of `dtar.sh` should be sufficient, adjust presets to taste.
(There is also an Little Endian ARM BCJ filter, along with filters for architectures that we don't care about.)https://gitlab.torproject.org/legacy/trac/-/issues/17336consider re-dzip'ing language packs2020-06-16T01:24:41ZMark Smithconsider re-dzip'ing language packsWhile doing some MAR file generation experiments, Kathy and I found that running re-dzip.sh on the Firefox language packs resulted in smaller incremental MAR files. Unfortunately, we did not make a note of the number of bytes saved. We s...While doing some MAR file generation experiments, Kathy and I found that running re-dzip.sh on the Firefox language packs resulted in smaller incremental MAR files. Unfortunately, we did not make a note of the number of bytes saved. We should repeat this experiment to determine whether it is worthwhile to re-dzip the language packs.https://gitlab.torproject.org/legacy/trac/-/issues/17379Using the same build process in Tor Browser and Tor Messenger2020-06-16T01:24:42ZboklmUsing the same build process in Tor Browser and Tor MessengerThe current Tor Browser build process is using gitian to run the build inside virtual machines, with some shell scripts to download and verify dependencies.
Tor Messenger is using a different system to do that.
To make maintenance easi...The current Tor Browser build process is using gitian to run the build inside virtual machines, with some shell scripts to download and verify dependencies.
Tor Messenger is using a different system to do that.
To make maintenance easier, we should try to use the same tools in both projects.
I think one of the main advantages of the way we are building in tor-messenger is that we can do faster builds as we rebuild only what is necessary. All components are built separately, with all built components having an identifier in their filename that is a hash of all their dependencies (build script, commit hash, source tarballs,
distribution used in the container, additional packages installed). We only rebuild a component when its identifier has changed. We currently only have one branch on tor messenger, but with multiple branches (alpha, beta, nightly, etc ...) it would be possible to build the different branches from the same build repository and share the components that are identical.
An other advantage of splitting the build of each component is to be able to share them between different projects. For instance we are also building a Tor Mail bundle from the same repository and sharing some of the components. In the case of Tor Browser and Tor Messenger I think we could share the compilers. Components can also be built differently
depending on which project they are built for, for instance tor-launcher is patched to use a different control port for tor-mail and tor-messenger:
https://gitweb.torproject.org/tor-messenger-build.git/tree/projects/tor-launcher/controlport.patch.tmpl
https://gitweb.torproject.org/tor-messenger-build.git/tree/rbm.conf#n74
I will open child tickets to list all the tasks that need to be done if we want Tor Browser to use the same build process as Tor Messenger.https://gitlab.torproject.org/legacy/trac/-/issues/17381Adapting the gitian/*.sh release scripts2020-06-16T01:24:43ZboklmAdapting the gitian/*.sh release scriptsThe various gitian/*.sh scripts will need to be adapted.The various gitian/*.sh scripts will need to be adapted.https://gitlab.torproject.org/legacy/trac/-/issues/17382Using tor to download all build dependencies2020-06-16T01:24:43ZboklmUsing tor to download all build dependenciesThe current Tor Messenger build process does not use tor to download the various build dependencies. We should add an option (on by default) to do that and allow anonymous builders.The current Tor Messenger build process does not use tor to download the various build dependencies. We should add an option (on by default) to do that and allow anonymous builders.https://gitlab.torproject.org/legacy/trac/-/issues/18325We should not depend on rebuilding Firefox to get a new Tor Browser version out2020-06-16T01:24:44ZGeorg KoppenWe should not depend on rebuilding Firefox to get a new Tor Browser version outIn case we need to bump OpenSSL or think about just rebundling for a new release we need to rebuild Firefox too, currently, as the Tor Browser version is getting set there. We should find a way to avoid that.In case we need to bump OpenSSL or think about just rebundling for a new release we need to rebuild Firefox too, currently, as the Tor Browser version is getting set there. We should find a way to avoid that.https://gitlab.torproject.org/legacy/trac/-/issues/18326Creating incremental MAR files should not include Tor Browser version in meta...2020-06-16T01:24:45ZGeorg KoppenCreating incremental MAR files should not include Tor Browser version in meta dataWhile trying to build the incrementals for 5.5.2 on a machine that had older mar-tools I ended up with them not matching incrementals built on other machines. Upon investigation it turned out that the browser versions gets embedded in th...While trying to build the incrementals for 5.5.2 on a machine that had older mar-tools I ended up with them not matching incrementals built on other machines. Upon investigation it turned out that the browser versions gets embedded in the MAR files' metadata. There is no need for doing that actually.https://gitlab.torproject.org/legacy/trac/-/issues/18867Ship auto-updates for Tor Browser nightly channel2020-06-16T01:24:47ZGeorg KoppenShip auto-updates for Tor Browser nightly channelWe want to get more users to test our nightly builds. The main hurdle currently is the missing auto-update. This is the parent ticket that tracks this task.We want to get more users to test our nightly builds. The main hurdle currently is the missing auto-update. This is the parent ticket that tracks this task.https://gitlab.torproject.org/legacy/trac/-/issues/19181Firefox >= 48 ships with an ICU pre-compiled blob2020-06-16T01:24:47ZGeorg KoppenFirefox >= 48 ships with an ICU pre-compiled blobIn https://bugzilla.mozilla.org/show_bug.cgi?id=1239083 Mozilla implemented build changes that resulted in an ICU related binary being shipped in the source tree. It is a pre-compiled thing to avoid generating it twice e.g. in a cross-co...In https://bugzilla.mozilla.org/show_bug.cgi?id=1239083 Mozilla implemented build changes that resulted in an ICU related binary being shipped in the source tree. It is a pre-compiled thing to avoid generating it twice e.g. in a cross-compilation scenario. We should investigate whether we want to ship that blob.