The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-12-08T17:41:30Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41434Letterboxing bypass through secondary tab (popup/popunder...)2022-12-08T17:41:30Zma1Letterboxing bypass through secondary tab (popup/popunder...)We should apply letterboxing to about:blank (we currently do not) because any web page can read the DOM of a new window/tab it creates.
And even if we do, current letterboxing implementation seems to have a race condition allowing the op...We should apply letterboxing to about:blank (we currently do not) because any web page can read the DOM of a new window/tab it creates.
And even if we do, current letterboxing implementation seems to have a race condition allowing the opener to bypass letterboxing.
PoC:
https://people.torproject.org/~ma1/bugs/lb/
@richard , @pierovSponsor 131 - Phase 5 - Ongoing Maintenancema1ma1https://gitlab.torproject.org/tpo/core/arti/-/issues/621Bump to MSRV 1.{60,61} for Arti 1.1.0?2022-11-10T17:06:26ZNick MathewsonBump to MSRV 1.{60,61} for Arti 1.1.0?In August, we decided not to bump our MSRV to 1.59 for Arti 1.0.0 (#538).
By our rules, we could now bump to MSRV 1.60 for 1.1.0. In two weeks (November 19), we could bump to MSRV 1.61.
In addition to the reasons discussed in #538 for...In August, we decided not to bump our MSRV to 1.59 for Arti 1.0.0 (#538).
By our rules, we could now bump to MSRV 1.60 for 1.1.0. In two weeks (November 19), we could bump to MSRV 1.61.
In addition to the reasons discussed in #538 for upgrading to ≥1.59, here are the reasons for updating to 1.60:
* Greatly improved cargo [feature handling](https://blog.rust-lang.org/2022/04/07/Rust-1.60.0.html#new-syntax-for-cargo-features). We'd use this in #434.
For requiring 1.61, we would also get:
* Better `const fn`s.
* A few stabilized APIs that we would use (including `Vec::retain_mut`).
These are all nice-to-have, but not IMO knock-down compelling. IMO the main reason to consider updating our MSRV is the number of our dependencies whose latest versions require a higher MSRV. They are currently:
* `rsa` (#613)
* `tinystr` (#591)
* `serde_with`, `phf` (#526)
* `clap` (!829)Arti 1.1.0: Anticensorship readyNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/tpa/nextcloud/-/issues/16Changing timezone for events stopped working2022-11-07T19:14:42ZGabagaba@torproject.orgChanging timezone for events stopped workingHey!
I used to change the timezone for events in the nextcloud calendar because otherwise people would get a notification email with the meeting's time in my timezone and they would get very confused. BUT after last nextcloud upgrade I ...Hey!
I used to change the timezone for events in the nextcloud calendar because otherwise people would get a notification email with the meeting's time in my timezone and they would get very confused. BUT after last nextcloud upgrade I can not change the timezone of the event. When I click the 'world button' nothing happens.
This is the bug in nextcloud: https://github.com/nextcloud/calendar/issues/4630https://gitlab.torproject.org/tpo/core/tor/-/issues/40706Tor gets killed by OOM killer2022-11-01T13:26:30ZanongTor gets killed by OOM killerHi,
my relay has been killed a few times by my OS's OOM killer in the last few days.
https://metrics.torproject.org/rs.html#details/F2D6EB211744D41DC41CCB62BF1C3246D24B42A2
`Tor 0.4.7.10 running on Linux with Libevent 2.1.12-stable, O...Hi,
my relay has been killed a few times by my OS's OOM killer in the last few days.
https://metrics.torproject.org/rs.html#details/F2D6EB211744D41DC41CCB62BF1C3246D24B42A2
`Tor 0.4.7.10 running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 and Glibc 2.31 as libc.`
MaxMemInQueues was set to 3072 MB when the last crash happened. System is an Debian LXC container with currently 10 gigabytes of RAM.
OS is `Debian GNU/Linux 11 (bullseye)`
Tor is installed via official Debian repositories.
```
Oct 27 22:47:27 Tor systemd[1]: tor@default.service: A process of this unit has been killed by the OOM killer.
Oct 27 22:47:27 Tor systemd[1]: tor@default.service: Main process exited, code=killed, status=9/KILL
Oct 27 22:47:27 Tor systemd[1]: tor@default.service: Failed with result 'oom-kill'.
Oct 27 22:47:27 Tor systemd[1]: tor@default.service: Consumed 2d 13h 43min 1.409s CPU time.
Oct 27 22:47:28 Tor systemd[1]: tor@default.service: Scheduled restart job, restart counter is at 4.
Oct 27 22:47:28 Tor systemd[1]: Stopped Anonymizing overlay network for TCP.
Oct 27 22:47:28 Tor systemd[1]: tor@default.service: Consumed 2d 13h 43min 1.409s CPU time.
Oct 27 22:47:28 Tor systemd[1]: Starting Anonymizing overlay network for TCP...
```
MaxMemInQueues is now not specifically defined anymore, so automatically determined.
Complete startup sequence from current run:
```
Oct 27 22:47:28 Tor tor[6405]: Oct 27 22:47:28.248 [notice] Tor 0.4.7.10 running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 and Glibc 2.31 as libc.
Oct 27 22:47:28 Tor tor[6405]: Oct 27 22:47:28.248 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/
Oct 27 22:47:28 Tor tor[6405]: Oct 27 22:47:28.248 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Oct 27 22:47:28 Tor tor[6405]: Oct 27 22:47:28.248 [notice] Read configuration file "/etc/tor/torrc".
Oct 27 22:47:28 Tor tor[6405]: Oct 27 22:47:28.249 [warn] Skipping obsolete configuration option "SocksListenAddress".
Oct 27 22:47:28 Tor tor[6405]: Oct 27 22:47:28.251 [notice] Based on detected system memory, MaxMemInQueues is set to 4096 MB. You can override this by setting MaxMemInQueues by hand.
Oct 27 22:47:28 Tor tor[6405]: Configuration was valid
Oct 27 22:47:28 Tor tor[6407]: Oct 27 22:47:28.265 [notice] Tor 0.4.7.10 running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 and Glibc 2.31 as libc.
Oct 27 22:47:28 Tor tor[6407]: Oct 27 22:47:28.265 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/
Oct 27 22:47:28 Tor tor[6407]: Oct 27 22:47:28.265 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Oct 27 22:47:28 Tor tor[6407]: Oct 27 22:47:28.265 [notice] Read configuration file "/etc/tor/torrc".
Oct 27 22:47:28 Tor tor[6407]: Oct 27 22:47:28.265 [warn] Skipping obsolete configuration option "SocksListenAddress".
Oct 27 22:47:28 Tor tor[6407]: Oct 27 22:47:28.266 [notice] Based on detected system memory, MaxMemInQueues is set to 4096 MB. You can override this by setting MaxMemInQueues by hand.
Oct 27 22:47:28 Tor tor[6407]: Oct 27 22:47:28.267 [notice] I think we have 8 CPUS, but only 4 of them are available. Telling Tor to only use 4. You can override this with the NumCPUs option
Oct 27 22:47:28 Tor tor[6407]: Oct 27 22:47:28.267 [notice] You configured a non-loopback address '192.168.100.9:9050' for SocksPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is wha>
Oct 27 22:47:28 Tor tor[6407]: Oct 27 22:47:28.267 [notice] Opening Socks listener on 192.168.100.9:9050
Oct 27 22:47:28 Tor tor[6407]: Oct 27 22:47:28.267 [notice] Opened Socks listener connection (ready) on 192.168.100.9:9050
Oct 27 22:47:28 Tor tor[6407]: Oct 27 22:47:28.267 [notice] Opening Control listener on 127.0.0.1:9051
Oct 27 22:47:28 Tor tor[6407]: Oct 27 22:47:28.267 [notice] Opened Control listener connection (ready) on 127.0.0.1:9051
Oct 27 22:47:28 Tor tor[6407]: Oct 27 22:47:28.267 [notice] Opening OR listener on 0.0.0.0:443
Oct 27 22:47:28 Tor tor[6407]: Oct 27 22:47:28.267 [notice] Opened OR listener connection (ready) on 0.0.0.0:443
Oct 27 22:47:28 Tor tor[6407]: Oct 27 22:47:28.267 [notice] Opening OR listener on [2003:a:1504:6000:a03a:d1ff:fea1:8062]:443
Oct 27 22:47:28 Tor tor[6407]: Oct 27 22:47:28.267 [notice] Opened OR listener connection (ready) on [2003:a:1504:6000:a03a:d1ff:fea1:8062]:443
Oct 27 22:47:28 Tor tor[6407]: Oct 27 22:47:28.267 [notice] Opening Directory listener on 0.0.0.0:80
Oct 27 22:47:28 Tor tor[6407]: Oct 27 22:47:28.267 [notice] Opened Directory listener connection (ready) on 0.0.0.0:80
```
Which more information is needed? Can you help me find the cause of this issue?https://gitlab.torproject.org/tpo/core/arti/-/issues/613Upgrade to rsa 0.7.0 once we are on MSRV ≥ 1.572022-11-10T17:06:25ZNick MathewsonUpgrade to rsa 0.7.0 once we are on MSRV ≥ 1.57The `rsa` crate now requires Rust 1.57 or later.The `rsa` crate now requires Rust 1.57 or later.https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/probeobserver/-/issues/1probeobserver, plus dynamic bridges, both need to upgrade to modern obfs4proxy2023-06-27T18:45:10ZRoger Dingledineprobeobserver, plus dynamic bridges, both need to upgrade to modern obfs4proxyShel tells me that our bridgestatus measurers are still using obfs4proxy 0.0.8, which means when they are probing a modern obfs4 bridge, they suffer from the compatibility issues in https://gitlab.torproject.org/tpo/applications/tor-brow...Shel tells me that our bridgestatus measurers are still using obfs4proxy 0.0.8, which means when they are probing a modern obfs4 bridge, they suffer from the compatibility issues in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40804 -- meaning that 75% of the connection attempts will fail.
This issue might explain why many of the bridgestatus probes take a long time before they connect.
It also could mean that our data so far are suspect, because we learned in the analysis of https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/92 that we rotate away from a bridge, and call it a blocking event, as soon as a connection to it fails from any country. So, Tor will try a few times to connect, but if it gets unlucky each time, we are calling the bridge blocked when actually we're just using an incompatible client to try to reach it.
So, I see two^Wthree activities here:
* [ ] Upgrade the obfs4proxy on the client side to 0.0.14.
* [x] Do a pass using dcf's bridge scanner to get a sense of how many of the target bridges are using the modern obfs4proxy vs how many are using the legacy one. That will help us understand how much of an impact this bug had on our data so far.
* [ ] Get the dynamic probe server-side code to switch its obfs4proxy version at the same time as we update the client.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41401Missing some mozilla icons because we still loading them from "chrome://brows...2022-10-27T17:56:38ZhenryMissing some mozilla icons because we still loading them from "chrome://browser/skin" rather than "chrome://global/skin/icons"I noticed that the "Onion Services Keys" prefernces dialog is missing its warning icon because it still uses "chrome://browser/skin/warning.svg" rather than "chrome://global/skin/icons/warning.svg". I'm guessing these icon paths were cha...I noticed that the "Onion Services Keys" prefernces dialog is missing its warning icon because it still uses "chrome://browser/skin/warning.svg" rather than "chrome://global/skin/icons/warning.svg". I'm guessing these icon paths were changed in mozilla-central. Some have been converted in our patches, but not all.Sponsor 131 - Phase 3 - Major ESR 102 Migrationhenryhenryhttps://gitlab.torproject.org/tpo/core/arti/-/issues/610Write a fuzzer for `PtMessage` from tor-ptmgr/ipc2022-11-15T22:01:46ZetaWrite a fuzzer for `PtMessage` from tor-ptmgr/ipcIt's a bunch of string parsing code, so it'd be good to fuzz, and @nickm wanted to have a go at fuzzing it.It's a bunch of string parsing code, so it'd be good to fuzz, and @nickm wanted to have a go at fuzzing it.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40704relay: Onionskin wait cutoff and MaxOnionQueueDelay in queue should be conse...2022-11-12T09:00:36ZDavid Gouletdgoulet@torproject.orgrelay: Onionskin wait cutoff and MaxOnionQueueDelay in queue should be consensus parametersOur onion queue code, using the CPU thread pool, has this value hardcoded:
```
/** 5 seconds on the onion queue til we just send back a destroy */
#define ONIONQUEUE_WAIT_CUTOFF 5
```
This is used when we add an onionskin to the qu...Our onion queue code, using the CPU thread pool, has this value hardcoded:
```
/** 5 seconds on the onion queue til we just send back a destroy */
#define ONIONQUEUE_WAIT_CUTOFF 5
```
This is used when we add an onionskin to the queue, we will drop any requests that has been longer than that in the queue by sending a `DESTROY`.
There is also a torrc option named `MaxOnionQueueDelay` that behaves a bit differently. If it takes tor more time than that value to process an ntor, reject it.
Both of these should be consensus parameters because they can affect strongly how our relays behave in times of load or attack like at the moment. For instance, under the DoS conditions of the network, it is possible (unproven) that extending `MaxOnionQueueDelay` to a longer wait time could result in less overload from our relays. But, this is a torrc option meaning that if not all 6000 relays update at once, we might have this partitioning problem.
If one group of the network sets that value higher leading to more room to handle onionskins, it means that these relays will have a higher CBT value which would transition circuit creation away from them to more overloaded relays.
If the network all at once change that value, CBT should in theory remains uniform for all path but just that all the sudden, circuit creation fails less but takes more time.Tor: 0.4.8.x-freezehttps://gitlab.torproject.org/tpo/core/onionmasq/-/issues/21Integrate IPtProxy for PT support2024-02-01T12:07:48Zmicahmicah@torproject.orgIntegrate IPtProxy for PT supportWe expect that part of TorVPN need will be onionmasq being able to call IPtProxy for PT support, ideally onionmasq would start and stop IPtProxy as necessary and probably the communication would happen over SOCKS. This integration work i...We expect that part of TorVPN need will be onionmasq being able to call IPtProxy for PT support, ideally onionmasq would start and stop IPtProxy as necessary and probably the communication would happen over SOCKS. This integration work in onionmasq will need to be done at the rust level and use the FFI to interface.Sponsor 101 - Tor VPN Client for Androidhttps://gitlab.torproject.org/tpo/web/support/-/issues/313Review and update the support article about circumventing censorship in China2023-10-31T16:10:20Zchampionquizzerchampionquizzer@torproject.orgReview and update the support article about circumventing censorship in ChinaWe should encourage users to use Connection Assist (ref. https://gitlab.torproject.org/tpo/anti-censorship/rdsys-admin/-/merge_requests/7/diffs)We should encourage users to use Connection Assist (ref. https://gitlab.torproject.org/tpo/anti-censorship/rdsys-admin/-/merge_requests/7/diffs)Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & TibetGusGushttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40217Upgrade utls dependency to v1.1.3 or later2023-10-11T05:28:38ZDavid Fifielddcf@torproject.orgUpgrade utls dependency to v1.1.3 or laterOur [current version](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/v2.3.1/go.mod#L15) is [v1.0.0](https://github.com/refraction-networking/utls/releases/tag/v1.0.0) from 2021-11-02. Newer releas...Our [current version](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/v2.3.1/go.mod#L15) is [v1.0.0](https://github.com/refraction-networking/utls/releases/tag/v1.0.0) from 2021-11-02. Newer releases have important enhancements, notably new and corrected fingerprints:
* [Implement certificate compression #95](https://github.com/refraction-networking/utls/pull/95)
* [new ClientHellos and Extensions #116](https://github.com/refraction-networking/utls/pull/116)
* Chrome_87
* Chrome_96
* Chrome_100
* Chrome_102
* Firefox_99
* Firefox_102
* iOS_13
* iOS_14
* Android_11
* ApplicationSettingsExtension
* SignatureAlgorithmsCertExtension
* DelegatedCredentialsExtension
* StatusRequestExtension
* [Add new ClientHellos #122](https://github.com/refraction-networking/utls/pull/122)
* Firefox 105
* Chrome 106
* Edge 106
* Safari 16.0
* 360 Secure Browser 11.0
* QQ Browser 11.1
* [Fix Google Parrots #125](https://github.com/refraction-networking/utls/pull/125)
You may not want to automatically include every possible new supported fingerprint. For example, see [this caveat](https://github.com/refraction-networking/utls/pull/122#issue-1401840671):
> Unfortunately, the specs based on Edge 106 and 360 11.0 seem to incompatible with this library.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/web/tpo/-/issues/329Broken Reports page link at donor FAQ2022-10-13T18:08:19ZmattlavBroken Reports page link at donor FAQA job for @kez - Our Donor FAQ has a missing link, here:
https://donate.torproject.org/donor-faq/#how-will-you-use-my-donation
It should lead to:
https://www.torproject.org/about/reports/A job for @kez - Our Donor FAQ has a missing link, here:
https://donate.torproject.org/donor-faq/#how-will-you-use-my-donation
It should lead to:
https://www.torproject.org/about/reports/https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41361Integrate the Conjure PT into alpha versions of Tor Browser2023-06-29T17:45:14ZCecylia BocovichIntegrate the Conjure PT into alpha versions of Tor BrowserLooks like it's going to be easily done on all platforms. See https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/14Looks like it's going to be easily done on all platforms. See https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/14Sponsor 30 - Objective 2.3Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41350Move the implementation of Bug 19273 out of Torbutton2023-04-18T17:46:38ZPier Angelo VendrameMove the implementation of Bug 19273 out of TorbuttonBug #19273 (e.g., 2cce8efa3cede0324b58e2e9a6b2b40e5a48bb87) has a part in Torbutton.
We should move it outside of it, and possibly move it before other Tor patches.
Uplifting it would be lovely, but very unlikely (since it explicitly s...Bug #19273 (e.g., 2cce8efa3cede0324b58e2e9a6b2b40e5a48bb87) has a part in Torbutton.
We should move it outside of it, and possibly move it before other Tor patches.
Uplifting it would be lovely, but very unlikely (since it explicitly says to use only Tor or Tails).
Finally, the title is a bit misleading, we could reword it to say it's the external app warning dialog, rather than saying "prevent JS from hijacking", even though this was the original reason for that ticket.Sponsor 131 - Phase 2 - Privacy BrowserDan BallardDan Ballardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41341Fix style and position of "Always Prioritize Onions" wingpanel2023-11-16T00:29:05ZdonutsFix style and position of "Always Prioritize Onions" wingpanelIt looks like we missed this one during the proton-ification of Tor Browser 11.0:
![always-prioritize-onions](/uploads/09fb1f753433285f88c94e9d7bf758b9/always-prioritize-onions.png)
It's not disastrous, but we should fix the body font ...It looks like we missed this one during the proton-ification of Tor Browser 11.0:
![always-prioritize-onions](/uploads/09fb1f753433285f88c94e9d7bf758b9/always-prioritize-onions.png)
It's not disastrous, but we should fix the body font weight for readability and the alignment of the whole wingpanel with the `.onion available` pill so it's clearer what it's referring to.henryhenryhttps://gitlab.torproject.org/tpo/network-health/team/-/issues/266Evaluate proposals for relay operator code of conduct, policies, agreements a...2023-06-14T16:53:07ZGabagaba@torproject.orgEvaluate proposals for relay operator code of conduct, policies, agreements and methods for enforcementThis is activity O2.2 for [sponsor 112](https://gitlab.torproject.org/groups/tpo/-/milestones/44#tab-issues):
Evaluate promising solutions for relay operator code of conduct, policies, agreements, and methods for enforcement. In this Ac...This is activity O2.2 for [sponsor 112](https://gitlab.torproject.org/groups/tpo/-/milestones/44#tab-issues):
Evaluate promising solutions for relay operator code of conduct, policies, agreements, and methods for enforcement. In this Activity, our goal is to engage relay operators and gather feedback about potential solutions around establishing behavior expectations and clear consequences.
- Gather input from the community on any concepts developed in this project. This involves online events and discussions where we engage with relay operators in different phases of the relay operator life cycle.
- Develop recommendations for activities [2.3](https://gitlab.torproject.org/tpo/network-health/team/-/issues/267) and [2.4](https://gitlab.torproject.org/tpo/network-health/team/-/issues/268) based on the research findings and the relay operator personas definition developed as part of the OTF fellowship alongside input collected in this Activity.https://gitlab.torproject.org/tpo/network-health/team/-/issues/265Create evaluation criteria for success of solutions for relay operator code o...2023-06-14T16:53:07ZGabagaba@torproject.orgCreate evaluation criteria for success of solutions for relay operator code of conducts, policies, agreements and methods for enforcementThis is activity O2.1 for [sponsor 112](https://gitlab.torproject.org/groups/tpo/-/milestones/44#tab-issues):
Develop evaluation criteria for determining if behavior expectation and consequence solutions are appropriate. In this Activit...This is activity O2.1 for [sponsor 112](https://gitlab.torproject.org/groups/tpo/-/milestones/44#tab-issues):
Develop evaluation criteria for determining if behavior expectation and consequence solutions are appropriate. In this Activity, we will define evaluation criteria for the success of policies, agreements, and methods of enforcement. This Activity will allow the Tor Project to evaluate the solutions we choose in [activity O2.3](https://gitlab.torproject.org/tpo/network-health/team/-/issues/267) of the same project and determine if we have met the community’s expressed needs.2022-12-16https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40206Broker status 500 when client requests fingerprint of snowflake-022023-03-14T16:42:43ZDavid Fifielddcf@torproject.orgBroker status 500 when client requests fingerprint of snowflake-02I was not sure whether distributed bridge support
(#40129, #28651) was supposed to be working yet, so I tried it.
I am using the client from commit 9ce1de4eee4e23c918c7c5e96666ff5c6ddc654e.
When I tried rendezvousing with the fingerprint...I was not sure whether distributed bridge support
(#40129, #28651) was supposed to be working yet, so I tried it.
I am using the client from commit 9ce1de4eee4e23c918c7c5e96666ff5c6ddc654e.
When I tried rendezvousing with the fingerprint of the
[snowflake-02 bridge](tpo/anti-censorship/pluggable-transports/snowflake#40122),
I got a 500 Internal Server Error, which was unexpected.
It makes me wonder if the broker is encountering an internal error and panicking,
or if 500 is the intended response code.
This torrc file works:
```
UseBridges 1
SocksPort auto
DataDirectory datadir
ClientTransportPlugin snowflake exec ./client -log snowflake.log
Bridge snowflake 192.0.2.3:80 2B280B23E1107BB62ABFC40DDCC8824814F80A72 fingerprint=2B280B23E1107BB62ABFC40DDCC8824814F80A72 url=https://snowflake-broker.torproject.net/ ice=stun:stun.voip.blackberry.com:3478,stun:stun.altar.com.pl:3478,stun:stun.antisip.com:3478,stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.sonetel.com:3478,stun:stun.sonetel.net:3478,stun:stun.stunprotocol.org:3478,stun:stun.uls.co.za:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478
```
This torrc file does not work. The only difference is changing the fingerprint
`2B280B23E1107BB62ABFC40DDCC8824814F80A72` to `8838024498816A039FCBBAB14E6F40A0843051FA`
in both places.
```
UseBridges 1
SocksPort auto
DataDirectory datadir
ClientTransportPlugin snowflake exec ./client -log snowflake.log
Bridge snowflake 192.0.2.3:80 8838024498816A039FCBBAB14E6F40A0843051FA fingerprint=8838024498816A039FCBBAB14E6F40A0843051FA url=https://snowflake-broker.torproject.net/ ice=stun:stun.voip.blackberry.com:3478,stun:stun.altar.com.pl:3478,stun:stun.antisip.com:3478,stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.sonetel.com:3478,stun:stun.sonetel.net:3478,stun:stun.stunprotocol.org:3478,stun:stun.uls.co.za:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478
```
The broker's HTTP response is:
```
500 Internal Server Error
Access-Control-Allow-Headers: Origin, X-Session-ID
Access-Control-Allow-Origin: *
Content-Length: 0
Date: Tue, 04 Oct 2022 16:33:06 GMT
```https://gitlab.torproject.org/tpo/core/arti/-/issues/596Test failure for rtt::test::rtt_test_vectors on OSX with M12022-10-04T19:09:56ZNick MathewsonTest failure for rtt::test::rtt_test_vectors on OSX with M1
```
--- STDERR: tor-congestion rtt::test::rtt_test_vectors ---
testing RttTestSample { sent_nsec: 100, sendme_received_nsec: 200, last_rtt_out_nsec: 100, ewma_rtt_out_nsec: 100, min_rtt_out_nsec: 100 }
thread '...
```
--- STDERR: tor-congestion rtt::test::rtt_test_vectors ---
testing RttTestSample { sent_nsec: 100, sendme_received_nsec: 200, last_rtt_out_nsec: 100, ewma_rtt_out_nsec: 100, min_rtt_out_nsec: 100 }
thread 'rtt::test::rtt_test_vectors' panicked at 'assertion failed: `(left == right)`
left: `83ns`,
right: `100ns`', crates/tor-congestion/src/rtt.rs:335:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Hi! I don't know what went wrong here, but this error occurs whenever I run the unit tests on my laptop. It's an M1 macbook pro running OSX 12.6. The error occurs with Rust 1.64 and rust nightly.
If this is an easy fix, let's go for it -- otherwise we can just disable this test for now, since it's not in code we're using yet?
cc @eta