The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-09-10T15:54:24Zhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40078Bump Gradle version for Fenix to 6.5.12020-09-10T15:54:24ZGeorg KoppenBump Gradle version for Fenix to 6.5.1While we did not look did Mozilla bump Fenix's Gradle version to 6.5.1.
We should do the same.
Thanks, cypherpunk!While we did not look did Mozilla bump Fenix's Gradle version to 6.5.1.
We should do the same.
Thanks, cypherpunk!Tor Browser: 10.0Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/network-health/metrics/geoip-data/-/issues/6Bump libloc to 0.9.162023-02-02T17:15:03ZGeorg KoppenBump libloc to 0.9.16We should pick up the latest `libloc` version, 0.9.16.We should pick up the latest `libloc` version, 0.9.16.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/network-health/metrics/geoip-data/-/issues/8Bump libloc to 0.9.172023-09-07T14:10:08ZGeorg KoppenBump libloc to 0.9.17We have a new `libloc` version we likely should pick up, 0.9.17.We have a new `libloc` version we likely should pick up, 0.9.17.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40433Bump LLVM to 13.0.0 for android builds2022-07-15T15:36:48ZaguestuserBump LLVM to 13.0.0 for android builds# context
- we want to use LLVM version 13.0.0 for android builds (as it is the latest version and is what mozilla uses upstream for geckoview)
- however: we are unable to build geckoview v96.0.x if we do so, b/c `clang_rt` errors, as pe...# context
- we want to use LLVM version 13.0.0 for android builds (as it is the latest version and is what mozilla uses upstream for geckoview)
- however: we are unable to build geckoview v96.0.x if we do so, b/c `clang_rt` errors, as per: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_requests/405#note_2776669
- for the purposes of !406 , we reverted to 12.0.0 for nightly, but want to resolve 13.0.0
before tagging next alpha release (11.5a5)
# changes
- use llvm v13.0.0 (with `git_hash: d7b669b3a30345cfcdb2fde2af6f48aa4b94845d`) in `projects/llvm-project/config.targets.android`Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/34013Bump node version to v10.21.02020-07-18T00:04:08ZGeorg KoppenBump node version to v10.21.0Update our node version to what is used in mozilla-central.Update our node version to what is used in mozilla-central.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40133Bump Rust to 1.43.0 for ESR 782020-11-08T15:37:32ZGeorg KoppenBump Rust to 1.43.0 for ESR 78While looking at the [minimum required Rust
version](https://searchfox.org/mozilla-esr78/source/python/mozboot/mozboot/base.py#161)
to build ESR 78 (1.41.1) I somehow missed that Mozilla is
[actually](https://bugzilla.mozilla.org/show_bu...While looking at the [minimum required Rust
version](https://searchfox.org/mozilla-esr78/source/python/mozboot/mozboot/base.py#161)
to build ESR 78 (1.41.1) I somehow missed that Mozilla is
[actually](https://bugzilla.mozilla.org/show_bug.cgi?id=1632723)
building ESR 78 with
[1.43.0](https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox). We
should do the same to minimize toolchain differences between official
Firefox and Tor Browser builds.
Thanks to a cypherpunk for the reminder.Tor Browser: 10.5Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40275Bump verison of snowflake to v2.6.02023-06-20T18:48:10ZCecylia BocovichBump verison of snowflake to v2.6.0Let's do a library version bump and update the version shipped in Tor BrowserLet's do a library version bump and update the version shipped in Tor BrowserCecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40474Bump version of snowflake and webrtc2022-06-21T18:37:50ZCecylia BocovichBump version of snowflake and webrtcLet's bump snowflake to the latest version and pion/webrtc to `v3.1.41`.Let's bump snowflake to the latest version and pion/webrtc to `v3.1.41`.richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40440Bump version of snowflake to include PT LOG events2022-03-10T18:27:53ZCecylia BocovichBump version of snowflake to include PT LOG eventsWe recently added a feature to snowflake that makes use of the [LOG](https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt#n634) message in the PT spec. Key snowflake connection events are now passed to the tor process to be logged....We recently added a feature to snowflake that makes use of the [LOG](https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt#n634) message in the PT spec. Key snowflake connection events are now passed to the tor process to be logged.
Getting this feature into the version of Snowflake shipped in Tor Browser will ensure that snowflake connection events are included in the tor log that users can copy-paste through the Tor Browser interface. This will help us diagnose difficulties with the connection and possibly detect new censorship events.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40068Bump versions for Fenix 81.1.0b1 dependencies2020-09-04T15:33:46ZGeorg KoppenBump versions for Fenix 81.1.0b1 dependenciesWe need to bump the dependencies for Fenix 81.1.0b1 and make sure the
result still compiles and runs.
The GeckoView part is already done and handled in #40062.
- [x] fenix#40029We need to bump the dependencies for Fenix 81.1.0b1 and make sure the
result still compiles and runs.
The GeckoView part is already done and handled in #40062.
- [x] fenix#40029Tor Browser: 10.0Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40588Bundle translations for New Identity and Security Level2022-08-04T12:43:28ZPier Angelo VendrameBundle translations for New Identity and Security LevelNew Identity and Security Level have been moved to base-browser, and with them also their localization files.
Therefore, we should inject them in Firefox during build phase.New Identity and Security Level have been moved to base-browser, and with them also their localization files.
Therefore, we should inject them in Firefox during build phase.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/network-health/team/-/issues/112C9349C4D1B827E2785D47F319F082100EDB61F8A censors blender.io via OpenDNS2021-09-04T15:04:55ZGeorg KoppenC9349C4D1B827E2785D47F319F082100EDB61F8A censors blender.io via OpenDNSbermuda showed us
```
+*** c9349c4d1b827e2785d47f319f082100edb61f8a returned 146.112.61.108 WOAH
```
for `blender.io today.
I'll add the `BadExit` flag for the relay and reach out to the operators.bermuda showed us
```
+*** c9349c4d1b827e2785d47f319f082100edb61f8a returned 146.112.61.108 WOAH
```
for `blender.io today.
I'll add the `BadExit` flag for the relay and reach out to the operators.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41462CAA record prevents renewing certs for snowflake.torproject.net, 02.snowflake...2024-01-11T18:33:24ZDavid Fifielddcf@torproject.orgCAA record prevents renewing certs for snowflake.torproject.net, 02.snowflake.torproject.net, and snowflake-broker.torproject.net[Since 2017](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/18654#note_2591192),
we've used Let's Encrypt (via the [acme/autocert](https://pkg.go.dev/golang.org/x/crypto@v0.17.0/acme/autocert) p...[Since 2017](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/18654#note_2591192),
we've used Let's Encrypt (via the [acme/autocert](https://pkg.go.dev/golang.org/x/crypto@v0.17.0/acme/autocert) package)
to issue TLS certificates for the Snowflake bridges and broker.
The [new CAA record](tpo/tpa/team#41386) for torproject.net
has made that [stop working](tpo/anti-censorship/pluggable-transports/snowflake#40319).
These are the expiration dates
of the certificates we're not able to renew
using the Let's Encrypt accounts we have used up to this point:
|Domain|NotAfter|
|--:|---|
|02.snowflake.torproject.net|2024-01-13 14:03:53|
|snowflake.torproject.net|2024-01-20 11:23:43|
|snowflake-broker.torproject.net|2024-02-22 04:15:23|
The earliest expiration is less than a week from now.
How should we proceed?
Related: tpo/tpa/team#41455, tpo/tpa/team#41460Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.org2024-01-12https://gitlab.torproject.org/tpo/core/tor/-/issues/40713calculate n_threads as "num-cpus +1" instead "num-cpus -1"2022-11-28T14:34:32Ztoralfcalculate n_threads as "num-cpus +1" instead "num-cpus -1"This
```c
/*
In our threadpool implementation, half the threads are permissive and
half are strict (when it comes to running lower-priority tasks). So we
always make sure we have at least two threads, so that there...This
```c
/*
In our threadpool implementation, half the threads are permissive and
half are strict (when it comes to running lower-priority tasks). So we
always make sure we have at least two threads, so that there will be at
least one thread of each kind.
*/
const int n_threads = get_num_cpus(get_options()) + 1;
```
could be for multi-cpu systems
```c
const int n_threads = get_num_cpus(get_options()) - 1;
```
nowadays ?Tor: 0.4.8.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/1050Calculate the worst_case_end time for desc publication attempts2023-10-04T18:02:15Zgabi-250Calculate the worst_case_end time for desc publication attemptsCalculate the `worst_case_end` (the time the publication attempt will definitely be complete or abandoned) and pass call `IptSet::note_publication_attempt` in the publisher.Calculate the `worst_case_end` (the time the publication attempt will definitely be complete or abandoned) and pass call `IptSet::note_publication_attempt` in the publisher.gabi-250gabi-250https://gitlab.torproject.org/tpo/community/relays/-/issues/65Call for bridge operators to fight censorship in Turkmenistan2023-03-26T13:23:16ZGusCall for bridge operators to fight censorship in TurkmenistanAs Turkmenistan government is blocking whole IP ranges, Snowflake, and almost the entire internet (see: https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40029#note_2888122), we learned that bridges running o...As Turkmenistan government is blocking whole IP ranges, Snowflake, and almost the entire internet (see: https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40029#note_2888122), we learned that bridges running on residential connections are working (at least in US, UK, DE). We should call our relay operators community to help and run bridges in this crucial moment.GusGushttps://gitlab.torproject.org/tpo/core/tor/-/issues/40254Can't migrate ORPort options from 0.4.4.6 to 0.4.5.3-rc2021-01-27T14:36:55ZVortCan't migrate ORPort options from 0.4.4.6 to 0.4.5.3-rcHello.
I was using unusual configuration for my relay:
Relay was listening at public IPv4 address and private IPv6 address:
```
ORPort 443
ORPort [ipv6_address]:ipv6_port NoAdvertise
```
IPv6 address belongs to Yggdrasil network, but it...Hello.
I was using unusual configuration for my relay:
Relay was listening at public IPv4 address and private IPv6 address:
```
ORPort 443
ORPort [ipv6_address]:ipv6_port NoAdvertise
```
IPv6 address belongs to Yggdrasil network, but it actually does not matter.
What important is that my IPv6 interface have no access to Internet.
This configuration was working fine with Tor 0.4.4.6.
But with upgrade to 0.4.5.3-rc, Tor begins to open not only IPv4:443, but also IPv6:443, which is, of course, then marked as unreachable.
I thought that it is possible to disable IPv6 listening at 443 port by modifying config this way:
```
ORPort 443 IPv4Only
ORPort [ipv6_address]:ipv6_port NoAdvertise
```
But then my log file began to be flooded with such messages:
```
Jan 22 15:55:04.000 [notice] Self-testing indicates your ORPort ipv4_address:443 is reachable from the outside. Excellent. Publishing server descriptor.
Jan 22 15:55:05.000 [notice] Guessed our IP address as [ipv6_address] (source: METHOD=INTERFACE).
Jan 22 15:55:05.000 [notice] Self-testing indicates your ORPort ipv4_address:443 is reachable from the outside. Excellent. Publishing server descriptor.
Jan 22 15:55:06.000 [notice] Guessed our IP address as [ipv6_address] (source: METHOD=INTERFACE).
Jan 22 15:55:06.000 [notice] Self-testing indicates your ORPort ipv4_address:443 is reachable from the outside. Excellent. Publishing server descriptor.
Jan 22 15:55:07.000 [notice] Guessed our IP address as [ipv6_address] (source: METHOD=INTERFACE).
...
```
Adding `Address ipv4_address` to `torrc` did not helped too.
Please let me know how to properly configure new version of Tor.
Or fix a bug if it should work, but not working as intended.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40555can't set email password in db.torproject.org2021-12-15T17:07:14Zmeskiomeskio@torproject.orgcan't set email password in db.torproject.orgThe form to setup the email password in LDAP doesn't give any error, but no password gets set into LDAP's `mailPassword`.The form to setup the email password in LDAP doesn't give any error, but no password gets set into LDAP's `mailPassword`.anarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40172cannot write to tor-relays list2021-02-15T20:25:52ZVortcannot write to tor-relays listHello.
At this link:
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I read such information: "To post a message to all the list members, send email to tor-relays@lists.torproject.org."
I made exactly this to disc...Hello.
At this link:
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I read such information: "To post a message to all the list members, send email to tor-relays@lists.torproject.org."
I made exactly this to discover lately a message in spam folder, which tells that my mail was rejected.
Please change this phrase in that way, which will tell user that without subscribing it will not work.
Here is my yesterday message (if anyone is interested):
```
Hi.
Today I have noticed a large increase in connection count.
at 2021-02-11 00:18 there was 6.39k connections,
at 2021-02-11 00:30 - 8.16k.
Most of the connections comes from Lithuania.
There are lots of similar IP, each one have 5-20 connections.
Maybe it is normal Tor work.
Maybe attack.
But anyway I was needed to notify community about it.
-- Vort
```
**upd.** Here is what my email provider says:
![image](/uploads/30f2ac71539112217eda0d679985536b/image.png)
Translation:
> The sender is confirmed. However, the letter came from the domain lists.torproject.org, which does not match the return address.
> Sender: lists.torproject.org
> Signature: no
> Encryption: yes
> Spam: yesanarcatanarcathttps://gitlab.torproject.org/tpo/core/arti/-/issues/951Carefully consider: should we be deny()ing any built-in warnings?2023-08-04T14:20:54ZNick MathewsonCarefully consider: should we be deny()ing any built-in warnings?Inspired by #950
We currently use `deny` on the following built-in compiler warnings:
```
#![deny(missing_docs)]
#![deny(unreachable_pub)]
```
These are both warnings that we never want to ship with, but `deny()`ing them creates a ris...Inspired by #950
We currently use `deny` on the following built-in compiler warnings:
```
#![deny(missing_docs)]
#![deny(unreachable_pub)]
```
These are both warnings that we never want to ship with, but `deny()`ing them creates a risk. If any future version of rustc extends these warnings so that they trigger in more cases of code, then all current versions of arti would fail to compile with those versions of rustc.
Possible decisions:
1. We trust that rustc will never make `missing_docs` or `unreachable_pub` apply in more cases than it does today.
2. We declare that we don't care if future versions of rustc won't compile existing versions of arti.
3. We change these `deny`s to `warn`s, but add `-D warnings` or whatever the flag is to our CI build flags, and encourage people to do the same in their local development environments.
4. ... something else?
(Every other lint that we deny is from `clippy`; this issue doesn't apply to clippy warnings, since failing to pass future versions of clippy won't keep our code from compiling.)Nick MathewsonNick Mathewson