The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-03-24T23:28:17Zhttps://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/46Gitlab should show text files in the browser2022-03-24T23:28:17ZGeorg KoppenGitlab should show text files in the browserRight now if I want to look at some .md or .txt file on Gitlab I need to
download and open it with an external application. However, that should
not be necessary. The browser should be sufficient for this task.Right now if I want to look at some .md or .txt file on Gitlab I need to
download and open it with an external application. However, that should
not be necessary. The browser should be sufficient for this task.https://gitlab.torproject.org/tpo/anti-censorship/emma/-/issues/3Increase test timeout2020-09-01T01:16:02ZPhilipp Winterphw@torproject.orgIncrease test timeoutEmma currently labels a test as failed if it didn't get a response within three seconds. That's a rather low timeout. We should probably change it to five seconds, if not more.Emma currently labels a test as failed if it didn't get a response within three seconds. That's a rather low timeout. We should probably change it to five seconds, if not more.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/34203Some of the static libraries we build are not reproducible2023-01-05T14:34:24ZGeorg KoppenSome of the static libraries we build are not reproducibleI just realized that the `.a` archives we create (e.g.) for `libevent` on android are not reproducible while their contents are. We should fix that as it makes it easier to compare results and spot problems.
While we are at it we should...I just realized that the `.a` archives we create (e.g.) for `libevent` on android are not reproducible while their contents are. We should fix that as it makes it easier to compare results and spot problems.
While we are at it we should check other outputs as well as I bet not only `lilbevent` is affected.
FWIW: In the `libevent` case it seems timestamps play a role when creating the `.a` files.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/32200only include required bits of OpenSSL in Android builds2022-10-06T01:19:52Zeighthaveonly include required bits of OpenSSL in Android buildsI've been doing some experiments to make the Android _libtor.so_ binaries smaller. One of them is building OpenSSL with as many things as possible turned off. This does make the resulting binary smaller. Here's what I tried:
```
$ ./...I've been doing some experiments to make the Android _libtor.so_ binaries smaller. One of them is building OpenSSL with as many things as possible turned off. This does make the resulting binary smaller. Here's what I tried:
```
$ ./Configure \
no-comp no-dtls no-ec2m no-psk no-srp no-ssl2 no-ssl3 \
no-camellia no-idea no-md2 no-md4 no-mdc2 no-rc2 no-rc4 no-rc5 no-rmd160 no-whirlpool \
no-dso no-engine no-hw no-ui-console \
no-shared no-unit-test \
```
The open question is whether the test coverage is good enough to know whether this breaks anything.
Additionally, I think Android _ndk-build_ used to 'gcc' "gc sections" to mark unused code blocks which were then stripped out at the end. They seemed to have stopped doing this with _clang_, but I don't know why. In the past, I have seen the "gc sections" stripping reduce binary size quite a bit.
Also related: I tried building with `-Os` and `-Oz` instead of `-O2`. That made a big difference:
https://github.com/guardianproject/tor-android/issues/18
This is related to legacy/trac#28764https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/31581KDE Desktop file error2022-10-06T01:19:17ZTracKDE Desktop file errorThe freedesktop spec for .desktop files requires the '\' char be escaped. In your desktop file, the Exec= command contains a continuation char with the rest of the command on the next line. Kwinini flags that as an error, no '='.
To fix...The freedesktop spec for .desktop files requires the '\' char be escaped. In your desktop file, the Exec= command contains a continuation char with the rest of the command on the next line. Kwinini flags that as an error, no '='.
To fix, replace the end of the Exec command with "\\" which escapes the bash continuation char.
Tor v8.5.4
**Trac**:
**Username**: Psnarfhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/31321Add cc -> gcc link to projects/gcc2022-08-05T15:06:01ZboklmAdd cc -> gcc link to projects/gccThere are a few places where we add a `cc -> gcc` symbolic link:
```
projects/clang/build: ln -s gcc /var/tmp/dist/gcc/bin/cc
projects/firefox/build: ln -s gcc /var/tmp/dist/gcc/bin/cc
projects/llvm/build: ln -s gcc /var/tmp/dist/gcc/...There are a few places where we add a `cc -> gcc` symbolic link:
```
projects/clang/build: ln -s gcc /var/tmp/dist/gcc/bin/cc
projects/firefox/build: ln -s gcc /var/tmp/dist/gcc/bin/cc
projects/llvm/build: ln -s gcc /var/tmp/dist/gcc/bin/cc
projects/nasm/build: ln -s gcc /var/tmp/dist/gcc/bin/cc
projects/node/build: ln -s gcc /var/tmp/dist/gcc/bin/cc
```
Instead of creating this link in each project where it is needed, maybe we could create it only one time, during the build of gcc in `projects/gcc/build`.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/26650Update d3dcompiler_47.dll to latest version in Tor Browser (10.0.15063.675)2022-11-16T09:36:20ZGeorg KoppenUpdate d3dcompiler_47.dll to latest version in Tor Browser (10.0.15063.675)A user on the blog (https://blog.torproject.org/comment/275958#comment-275958) mentioned there is a newer version of the d3dcompiler_47 library we ship with Tor Browser and strongly suggested to update the one we provide.A user on the blog (https://blog.torproject.org/comment/275958#comment-275958) mentioned there is a newer version of the d3dcompiler_47 library we ship with Tor Browser and strongly suggested to update the one we provide.Sponsor 131 - Phase 5 - Ongoing MaintenancePier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/25863Check where the -mwindows flag is needed2023-01-05T12:42:49ZboklmCheck where the -mwindows flag is neededCurrently we are setting the `-mwindows` flag by default in `CFLAGS` and `LDFLAGS` defined in `rbm.conf`, which are currently used (through `var/configure_opt`) in tor, gmp, libevent and go.
We should check where this flag is really nee...Currently we are setting the `-mwindows` flag by default in `CFLAGS` and `LDFLAGS` defined in `rbm.conf`, which are currently used (through `var/configure_opt`) in tor, gmp, libevent and go.
We should check where this flag is really needed, and only set it there.Sponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/22633Running ./start-tor-browser.desktop --detach --log creates two log files2022-08-03T14:52:38ZGeorg KoppenRunning ./start-tor-browser.desktop --detach --log creates two log filesAdding `--detach` explicitely creates two log files one inside the current working directory containing all the logs (which is okay) and an empty one in the parent directory (which is not okay).
This got reported on our blog: https://bl...Adding `--detach` explicitely creates two log files one inside the current working directory containing all the logs (which is okay) and an empty one in the parent directory (which is not okay).
This got reported on our blog: https://blog.torproject.org/comment/269202#comment-269157.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/19181Firefox >= 48 ships with an ICU pre-compiled blob2023-01-05T14:10:02ZGeorg 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.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/18130Fold in pre 3.0 Tor Browser changelogs2023-02-09T09:50:44ZGeorg KoppenFold in pre 3.0 Tor Browser changelogsWe should fold in the pre 3.0 Tor Browser changelogs for reference purposes. They are right here: https://gitweb.torproject.org/torbrowser.git/tree/?h=maint-2.4. Might be a bit of work to sort all the things out and get that into the for...We should fold in the pre 3.0 Tor Browser changelogs for reference purposes. They are right here: https://gitweb.torproject.org/torbrowser.git/tree/?h=maint-2.4. Might be a bit of work to sort all the things out and get that into the format we use today, but it's worthwhile.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34370Improve identity doorhanger message during failed onion authentication2022-11-30T16:59:26ZAntonelaantonela@torproject.orgImprove identity doorhanger message during failed onion authenticationWhen you visit an onion site that requires authentication and you click cancel, then you click the circled-i button to the left of the URL, it says connection is not secure.
But there is no connection, and any handshake-type stuff that ...When you visit an onion site that requires authentication and you click cancel, then you click the circled-i button to the left of the URL, it says connection is not secure.
But there is no connection, and any handshake-type stuff that happens is all secure, right? Maybe it's not an issue but I thought I'd just bring it up.
via https://blog.torproject.org/comment/288072#comment-288072https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/33955Selecting "Copy image" from menu leaks the source URL to the clipboard. This ...2023-10-03T15:37:49ZTracSelecting "Copy image" from menu leaks the source URL to the clipboard. This data is often dereferenced by other applications.Right-clicking an image and selecting "Copy image" from the context-menu leaks the source URL to the clipboard. In many applications, pasting the image leads to the URL being dereferenced, and a clearnet web request can result, instead o...Right-clicking an image and selecting "Copy image" from the context-menu leaks the source URL to the clipboard. In many applications, pasting the image leads to the URL being dereferenced, and a clearnet web request can result, instead of the bitmap simply being pasted. This is dangerous and unexpected behaviour that stems from Firefox.
11 formats are placed on the clipboard during an image copy. 3 of these contain the URL, 2 of which contain further tag metadata:
49318 'HTML Format' - this contains the entire source HTML of the <img> element, inside a comment, wrapped in a minimal HTML document, and a header containing the offsets
49419 'text/html' - this also contains the source HTML of the <img> element
49426 'application/x-moz-file-promise-url' - this contains the plain source URL.
While some might argue that this is appropriate in Firefox, it's an unexpected information leak in the Tor Browser.
My suggestion would be to change the menu items to:
- Copy image
- Copy image location
- Copy image as HTML
**Copy image** would copy only raw image pixels as an uncompressed bitmap. This ensures there is no metadata in the image, and also ensures that increasingly common things like WebP don't break everything. It also fixes unexpected behaviour with respect to dynamically generated or uncached images, ensuring that what the user sees is exactly what ends up in the clipboard, without any extra web requests in the target application.
**Copy image location** would copy, in plaintext, the source URL of the image.
**Copy image as HTML** would copy or create a sanitised version of the <img> tag (i.e. onclick handlers etc would be stripped, leaving only alt text, width and height and perhaps eventually a filtered version of any embedded CSS).
I believe each of those menu options would behave as everyone would expect, without any unexpected information leakage issues.
(I have set severity as major and priority high, since this has the potential to deanonymise a user before they realise what's happened, but is probably a relatively easy fix. Presumably this would be regarded as the most important kind of bug, but I don't know the convention here.)
**Trac**:
**Username**: peskydanhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/33849Maybe disable Windows Hello2022-11-30T13:27:45ZrichardMaybe disable Windows HelloIf we want to disable Windows Hello and associated biometrics queries in Tor Browser it looks like we can patch various IsUserVerifyingPlatformAuthenticatorAvailable calls to always return false.
It seems like there was a bit of a refac...If we want to disable Windows Hello and associated biometrics queries in Tor Browser it looks like we can patch various IsUserVerifyingPlatformAuthenticatorAvailable calls to always return false.
It seems like there was a bit of a refactor to wrap both Windows Hello as well hardware tokens like yubikeys(?) into the same authentication system so we need to take care to not break support for these.
See this patch: https://bugzilla.mozilla.org/show_bug.cgi?id=1508115
The library Mozilla is using to add Windows Hello support: https://github.com/Microsoft/webauthnhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/33298HTTP onion sites do not give a popup warning when submitting form data to non...2023-06-11T04:21:10ZrichardHTTP onion sites do not give a popup warning when submitting form data to non-onion HTTP sitesIn vanilla firefox, HTTPS site with a form that submits to an HTTP site will put up a pop-up box warning the user they are about to send their data unencrypted across the network. Tor Browser follows this behaviour, but it also needs to ...In vanilla firefox, HTTPS site with a form that submits to an HTTP site will put up a pop-up box warning the user they are about to send their data unencrypted across the network. Tor Browser follows this behaviour, but it also needs to do so when submitting data from an HTTP onionsite to a vanilla HTTP site.ma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/32988What a horrible, useless feature that'll come back and bite you in your ass s...2020-06-27T14:32:08ZTracWhat a horrible, useless feature that'll come back and bite you in your ass some dayWhat a horrible, useless feature that'll come back and bite you in your ass some day
**Trac**:
**Username**: wazaaaahWhat a horrible, useless feature that'll come back and bite you in your ass some day
**Trac**:
**Username**: wazaaaahhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/32861"Fingerprint.js PRO" successfully fingerprints Tor Browser2023-09-01T00:28:52ZTrac"Fingerprint.js PRO" successfully fingerprints Tor BrowserNot affiliated with the site. Demo: https://fingerprintjs.com/demo.
When using Tor Browser 68.3.0esr on macOS Catalina, this site is capable of successfully fingerprinting me across multiple visits with a different identity each time.
...Not affiliated with the site. Demo: https://fingerprintjs.com/demo.
When using Tor Browser 68.3.0esr on macOS Catalina, this site is capable of successfully fingerprinting me across multiple visits with a different identity each time.
Steps to reproduce:
1. Visit https://fingerprintjs.com/demo in the Tor Browser.
2. Click the "New Identity" button.
3. Wait a little bit to avoid timing correlation.
4. Revisit the website.
Screenshot of the fingerprinting: https://i.ibb.co/SvWsP4K/image.png.
A potential solution is taking some features from the "Trace" Firefox add-on (not affiliated): https://addons.mozilla.org/en-US/firefox/addon/absolutedouble-trace/. It prevented Fingerprint.js from successfully fingerprinting anything. Every time I created a "New Identity" in the Tor Browser and visited the website, it gave me a new identifier, with no record of my past visits.
When using the Firefox add-on "Canvas Blocker", Fingerprint.js was still capable of identifying me across identities.
Here are the Trace features I have enabled: https://i.ibb.co/BPCbWCk/image.png.
Here are the advanced Trace features I have enabled: https://i.ibb.co/8bmNYxL/image.png.
**Trac**:
**Username**: printerman22https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/32544Create Style Guides2023-01-05T15:49:18ZMatthew FinkelCreate Style GuidesFollowing legacy/trac#26184, we should document our coding style preferences. We should consider documenting all Tor Browser-related projects.Following legacy/trac#26184, we should document our coding style preferences. We should consider documenting all Tor Browser-related projects.Sponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/31814Moving Tor Browser onto SD Card breaks app on Android2022-07-20T14:56:05ZMatthew FinkelMoving Tor Browser onto SD Card breaks app on AndroidWe received a report that the app breaks when it is moved onto an external SD Card (or additional storage partition).
```
- Einstellungen im Tor-Dienst werden aktualisiert
- updating torrc custom configuration...
- success.
- checki...We received a report that the app breaks when it is moved onto an external SD Card (or additional storage partition).
```
- Einstellungen im Tor-Dienst werden aktualisiert
- updating torrc custom configuration...
- success.
- checking binary version: 0.3.5.8-rc-openssl1.0.2p
- Orbot startet ...
- Unable to start Tor: java.io.IOException: Cannot run program
"/mnt/sdcard/org.torproject.torbrowser-1/lib/arm64/libTor.so" (in
directory
"/data/user/0/org.torproject.torbrowser/app_torservice"):
error=13, Permission denied
```
It seems like tor-android-service is expecting a relative path for `libTor.so` within the app's local storage, but it is receiving an absolute path somewhere else.
Moving Fennec onto an sdcard works, so we can see how geckoview loads libxul.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/30668Mobile: Favicon is not used when making a shortcut on Home screen2022-07-20T14:52:54ZTracMobile: Favicon is not used when making a shortcut on Home screen- Tor Browser and Tor Broswer (Alpha):
- Press the three dotted button in the top right,
- Select "Page >",
- Select "Add to home screen".
- A button on the home screen appears, but is missing the favicon.
Would the proper behaviour be ...- Tor Browser and Tor Broswer (Alpha):
- Press the three dotted button in the top right,
- Select "Page >",
- Select "Add to home screen".
- A button on the home screen appears, but is missing the favicon.
Would the proper behaviour be to download the largest favicon possible and then resize it down on the client-side to avoid resquesting an icon dize that might identify the client os?
NOTE: Old Orfox appears to function correctly, in that the icon is used and it appears brilliant and sharp (ie. high-resolution).
**Trac**:
**Username**: torlove