New Alpha Release: Tor Browser 13.5a8
Tor Browser 13.5a8 is now available from the Tor Browser download page and also from our distribution directory.
This version includes important security updates to Firefox.
We would like to thank the folowing community members for their contributions this release:
If you would like to contribute, our contributor guide can be found here.
End of Life for Windows versions ≤ 8.1 and macOS versions ≤ 10.14
Users running Tor Browser on older versions of Windows and macOS will start seeing messages warning them their operating systems will no longer be supported. This is an upstream change we are inheriting from Mozilla. Starting with version 116 Firefox Windows users will require Windows 10 or later while macOS users will require macOS 10.15 or later to continue receiving Tor Browser updates. Users have until October 1st, 2024 to upgrade!
Continued Improvements on Android!
This release has removed the legacy bootstrapping functionality from Tor Browser for Android entirely. This legacy functionality depended on the tor-android-service and tor-onion-proxy-library components. With this functionality gone and replaced with the unified Tor backend living in GeckoView, we will be able to drop these components in the next release, which should result in slightly smaller .apk sizes.
We have made a few UI changes and improvements with this release. The UI which allowed users to fallback to the legacy bootstrapping process has been removed (since the backend is also gone).
Additionally various Android-specific privacy and security bugs have been fixed.
Various User Experience Improvements
On desktop, we have been working on various UI improvements and polish. The about:torconnect (aka Connect Assist) page has been restyled to better fit with Firefox's existing UI. We have also fixed various minor bugs related to letterboxing, the onion-service client-authentication dialgo, and the circuit display.
Send us your feedback
If you find a bug or have a suggestion for how we could improve this release, please let us know.
Full changelog
The full changelog since Tor Browser 13.5a7 is:
- All Platforms
- Windows + macOS + Linux
- Windows + macOS
- Linux
- Android
- Build System
Fri, 17 May 2024, 12:00 am
Join us for the Tor Community Day 2024 in Lisbon
The Tor Project is happy to announce that we are hosting the Tor Community Day 2024 on May 25th in Lisbon, Portugal! The Community Day is a great opportunity for Tor Core Contributors, Tor Community Members, and other interested folks to come together, connect and discuss all things Tor.
If you want to learn more about how Tor works, its impact in Portugal, how you can become a contributor–or simply want to discuss various topics related to free and open-source software, censorship circumvention, privacy and more–this event is for you!
When
- Date: May 25th, 2024
- Time: 9:00 AM to 5:00 PM. (There will be an hour and a half break for lunch.)
Where
- Location: Universidade NOVA de Lisboa, Colégio Almada Negreiros, Room 209.
Who
- Organizers: The Tor Project and PrivacyLx
- The Tor Community Day is free and open to the public. Anyone who wishes to join is welcome without any prior need to sign up. If you're curious about Tor, stop by!
Program
- This is a bilingual event: The first half of the event will be in English, the second half in Portuguese.
- We'll have talks from the Tor Project and from members of the community in Portugal.
- Be on the lookout for updates about the schedule and participating projects on our social channels and the Tor forum.
We are excited to meet you later this month!
-The Tor Project
Junta-te a nós para o Dia da Comunidade do Tor de 2024 em Lisboa
O Projeto Tor tem o prazer de anunciar que vamos organizar o Dia da Comunidade do Tor de 2024 no dia 25 de maio em Lisboa, Portugal! O Dia da Comunidade é uma grande oportunidade para os principais colaboradores do Tor, membros da comunidade do Tor e outras pessoas interessadas se reunirem, se conectarem e discutirem todas as coisas relacionadas com o Tor.
Se queres saber mais sobre como o Tor funciona, o seu impacto em Portugal, como te podes tornar um contribuidor - ou simplesmente queres discutir vários tópicos relacionados com software livre e de código aberto, evasão à censura, privacidade e muito mais - este evento é para ti!
Quando
- Data: 25 de maio de 2024
- Horário: 9h às 17h. (Haverá um intervalo de uma hora e meia para o almoço).
Onde
- Localização: Universidade NOVA de Lisboa, Colégio Almada Negreiros, Sala 209.
Quem
- Organizadores: The Tor Project e PrivacyLx
- O Dia da Comunidade do Tor é gratuito e aberto ao público. Qualquer pessoa que deseje participar é bem-vinda sem necessidade de se inscrever previamente. Se estiveres curioso sobre o Tor, aparece!
Programa
- Este é um evento bilingue: A primeira metade do evento será em inglês, a segunda metade em português.
- Teremos palestras do Projeto Tor e de membros da comunidade em Portugal.
- Estejam atentos a actualizações sobre a programação e os projectos participantes nos nossos canais sociais e no fórum Tor.
Estamos ansiosos por vos encontrar no final deste mês!
-The Tor Project
Wed, 15 May 2024, 12:00 am
Security release: Arti 1.2.3. (Please upgrade.)
We have released updates to Arti today,
to resolve a pair of security issues
related to circuit construction for onion services.
These vulnerabilities affect the crate tor-circmgr 0.18.0,
released along with Arti version 1.2.2.
They are fixed in tor-circmgr 0.18.1.
(Fixes will also appear in Arti version 1.2.4,
to be released on our regular schedule at the start of June.)
Who is affected
If you use arti to connect to onion services,
or to run onion services,
and you are using Arti 1.2.2 or tor-circmgr 0.18.0,
you should upgrade.
(In Arti 1.2.1 and earlier, vanguards were still an experimental feature,
or absent, so those versions are classified as "not affected",
but downgrading to these versions will not improve your security.)
Upgrade instructions
If you installed Arti via cargo install, use this command to update:
cargo install --locked --features=full arti
# or whatever --features you used before
If you obtained Arti as source code from git, fetch the tag arti-v1.2.3
and rebuild, with cargo build --locked --release --features=full -p arti.
The issues
Both issues affect circuit construction when vanguards are enabled,
and affect the length.
First, when building anonymizing circuits to or from an onion service with
'lite' vanguards (the default) enabled,
the circuit manager code would build the circuits with one hop too few.
This makes users of this code more vulnerable to some kinds of traffic analysis
when they run or visit onion services.
This bug is tracked as issue #1409, and as TROVE-2024-003.
Its severity is "high".
Second, when 'full' vanguards are enabled, some circuits are supposed to be
built with an extra hop to minimize the linkability of the guard nodes.
In some circumstances,
the circuit manager would build circuits with one hop too few,
making it easier for an adversary to discover the L2 and L3 guards
of the affected clients and services.
This issue is tracked as issue #1400, and as TROVE-2024-004.
Its severity is "medium".
Wed, 15 May 2024, 12:00 am
Arti 1.2.2 is released: onion services development
Arti is our ongoing project to create a next-generation Tor client in
Rust. Now we're announcing the latest release, Arti 1.2.2.
This release continues improvements to the security of onion services
(for example, Arti now supports Vanguards for improved security
against guard discovery for onion service circuits).
It also fixes a few bugs, such as #1379.
Even more security improvements are on the way.
See doc/OnionService.md for instructions and caveats about running
onion services with Arti today.
Also,
we've overhauled the configuration reader to use figment,
and
we're picking up the pace on the planned RPC system,
which will allow Arti to be managed and controlled programmatically.
For more information on using Arti, see our top-level README, and the
documentation for the arti binary.
Thanks to everybody who's contributed to this release, including
Alexander Færøy, Jim Newsome, Richard Pospesel, trinity-1686a,
Wiktor Kwapisiewicz, and VaiTon.
Also, our deep thanks to Zcash Community Grants and our other sponsors
for funding the development of Arti!
Tue, 30 Apr 2024, 12:00 am
Tor migrates from Gitolite/GitWeb to GitLab
Tor has finally completed a long migration from legacy Git
infrastructure (Gitolite and GitWeb) to our self-hosted
GitLab server.
Git repository addresses have therefore changed. Many of you probably
have made the switch already, but if not, you will need to change:
https://git.torproject.org/
to:
https://gitlab.torproject.org/
In your Git configuration.
The GitWeb front page is now an archived listing of all the
repositories before the migration. Inactive git repositories were
archived in GitLab legacy/gitolite namespace and the
gitweb.torproject.org and git.torproject.org web sites now
redirect to GitLab.
Best effort was made to reproduce the original gitolite repositories
faithfully and also avoid duplicating too much data in the
migration. But it's possible that some data present in Gitolite has
not migrated to GitLab.
User repositories are particularly at risk, because they were
massively migrated, and they were "re-forked" from their upstreams, to
avoid wasting disk space. If a user had a project with a matching name
it was assumed to have the right data, which might be inaccurate.
The two virtual machines responsible for the legacy service (cupani
for git-rw.torproject.org and vineale for git.torproject.org and
gitweb.torproject.org) have been shutdown. Their disks will remain
for 3 months (until the end of July 2024) and their backups for
another year after that (until the end of July 2025), after which
point all the data from those hosts will be destroyed, with only the
GitLab archives remaining.
The rest of this article expands on how this was done and what kind of
problems we faced during the migration.
Where is the code?
Normally, nothing should be lost. All repositories in gitolite have
been either explicitly migrated by their owners, forcibly migrated by
the sysadmin team (TPA), or explicitly destroyed at their owner's
request.
An exhaustive rewrite map translates gitolite projects to GitLab
projects. Some of those projects actually redirect to their parent
in cases of empty repositories that were obvious forks. Destroyed
repositories redirect to the GitLab front page.
Because the migration happened progressively, it's technically
possible that commits pushed to gitolite were lost after the
migration. We took great care to avoid that scenario. First, we
adopted a proposal (TPA-RFC-36) in June 2023 to announce the
transition. Then, in March 2024, we locked down all repositories
from any further changes. Around that time, only a handful of
repositories had changes made after the adoption date, and we
examined each repository carefully to make sure nothing was lost.
Still, we built a diff of all the changes in the git references
that archivists can peruse to check for data loss. It's large (6MiB+)
because a lot of repositories were migrated before the mass migration
and then kept evolving in GitLab. Many other repositories were rebuilt
in GitLab from parent to rebuild a fork relationship which added extra
references to those clones.
A note to amateur archivists out there, it's probably too late for one
last crawl now. The Git repositories now all redirect to GitLab and
are effectively unavailable in their original form.
That said, the GitWeb site was crawled into the Internet Archive in
February 2024, so at least some copy of it is available in the
Wayback Machine. At that point, however, many developers had already
migrated their projects to GitLab, so the copies there were already
possibly out of date compared with the repositories in GitLab.
Software Heritage also has a copy of all repositories hosted on
Gitolite since June 2023 and have continuously kept mirroring the
repositories, where they will be kept hopefully in eternity. There's
an issue where the main website can't find the repositories when
you search for gitweb.torproject.org, instead search for
git.torproject.org.
In any case, if you believe data is missing, please do let us know by
opening an issue with TPA.
Why?
This is an old project in the making. The first discussion about
migrating from gitolite to GitLab started in 2020 (almost 4 years
ago). But going further back, the first GitLab experiment was in
2016, almost a decade ago.
The current GitLab server dates from 2019, replacing Trac for issue
tracking in 2020. It was originally supposed to host only mirrors
for merge requests and issue trackers but, naturally, one thing led to
another and eventually, GitLab had grown a container registry,
continuous integration (CI) runners, GitLab Pages, and, of course,
hosted most Git repositories.
There were hesitations at moving to GitLab for code hosting. We had
discussions about the increased attack surface and ways to
mitigate that, but, ultimately, it seems the issues were not that
serious and the community embraced GitLab.
TPA actually migrated its most critical repositories out of shared
hosting entirely, into specific servers (e.g. the Puppet Git
repository is just on the Puppet server now), leveraging Git's
decentralized nature and removing an entire attack surface from our
infrastructure. Some of those repositories are mirrored back into
GitLab, but the authoritative copy is not on GitLab.
In any case, the proposal to migrate from Gitolite to GitLab was
effectively just formalizing a fait accompli.
How to migrate from Gitolite / cgit to GitLab
The progressive migration was a challenge. If you intend to migrate
between hosting platforms, we strongly recommend to make a "flag day"
during which you migrate all repositories at once. This ensures a
smoother transition and avoids elaborate rewrite rules.
When Gitolite access was shutdown, we had repositories on both GitLab
and Gitolite, without a clear relationship between the two. A priori,
the plan then was to import all the remaining Gitolite repositories
into the legacy/gitolite namespace, but that seemed wasteful,
particularly for large repositories like Tor Browser which uses
nearly a gigabyte of disk space. So we took special care to avoid
duplicating repositories.
When the mass migration started, only 71 of the 538 Gitolite
repositories were Migrated to GitLab in the gitolite.conf
file. So, given that we had hundreds of repositories to migrate:, we
developed some automation to "save time". We already automate
similar ad-hoc tasks with Fabric, so we used that framework here
as well. (Our normal configuration management tool is Puppet,
which is a poor fit here.)
So a relatively large amount of Python code was produced to
basically do the following:
- check if all on-disk repositories are listed in
gitolite.conf
(and vice versa) and either add missing repositories or delete
them from disk if garbage
- for each repository in
gitolite.conf, if its category is marked
Migrated to GitLab, skip, otherwise;
- find a matching GitLab project by name, prompt the user for
multiple matches
- if a match is found, redirect if the repository is non-empty
- we have GitLab projects that look like the real thing, but are
only present to host migrated Trac issues
- in such cases we cloned the Gitolite project locally and pushed
to the existing repository instead
- otherwise, a new repository is created in the
legacy/gitolite
namespace, using the "import" mechanism in GitLab to automatically
import the repository from Gitolite, creating redirections and
updating gitolite.conf to document the change
User repositories (those under the user/ directory in Gitolite) were
handled specially. First, the existing redirection map was checked to
see if a similarly named project was migrated (so that,
e.g. user/dgoulet/tor is properly treated as a fork of
tpo/core/tor). Then the parent project was forked in GitLab and the
Gitolite project force-pushed to the fork. This allows us to show the
fork relationship in GitLab and, more importantly, benefit from the
"pool" feature in GitLab which deduplicates disk usage between forks.
Sometimes, we found no such relationships. Then we simply imported
multiple repositories with similar names in the legacy/gitolite
namespace, sometimes creating forks between user repositories, on a
first-come-first-served basis from the gitolite.conf order.
The code used in this migration is now available publicly. We
encourage other groups planning to migrate from Gitolite/GitWeb to
GitLab to use (and contribute to) our fabric-tasks repository,
even though it does have its fair share of hard-coded assertions.
The main entry point is the gitolite.mass-repos-migration task. A
typical migration job looked like:
anarcat@angela:fabric-tasks$ fab -H cupani.torproject.org gitolite.mass-repos-migration
[...]
INFO: skipping project project/help/infra in category Migrated to GitLab
INFO: skipping project project/help/wiki in category Migrated to GitLab
INFO: skipping project project/jenkins/jobs in category Migrated to GitLab
INFO: skipping project project/jenkins/tools in category Migrated to GitLab
INFO: searching for projects matching fastlane
INFO: Successfully connected to https://gitlab.torproject.org
import gitolite project project/tor-browser/fastlane into gitlab legacy/gitolite/project/tor-browser/fastlane with desc 'Tor Browser app store and deployment configuration for Fastlane'? [Y/n]
INFO: importing gitolite project project/tor-browser/fastlane into gitlab legacy/gitolite/project/tor-browser/fastlane with desc 'Tor Browser app store and deployment configuration for Fastlane'
INFO: building a new connect to cupani
INFO: defaulting name to fastlane
INFO: importing project into GitLab
INFO: Successfully connected to https://gitlab.torproject.org
INFO: loading group legacy/gitolite/project/tor-browser
INFO: archiving project
INFO: creating repository fastlane (fastlane) in namespace legacy/gitolite/project/tor-browser from https://git.torproject.org/project/tor-browser/fastlane into https://gitlab.torproject.org/legacy/gitolite/project/tor-browser/fastlane
INFO: migrating Gitolite repository project/tor-browser/fastlane to GitLab project legacy/gitolite/project/tor-browser/fastlane
INFO: uploading 399 bytes to /srv/git.torproject.org/repositories/project/tor-browser/fastlane.git/hooks/pre-receive
INFO: making /srv/git.torproject.org/repositories/project/tor-browser/fastlane.git/hooks/pre-receive executable
INFO: adding entry to rewrite_map /home/anarcat/src/tor/tor-puppet/modules/profile/files/git/gitolite2gitlab.txt
INFO: modifying gitolite.conf to add: "config gitweb.category = Migrated to GitLab"
INFO: rewriting gitolite config /home/anarcat/src/tor/gitolite-admin/conf/gitolite.conf to change project project/tor-browser/fastlane to category Migrated to GitLab
INFO: skipping project project/bridges/bridgedb-admin in category Migrated to GitLab
[...]
In the above, you can see migrated repositories skipped then the
fastlane project being archived into GitLab. Another example with
a later version of the script, processing only user repositories and
showing the interactive prompt and a force-push into a fork:
$ fab -H cupani.torproject.org gitolite.mass-repos-migration --include 'user/.*' --exclude '.*tor-?browser.*'
INFO: skipping project user/aagbsn/bridgedb in category Migrated to GitLab
[...]
INFO: skipping project user/phw/atlas in category Migrated to GitLab
INFO: processing project user/phw/obfsproxy (Philipp's obfsproxy repository) in category Users' development repositories (Attic)
INFO: Successfully connected to https://gitlab.torproject.org
INFO: user repository detected, trying to find fork phw/obfsproxy
WARNING: no existing fork found, entering user fork subroutine
INFO: found 6 GitLab projects matching 'obfsproxy' (https://gitweb.torproject.org/user/phw/obfsproxy.git)
0 legacy/gitolite/debian/obfsproxy
1 legacy/gitolite/debian/obfsproxy-legacy
2 legacy/gitolite/user/asn/obfsproxy
3 legacy/gitolite/user/ioerror/obfsproxy
4 tpo/anti-censorship/pluggable-transports/obfsproxy
5 tpo/anti-censorship/pluggable-transports/obfsproxy-legacy
select parent to fork from, or enter to abort: ^G4
INFO: repository is not empty: in-pack: 2104, packs: 1, size-pack: 414
fork project tpo/anti-censorship/pluggable-transports/obfsproxy into legacy/gitolite/user/phw/obfsproxy^G [Y/n]
INFO: loading project tpo/anti-censorship/pluggable-transports/obfsproxy
INFO: forking project user/phw/obfsproxy into namespace legacy/gitolite/user/phw
INFO: waiting for fork to complete...
INFO: fork status: started, sleeping...
INFO: fork finished
INFO: cloning and force pushing from user/phw/obfsproxy to legacy/gitolite/user/phw/obfsproxy
INFO: deleting branch protection: => {'id': 2723, 'name': 'master', 'push_access_levels': [{'id': 2864, 'access_level': 40, 'access_level_description': 'Maintainers', 'deploy_key_id': None}], 'merge_access_levels': [{'id': 2753, 'access_level': 40, 'access_level_description': 'Maintainers'}], 'allow_force_push': False}
INFO: cloning repository git-rw.torproject.org:/srv/git.torproject.org/repositories/user/phw/obfsproxy.git in /tmp/tmp6orvjggy/user/phw/obfsproxy
Cloning into bare repository '/tmp/tmp6orvjggy/user/phw/obfsproxy'...
INFO: pushing to GitLab: https://gitlab.torproject.org/legacy/gitolite/user/phw/obfsproxy
remote:
remote: To create a merge request for bug_10887, visit:
remote: https://gitlab.torproject.org/legacy/gitolite/user/phw/obfsproxy/-/merge_requests/new?merge_request%5Bsource_branch%5D=bug_10887
remote:
[...]
To ssh://gitlab.torproject.org/legacy/gitolite/user/phw/obfsproxy
+ 2bf9d09...a8e54d5 master -> master (forced update)
* [new branch] bug_10887 -> bug_10887
[...]
INFO: migrating repo
INFO: migrating Gitolite repository https://gitweb.torproject.org/user/phw/obfsproxy.git to GitLab project https://gitlab.torproject.org/legacy/gitolite/user/phw/obfsproxy
INFO: adding entry to rewrite_map /home/anarcat/src/tor/tor-puppet/modules/profile/files/git/gitolite2gitlab.txt
INFO: modifying gitolite.conf to add: "config gitweb.category = Migrated to GitLab"
INFO: rewriting gitolite config /home/anarcat/src/tor/gitolite-admin/conf/gitolite.conf to change project user/phw/obfsproxy to category Migrated to GitLab
INFO: processing project user/phw/scramblesuit (Philipp's ScrambleSuit repository) in category Users' development repositories (Attic)
INFO: user repository detected, trying to find fork phw/scramblesuit
WARNING: no existing fork found, entering user fork subroutine
WARNING: no matching gitlab project found for user/phw/scramblesuit
INFO: user fork subroutine failed, resuming normal procedure
INFO: searching for projects matching scramblesuit
import gitolite project user/phw/scramblesuit into gitlab legacy/gitolite/user/phw/scramblesuit with desc 'Philipp's ScrambleSuit repository'?^G [Y/n]
INFO: checking if remote repo https://git.torproject.org/user/phw/scramblesuit exists
INFO: importing gitolite project user/phw/scramblesuit into gitlab legacy/gitolite/user/phw/scramblesuit with desc 'Philipp's ScrambleSuit repository'
INFO: importing project into GitLab
INFO: Successfully connected to https://gitlab.torproject.org
INFO: loading group legacy/gitolite/user/phw
INFO: creating repository scramblesuit (scramblesuit) in namespace legacy/gitolite/user/phw from https://git.torproject.org/user/phw/scramblesuit into https://gitlab.torproject.org/legacy/gitolite/user/phw/scramblesuit
INFO: archiving project
INFO: migrating Gitolite repository https://gitweb.torproject.org/user/phw/scramblesuit.git to GitLab project https://gitlab.torproject.org/legacy/gitolite/user/phw/scramblesuit
INFO: adding entry to rewrite_map /home/anarcat/src/tor/tor-puppet/modules/profile/files/git/gitolite2gitlab.txt
INFO: modifying gitolite.conf to add: "config gitweb.category = Migrated to GitLab"
INFO: rewriting gitolite config /home/anarcat/src/tor/gitolite-admin/conf/gitolite.conf to change project user/phw/scramblesuit to category Migrated to GitLab
[...]
Acute eyes will notice the bell used as a notification mechanism
as well in this transcript.
A lot of the code is now useless for us, but some, like "commit and
push" or is-repo-empty live on in the git module and, of
course, the gitlab module has grown some legs along the
way. We've also found fun bugs, like a file descriptor exhaustion in
bash, among other oddities. The retirement milestone and
issue 41215 has a detailed log of the migration, for those
curious.
This was a challenging project, but it feels nice to have this behind
us. This gets rid of 2 of the 4 remaining machines running Debian
"old-old-stable", which moves a bit further ahead in our late
bullseye upgrades milestone.
Full transparency: we tested GPT-3.5, GPT-4, and other large language
models to see if they could answer the question "write a set of
rewrite rules to redirect GitWeb to GitLab". This has become a
standard LLM test for your faithful writer to figure out how good a
LLM is at technical responses. None of them gave an accurate,
complete, and functional response, for the record.
The actual rewrite rules as of this writing follow, for humans that
actually like working answers provided by expert humans instead of
artificial intelligence which currently seem to be, glorified,
mansplaining interns.
git.torproject.org rewrite rules
Those rules are relatively simple in that they rewrite a single URL to
its equivalent GitLab counterpart in a 1:1 fashion. It relies on the
rewrite map mentioned above, of course.
RewriteEngine on
# this RewriteMap connects the gitweb projects to their GitLab
# equivalent
RewriteMap gitolite2gitlab "txt:/etc/apache2/gitolite2gitlab.txt"
# if this becomes a performance bottleneck, convert to a DBM map with:
#
# $ httxt2dbm -i mapfile.txt -o mapfile.map
#
# and:
#
# RewriteMap mapname "dbm:/etc/apache/mapfile.map"
#
# according to reports lavamind found online, we hit such a
# performance bottleneck only around millions of entries, which is not our case
# those two rules can go away once all the projects are
# migrated to GitLab
#
# this matches the request URI so we can check the RewriteMap
# for a match next
#
# WARNING: this won't match URLs without .git in them, which
# *do* work now. one possibility would be to match the request
# URI (without query string!) with:
#
# /git/(.*)(.git)?/(((branches|hooks|info|objects/).*)|git-.*|upload-pack|receive-pack|HEAD|config|description)?.
#
# I haven't been able to figure out the actual structure of
# those URLs, so it's really hard to figure out the boundaries
# of the project name here. I stopped after pouring around the
# http-backend.c code in git
# itself. https://www.git-scm.com/docs/http-protocol is also
# kind of incomplete and unsatisfying.
RewriteCond %{REQUEST_URI} ^/(git/)?(.*).git/.*$
# this makes the RewriteRule match only if there's a match in
# the rewrite map
RewriteCond ${gitolite2gitlab:%2|NOT_FOUND} !NOT_FOUND
RewriteRule ^/(git/)?(.*).git/(.*)$ https://gitlab.torproject.org/${gitolite2gitlab:$2}.git/$3 [R=302,L]
# Fallback everything else to GitLab
RewriteRule (.*) https://gitlab.torproject.org [R=302,L]
gitweb.torproject.org rewrite rules
Those are the vastly more complicated GitWeb to GitLab rewrite
rules.
Note that we say "GitWeb" but we were actually not running
GitWeb but cgit, as the former didn't actually scale for us.
RewriteEngine on
# this RewriteMap connects the gitweb projects to their GitLab
# equivalent
RewriteMap gitolite2gitlab "txt:/etc/apache2/gitolite2gitlab.txt"
# special rule to process targets of the old spec.tpo site and
# bring them to the right redirect on the new spec.tpo site. that should turn, for example:
#
# https://gitweb.torproject.org/torspec.git/tree/address-spec.txt
#
# into:
#
# https://spec.torproject.org/address-spec
RewriteRule ^/torspec.git/tree/(.*).txt$ https://spec.torproject.org/$1 [R=302]
# list of endpoints taken from cgit's cmd.c
# those two RewriteCond are necessary because we don't move
# all repositories at once. once the migration is completed,
# they can be removed.
#
# and yes, they are copied all over the place below
#
# create a match for the project name to check if the project
# has been moved to GitLab
RewriteCond %{REQUEST_URI} ^/(.*).git(/.*)?$
# this makes the RewriteRule match only if there's a match in
# the rewrite map
RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
# main project page, like summary below
RewriteRule ^/(.*).git/?$ https://gitlab.torproject.org/${gitolite2gitlab:$1}/ [R=302,L]
# summary
RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
RewriteRule ^/(.*).git/summary/?$ https://gitlab.torproject.org/${gitolite2gitlab:$1}/ [R=302,L]
# about
RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
RewriteRule ^/(.*).git/about/?$ https://gitlab.torproject.org/${gitolite2gitlab:$1}/ [R=302,L]
# commit
RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))id=([^&]*)(&.*)?$"
RewriteRule ^/(.*).git/commit/? https://gitlab.torproject.org/${gitolite2gitlab:$1}/-/commit/%2 [R=302,L,QSD]
RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
RewriteRule ^/(.*).git/commit/? https://gitlab.torproject.org/${gitolite2gitlab:$1}/-/commits/HEAD [R=302,L]
# diff, incomplete because can diff arbitrary refs and files in cgit but not in GitLab, hard to parse
RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
RewriteCond %{QUERY_STRING} id=([^&]*)
RewriteRule ^/(.*).git/diff/? https://gitlab.torproject.org/${gitolite2gitlab:$1}/-/commit/%1 [R=302,L,QSD]
# patch
RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
RewriteCond %{QUERY_STRING} id=([^&]*)
RewriteRule ^/(.*).git/patch/? https://gitlab.torproject.org/${gitolite2gitlab:$1}/-/commit/%1.patch [R=302,L,QSD]
# rawdiff, incomplete because can show only one file diff, which GitLab cannot
RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
RewriteCond %{QUERY_STRING} id=([^&]*)
RewriteRule ^/(.*).git/rawdiff/?$ https://gitlab.torproject.org/${gitolite2gitlab:$1}/-/commit/%1.diff [R=302,L,QSD]
# log
RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
RewriteCond %{QUERY_STRING} h=([^&]*)
RewriteRule ^/(.*).git/log/?$ https://gitlab.torproject.org/${gitolite2gitlab:$1}/-/commits/%1 [R=302,L,QSD]
RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
RewriteRule ^/(.*).git/log/?$ https://gitlab.torproject.org/${gitolite2gitlab:$1}/-/commits/HEAD [R=302,L]
RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
RewriteRule ^/(.*).git/log(/?.*)$ https://gitlab.torproject.org/${gitolite2gitlab:$1}/-/commits/HEAD$2 [R=302,L]
# atom
RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
RewriteCond %{QUERY_STRING} h=([^&]*)
RewriteRule ^/(.*).git/atom/?$ https://gitlab.torproject.org/${gitolite2gitlab:$1}/-/commits/%1 [R=302,L,QSD]
RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
RewriteRule ^/(.*).git/atom/?$ https://gitlab.torproject.org/${gitolite2gitlab:$1}/-/commits/HEAD [R=302,L,QSD]
# refs, incomplete because two pages in GitLab, defaulting to "tags"
RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
RewriteRule ^/(.*).git/refs/?$ https://gitlab.torproject.org/${gitolite2gitlab:$1}/-/tags [R=302,L]
RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
RewriteCond %{QUERY_STRING} h=([^&]*)
RewriteRule ^/(.*).git/tag/? https://gitlab.torproject.org/${gitolite2gitlab:$1}/-/tags/%1 [R=302,L,QSD]
# tree
RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
RewriteCond %{QUERY_STRING} id=([^&]*)
RewriteRule ^/(.*).git/tree(/?.*)$ https://gitlab.torproject.org/${gitolite2gitlab:$1}/-/tree/%1$2 [R=302,L,QSD]
RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
RewriteRule ^/(.*).git/tree(/?.*)$ https://gitlab.torproject.org/${gitolite2gitlab:$1}/-/tree/HEAD$2 [R=302,L]
# /-/tree has no good default in GitLab, revert to HEAD which is a good
# approximation (we can't assume "master" here anymore)
RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
RewriteRule ^/(.*).git/tree/?$ https://gitlab.torproject.org/${gitolite2gitlab:$1}/-/tree/HEAD [R=302,L]
# plain
RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
RewriteCond %{QUERY_STRING} h=([^&]*)
RewriteRule ^/(.*).git/plain(/?.*)$ https://gitlab.torproject.org/${gitolite2gitlab:$1}/-/raw/%1$2 [R=302,L,QSD]
RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
RewriteRule ^/(.*).git/plain(/?.*)$ https://gitlab.torproject.org/${gitolite2gitlab:$1}/-/raw/HEAD$2 [R=302,L]
# blame: disabled
#RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
#RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
#RewriteCond %{QUERY_STRING} h=([^&]*)
#RewriteRule ^/(.*).git/blame(/?.*)$ https://gitlab.torproject.org/${gitolite2gitlab:$1}/-/blame/%1$2 [R=302,L,QSD]
# same default as tree above
#RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
#RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
#RewriteRule ^/(.*).git/blame(/?.*)$ https://gitlab.torproject.org/${gitolite2gitlab:$1}/-/blame/HEAD/$2 [R=302,L]
# stats
RewriteCond %{REQUEST_URI} ^/(.*).git/.*$
RewriteCond ${gitolite2gitlab:%1|NOT_FOUND} !NOT_FOUND
RewriteRule ^/(.*).git/stats/?$ https://gitlab.torproject.org/${gitolite2gitlab:$1}/-/graphs/HEAD [R=302,L]
# still TODO:
# repolist: once migration is complete
#
# cannot be done:
# atom: needs a feed token, user must be logged in
# blob: no direct equivalent
# info: not working on main cgit website?
# ls_cache: not working, irrelevant?
# objects: undocumented?
# snapshot: pattern too hard to match on cgit's side
# special case, we keep a copy of the main index on the archive
RewriteRule ^/?$ https://archive.torproject.org/websites/gitweb.torproject.org.html [R=302,L]
# Fallback: everything else to GitLab
RewriteRule .* https://gitlab.torproject.org [R=302,L]
The reference copy of those is available in our (currently private)
Puppet git repository.
Tue, 30 Apr 2024, 12:00 am
New Alpha Release: Tor Browser 13.5a7
Tor Browser 13.5a7 is now available from the Tor Browser download page and also from our distribution directory.
This version includes important security updates to Firefox.
We would like to thank the folowing community members for their contributions this release:
If you would like to contribute, our contributor guide can be found here.
Letterboxing Improvements and Bug Fixes
This release contains more tweaks and bug fixes related to the updated letterboxing UI and associated back-end systems. As described previously, in about:preferences#general one may now configure some aspects of the letterbox behaviour, including whether the content area floats in the center of the window or is snapped to the browser chrome at the top. We also implemented a somewhat hidden feature which will allow you to remove the extra spacing when you resize the window by double-clicking within the letterbox gutter area. This will snap the whole window down to the size required by the content.
Please continue to exercising this feature and filing bugs if you find any issues!
Localisation Updates
We have continued migrating our localisation pipelines from the legacy 'dtd' to the new 'fluent' format. Please report any localisation issues or missing translations you may find!
Japanese Locale on macOS Weirdness
The technical specifics around our Japanese localisation on macOS are a bit peculiar (if you've ever peaked at our release+packaging scripts for macOS, you know what I mean). Therefore, this platform+locale combo has historically had interesting problems which go undiscovered for awhile since nobody on the team can read Japanese and few of us use macOS as their daily driver. If there are any Japanese-reading macOS users out there, we would definitely appreciate any localisation-related bug reports you can provide!
Native Android Connect-Assist
We have continued improving our connect-assist implementation on Android. We have fixed the problems which prevented bridge-settings from sticking (tor-browser#42486) and continued work bringing this native Android UI up to feature-parity with desktop. We have also been updating the Tor-related settings and have added the ability to the view the Tor logs after bootstrapping.
Please give the new systems a go by navigating to Settings > Connection > Enable beta connection features and toggling Enable beta connection features and selecting Native Android UI. We expect to reach feature parity with Desktop over this next release cycle, at which point both the legacy frontend (and its eccentric backend) as well as the stop-gap HTML-based frontend will be removed.
Connect-Assist Backend Work
As mentioned in the previous section, we have been iteratively improving the connect-assist backend code which is used on both Desktop and Android. If you are Desktop user we would appreciate you verifying that your bootstrapping experience is unchanged between releases, particularly if you have any custom configuration or settings.
WebTunnel + Lyrebird Pluggable-Transport Fusion
Tor Browser ships with a number of pluggable-transports (PTs) which allow users to connect to the Tor network by disguising their traffic. Up until this released, we have shipped the lyrebird, snowflake, conjure-client, and webtunnel-client PTs, each of which implement support for at least one bridge type (such as obfs4).
For historical reasons, each of these PTs are developed in Go. The problem with that is that (to summarise) Go applications ship with all of their dependencies baked into their binaries, rather than depending on 3rd party libraries. As a result, Go binaries typically are a bit bigger than you would expect given the functionality they may provide.
This is a reasonable thing to do in some contexts. Unfortunately, Tor Browser for Android has a hard application size budget it has to stay within in order to be accepted to the Google Play Store, about 100 megabytes.
To help keep Tor Browser for Android within this budget, Tor's Anticensorship team built a version of the Lyrebird PT which also includes the WebTunnel PT's functionality. As a result, from 13.5a7 onward, WebTunnel bridges will be handled by Lyrebird, and the WebTunnel PT is no longer necessary!
Nothing should have changed from an end-user perspective (apart from a smaller binary size) and WebTunnel bridges should continue to work as they always have. If this is not the case, please file an issue!
Send us your feedback
If you find a bug or have a suggestion for how we could improve this release, please let us know.
Full changelog
The full changelog since Tor Browser 13.5a6 is:
- All Platforms
- Windows + macOS + Linux
- Windows
- Linux
- Android
- Build System
- All Platforms
- Windows + macOS + Linux
- macOS
- Linux
- Android
Tue, 30 Apr 2024, 12:00 am
Code audit for censorship circumvention tools completed by Cure53
Since 2021, the Tor Project has been working on a project entitled "Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibet", which aimed at improving the use of Tor in the China region. We had the following goals for this project:
Implement new pluggable transports and add more bridges that are harder for censors to block.
Improve the bridge distribution systems so that it's harder for censors to learn and block bridges, while making it easier for users to get them.
Update a diverse set of proven open source circumvention applications so they are compatible with new bridges and censorship resistance/detection techniques.
Surge adoption through the deployment of region-specific localization, outreach, and distribution efforts for target users.
This project allowed us to release:
Webtunnel, a new pluggable transport designed to mimic encrypted traffic.
Lox, a privacy preserving reputation-based bridge distribution system that is being integrated into Tor Browser.
RDSys, a new distribution system for bridges that is replacing BridgeDB.
A new feature in Tor Browser, called Connection Assist, that makes censorship circumvention easier for users.
OnionShare, a secure and anonymous productivity and privacy suite built on Tor allowing users to share files, host websites, and chat with friends, available for desktop and mobile devices.
Improvements on OnionShare for Desktop
In January 2024 we contracted Cure53 to audit all the code that was changed or created during this project. The security audit helps uncover vulnerabilities produced through these changes in the software. We are happy to report that all the vulnerabilities that were uncovered have already been mitigated.
For more details and information please access the complete audit report.
We would like to thank Cure53 for an excellent and professional audit, as well as the U.S. State Department Bureau of Democracy, Human Rights, and Labor (DRL) for sponsoring this project.
Wed, 10 Apr 2024, 12:00 am
Surveillance as a Service: The Global Impact of Israeli “Defense” Technologies on Privacy and Human Rights
Highlighting, exposing, and actively working against the proliferation and normalization of surveillance technology is crucial in protecting human rights worldwide. At the Tor Project, we know that it is through collective awareness and action that we can all build and contribute to privacy-preserving technologies that aim to protect people everywhere from the prevalence of surveillance and oppression. It is equally important to hold companies accountable and recognize the source and enablers of surveillance tech, especially now as we see these technologies being aggressively utilized in the ongoing genocide in Gaza.
This post delves into the impact of Israeli surveillance technologies in Palestine, illustrating how localized instances of its use can have extensive repercussions that pave the way for the widespread acceptance and global adoption of such oppressive practices.
There is a growing need for a global stance against the use of technology for oppression. Tech workers and the broader international community are urged to prioritize integrity over profit to protect privacy and prevent the deleterious impacts of pervasive surveillance on our lives. There is even more urgency to address these issues in the face of growing demand for surveillance solutions enhanced and exacerbated by AI.
Global Surveillance and Oppression
The examples below demonstrate the alarming sophistication of surveillance capitalism and its increasingly global footprint. They also explore how Israeli spyware and surveillance companies navigate global scrutiny by rebranding and establishing offices worldwide, all while a network of venture capital firms facilitate their operations and help them avoid much needed accountability.
Elbit Systems is a leading military tech exporter in Israel, specializing in various advanced surveillance technologies, terrifyingly deployed in space, air, sea and ground operations. Its surveillance systems, drones, and other high-tech tools, which are used to enforce violent occupations and apartheid, are in high demand worldwide.
This pervasive surveillance technology doesn't end in Palestine, but it often starts with it.
Since at least 2014, Elbit Systems has been deploying these tools at the U.S Southern Border as well as in the UAE and UK. Some of these deals occur via a subsidiary of Elbit Systems of America called Kollsman Inc, which is involved in a controversial death of an employee during a work trip to Saudi Arabia.
These relationships are further strengthened through VC investments. The UAE invested at least $100 million in Israeli VC firms, which is not surprising, considering it is a longtime customer of its spyware tools. An Israeli owned company, for example, is behind Abu Dhabi's mass surveillance system, in a contract worth $600m. Dubai also operates a back-channel for Arab countries who wish to deploy Israeli surveillance technologies through a local entity called Black Wall Global, which is led by Israeli intelligence veterans.
In similarly structured deals, Israeli companies like IntuView have contracts with Saudi Arabia for efforts that include scanning Saudi citizens' data. Its advisory board consists of a former head of Mossad and a former director of the CIA.
The technology is becoming increasingly advanced and appealing to authoritarian governments. Israel, with the assistance of U.S companies, is deploying robots equipped with numerous sensors and cameras to surveil buildings and open spaces.
AI-based systems like "The Gospel" largely consist of drone footage, intercepted communications, surveillance data and information drawn from monitoring the movements and behavior patterns of individuals and large groups to create bombing targets.
In a similar setup, through "Lavender", Israel is using AI to detect assassination targets with little human oversight through information collected via mass surveillance of Gaza residents. The report highlights how many of these attacks result in the mass killing of civilians and entire families, often in their own homes.
Spyware has always been a highly lucrative and increasingly prominent business in Israel. Citizen Lab has spent years uncovering sophisticated spyware from Israeli companies like NSO, which contracts with governments with a long history of imprisoning, murdering and silencing dissidents and surveilling civil society organizations, including Saudi Arabia, Bahrain and the UAE. These governments normalize relations with Israel largely to facilitate access to such technologies, which they then deploy to oppress their own citizens.
Israel-based Voyager Labs actively marketed and sold surveillance tools which have been used to profile and intimidate journalists and activists, including by Colombian military intelligence. They recently moved their headquarters to the U.S. to continue building such tools with a team of "world-class AI researchers."
U.S.-Israeli company Verint, whose products include surveillance cameras and analysis software to monitor and analyze large voice and video data sets, had sold their technology to repressive regimes in Azerbaijan, Indonesia, South Sudan, Uzbekistan and Kazakhstan. Among the uses of their tools is the violent crackdown on LGBTQ+ communities and human rights activists.
These companies don't operate alone. When facing scrutiny or exposure, they spin off new entities, often with the backing of venture capital firms that are equally complicit. Verint, for example, spun off a separate company called Cognyte to continue its lucrative deals, which an Israeli human rights lawyer says was "aiding and abetting crimes against humanity." A New York-based hedge fund, Edenbrook Capital, is among its largest shareholders.
Another and more recent example is Dream Security from the former CEO of Pegasus Software. Their latest round was raised in a deal that was co-led with Los Angeles-based VC firm Group 11. This demonstrates a troubling cycle of evasion.
Corsight, an Israeli company, has been using facial recognition and Google Photos to conduct mass surveillance of Palestinians without their knowledge or consent. To date, Google has declined to answer, despite prohibiting their tech in being used for "immediate harm." Apart from being an egregious privacy violation, the technology also misidentifies people, putting their lives at risk. Canadian-Israeli VC firm, AWZ ventures, is among its lead investors. Their tools are also deployed by the U.S. Department of Homeland Security for facial recognition purposes.
AnyVision, an Israeli company with an international presence, is behind "advanced tactical surveillance" software used to monitor the movements of Palestinians. Its CEO is a former operating partner at SoftBank's investment arm, which co-led a large fundraising round for the company alongside Eldridge, an American holding company headquartered in Connecticut. A few months after the extent of their surveillance systems were exposed in U.S schools, they rebranded to Oosto and resumed operations.
One of the most prominent examples of these collaborations remains Palantir, which also continues to win major contracts with the UK government and various U.S agencies, most recently the U.S army on an AI-powered targeting system, and who will once again supply its surveillance products to Israel in a new "strategic partnership."
The global market for "Border Security Technologies" is projected to exceed $70 billion by 2027, up from $48 billion in 2022. The significant growth in this market is partly attributed to the increasing adoption of AI-integrated surveillance towers, made possible by Israeli companies who test repressive technologies on Palestinians. This practice allows Israel to refine and demonstrate the effectiveness of its products in real scenarios, making them more appealing to international buyers, who, again, are often equally oppressive regimes with horrific human rights records.
As shown above, these technologies, initially used to enforce violent occupation, apartheid, and genocide have found a lucrative global market, stretching far beyond the confines of Palestine. Antony Loewenstein, author of The Palestine Laboratory, notes to Tor: "Since 7 October, 2023, Israel has been live-testing new weapons in Gaza including drones, quadcopters, facial recognition tools and surveillance tech. The aim isn't just to kill Palestinians indiscriminately in Gaza but sell these weapons of war to a global market. AI-enabled warfare is a key selling point for the Israeli state and its private backers. What starts in Palestine never stays there."
Building a Culture of Accountability
The export of military systems by Israel reveals a harrowing journey of surveillance technologies from local deployments in Palestine to worldwide distribution, with a disturbing and alarming trend of normalization and acceptance of the grave human rights violations that are committed in the process of their creation and testing. The complicity of venture capital in the proliferation of such technologies highlights the intricate web of interests that prioritize power and profit over basic human rights.
This is your reminder that standing against surveillance that continues to engulf us all is a global responsibility. There needs to be a consistent and immediate call to action for tech workers, companies, civil society organizations, and the global community at large to stand firm in our commitment to human rights and privacy. We must hold companies accountable, dissect and expose the origins of surveillance technologies, and resist their normalization.
We applaud the companies and civil society organizations who have joined the No Tech For Apartheid campaign, including the many who risked their employment to do so, and urge others to join in this crucial effort. As many tech workers also have investment portfolios, we highly recommend that you align your investments with your values. This is one free screening tool you can use to ensure you're not profiting off of weapons manufacturers, illegal occupations, apartheid, genocide and border militarization, all of which use intense surveillance that enable the perpetration of war crimes.
Mon, 8 Apr 2024, 12:00 am