The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-09-15T19:57:13Zhttps://gitlab.torproject.org/tpo/team/-/issues/2test2020-09-15T19:57:13Zgabelulatesttesttesthttps://gitlab.torproject.org/tpo/ux/design/-/issues/1Huge bezels on the sides after updating to v102020-09-24T15:45:46ZYog SothothHuge bezels on the sides after updating to v10Currently Tor Browser 10 window on OSX 10.14 looks like that:
![Screenshot_2020-09-24_at_18.33.28](/uploads/6bbb7d852b2bbb7619d2904fbe0ea53b/Screenshot_2020-09-24_at_18.33.28.png)
with huge bezels between the window border and actual we...Currently Tor Browser 10 window on OSX 10.14 looks like that:
![Screenshot_2020-09-24_at_18.33.28](/uploads/6bbb7d852b2bbb7619d2904fbe0ea53b/Screenshot_2020-09-24_at_18.33.28.png)
with huge bezels between the window border and actual web content, which randomly resize when the window gets resized. What is this and how can that be fixed?https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/1Use timers to determine when it's time to prune cache entries2020-12-14T19:00:42ZPhilipp Winterphw@torproject.orgUse timers to determine when it's time to prune cache entriesEach time a new cache entry is added, [bridgestrap iterates](https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/blob/471ab0714f3966621f9f40aa707f3d12b0711410/tor.go#L108) over existing cache entries to figure out what entrie...Each time a new cache entry is added, [bridgestrap iterates](https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/blob/471ab0714f3966621f9f40aa707f3d12b0711410/tor.go#L108) over existing cache entries to figure out what entries have expired:
```golang
// First, prune expired cache entries.
now := time.Now()
cacheMutex.Lock()
for index, entry := range *tc {
if entry.Time.Before(now.Add(-CacheValidity)) {
delete(*tc, index)
}
}
```
This scales linearly, which is bad news. On my core i7 2.9 GHz laptop, it takes 0.3 ms to prune a cache holding 10,000 elements. @cohosh [suggested](https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/commit/ecc6e0487655af9ab6f91ff4fbab7ce76d11caa7#note_2709958) that we could use Timers instead: each time a cache entry is added, we set up a new timer. In parallel, we have a goroutine running that waits for the timers to fire, to then delete the expired cache entries.https://gitlab.torproject.org/tpo/anti-censorship/monit-configuration/-/issues/2Add Snowflake's probe service once it's deployed2020-11-09T16:46:44ZPhilipp Winterphw@torproject.orgAdd Snowflake's probe service once it's deployedOver at tpo/anti-censorship/pluggable-transports/snowflake#40013, we are planning to build a probe service that helps Snowflake proxies figure out their NAT type. Once the service is live, we should start monitoring it.Over at tpo/anti-censorship/pluggable-transports/snowflake#40013, we are planning to build a probe service that helps Snowflake proxies figure out their NAT type. Once the service is live, we should start monitoring it.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/1SENDME failures on iterated flood/download tests2023-08-30T18:58:35ZNick MathewsonSENDME failures on iterated flood/download testsI believe that there are a pair of linked bugs in our current SENDME cell handling: we count begin and end cells towards towards window totals when we are only supposed to count DATA cells, _and_ we send our sendmes one cell too early (o...I believe that there are a pair of linked bugs in our current SENDME cell handling: we count begin and end cells towards towards window totals when we are only supposed to count DATA cells, _and_ we send our sendmes one cell too early (or maybe late?).
I think that these two bugs cancel each other out on the first stream on each circuit, but with the second stream, they cause the circuit to failNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/team/-/issues/1Organizing triaging new issues for the applications group2023-09-27T14:47:43ZGabagaba@torproject.orgOrganizing triaging new issues for the applications groupWe need a better process and shifts for triaging tickets so it does not fall only in one person or does not get done:
- [ ] process - how we are doing triage - where the tickets go to - define criteria for triaging a ticket into a miles...We need a better process and shifts for triaging tickets so it does not fall only in one person or does not get done:
- [ ] process - how we are doing triage - where the tickets go to - define criteria for triaging a ticket into a milestone
- [ ] who is doing it when
- [ ] add documentation to https://gitlab.torproject.org/tpo/applications/teamGabagaba@torproject.orgGabagaba@torproject.orghttps://gitlab.torproject.org/tpo/tpa/anon_ticket/-/issues/1Attempting to Post an Issue from Within Django Admin2021-02-08T18:01:40ZMariaVAttempting to Post an Issue from Within Django Admin1st attempt to post an issue from within django admin by overriding Issue.save(), calling Issue.approve_issue() with change in Issue.reviewer_status to 'A'.1st attempt to post an issue from within django admin by overriding Issue.save(), calling Issue.approve_issue() with change in Issue.reviewer_status to 'A'.Sponsor 102 Outreachy Project: Anonymous Ticket HandlingMariaVMariaVhttps://gitlab.torproject.org/tpo/anti-censorship/gettor-project/OnionSproutsBot/-/issues/1[PSA] Project temporarily unmaintained2021-06-10T14:09:59Zn0toose[PSA] Project temporarily unmaintainedHey, I'm opening this issue as a general PSA that I'm going to get back to working on this around **Q3 2021** and *hopefully* finish this for good.
Doing so will provide me with the ability to invest a lot of time in an organized, focus...Hey, I'm opening this issue as a general PSA that I'm going to get back to working on this around **Q3 2021** and *hopefully* finish this for good.
Doing so will provide me with the ability to invest a lot of time in an organized, focused manner and ultimately finish this. I'll also hopefully begin to make some similar implementations for other platforms, which I've already set the foundations for. I'll be right back.
Please feel more than free to tinker around with this in the meantime.
Thanks,
Panosn0toosen0toose2021-07-01https://gitlab.torproject.org/tpo/network-health/metrics/timeline/-/issues/2Add Uganda internet shutdown (Jan 2021)2021-02-05T21:30:50ZGusAdd Uganda internet shutdown (Jan 2021)Last week there was an internet shutdown in Uganda:
https://qz.com/africa/1957137/uganda-cuts-off-internet-ahead-of-election-polls-opening/
https://www.accessnow.org/the-world-is-watching-uganda-elections/
We can see an interruption on...Last week there was an internet shutdown in Uganda:
https://qz.com/africa/1957137/uganda-cuts-off-internet-ahead-of-election-polls-opening/
https://www.accessnow.org/the-world-is-watching-uganda-elections/
We can see an interruption on Tor metrics graph
![Screenshot_2021-01-20_Users___Tor_Metrics](/uploads/7faad2c6184fe6b9d0c1ad5d1df735ba/Screenshot_2021-01-20_Users___Tor_Metrics.png)https://gitlab.torproject.org/tpo/network-health/bandwidth-authorities/-/issues/1Remove old bandwidth authorities wiki?2021-06-15T14:25:26ZjugaRemove old bandwidth authorities wiki?As commented in https://gitlab.torproject.org/tpo/core/team/-/issues/16 this wiki page https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/BandwidthAuthority contains old information.
Maybe there could be a link in this proj...As commented in https://gitlab.torproject.org/tpo/core/team/-/issues/16 this wiki page https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/BandwidthAuthority contains old information.
Maybe there could be a link in this project wiki pointing to that page at legacy/archived Trac.Gabagaba@torproject.orgGabagaba@torproject.orghttps://gitlab.torproject.org/tpo/tpa/triage-ops/-/issues/1consider the user's busy status when assigning issues2022-04-12T18:29:08Zanarcatconsider the user's busy status when assigning issuesit might be good to skip (or rank down somehow) users that are marked as "busy", so that users have a way to schedule themselves AFK, when they go on vacation for example.
obviously, it could backfire if people forget to unset the busy ...it might be good to skip (or rank down somehow) users that are marked as "busy", so that users have a way to schedule themselves AFK, when they go on vacation for example.
obviously, it could backfire if people forget to unset the busy status when they return, but it seems still worthwhile to look into.
i explicitly do not mention the idea of writing a bot which rewrites the ruby code based on nextcloud calendar status. that way lies madness. (although having a sync between the "busy" status and the nextcloud calendar would surely be nice, but that's still a separate issue.)Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/onion-services/onionbalance/-/issues/1Onionbalance crashing at startup2021-06-04T15:49:13ZHiroOnionbalance crashing at startupI am configuring onionbalance v3 and it's crashing with the following error
```
# onionbalance -v info -c config.yaml -p 6666
2021-03-26 21:30:18,904 [WARNING]: Initializing onionbalance (version: 0.2.0)...
2021-03-26 21:30:18,906 [INFO]...I am configuring onionbalance v3 and it's crashing with the following error
```
# onionbalance -v info -c config.yaml -p 6666
2021-03-26 21:30:18,904 [WARNING]: Initializing onionbalance (version: 0.2.0)...
2021-03-26 21:30:18,906 [INFO]: Loaded the config file '/etc/onionbalance/config.yaml'.
Traceback (most recent call last):
File "/usr/sbin/onionbalance", line 11, in <module>
load_entry_point('OnionBalance==0.2.0', 'console_scripts', 'onionbalance')()
File "/usr/lib/python3/dist-packages/onionbalance/manager.py", line 31, in main
onionbalance.hs_v3.manager.main(args)
File "/usr/lib/python3/dist-packages/onionbalance/hs_v3/manager.py", line 27, in main
my_onionbalance.init_subsystems(args)
File "/usr/lib/python3/dist-packages/onionbalance/hs_v3/onionbalance.py", line 50, in init_subsystems
self.consensus = ob_consensus.Consensus()
File "/usr/lib/python3/dist-packages/onionbalance/hs_v3/consensus.py", line 35, in __init__
self.refresh()
File "/usr/lib/python3/dist-packages/onionbalance/hs_v3/consensus.py", line 44, in refresh
md_consensus_str = my_onionbalance.controller.get_md_consensus().encode()
File "/usr/lib/python3/dist-packages/onionbalance/hs_v3/stem_controller.py", line 63, in get_md_consensus
return self.controller.get_info("dir/status-vote/current/consensus-microdesc")
File "/usr/lib/python3/dist-packages/stem/control.py", line 489, in wrapped
return func(self, *args, **kwargs)
File "/usr/lib/python3/dist-packages/stem/control.py", line 1209, in get_info
stem.response.convert('GETINFO', response)
File "/usr/lib/python3/dist-packages/stem/response/__init__.py", line 124, in convert
message._parse_message(**kwargs)
File "/usr/lib/python3/dist-packages/stem/response/getinfo.py", line 44, in _parse_message
raise stem.InvalidArguments('552', 'GETINFO request contained unrecognized keywords: %s\n' % ', '.join(unrecognized_keywords), unrecognized_keywords)
stem.InvalidArguments: GETINFO request contained unrecognized keywords: dir/status-vote/current/consensus-microdesc
```
It actually seems a stem error. Do you have an idea of how this should be debugged?https://gitlab.torproject.org/tpo/community/hackweek/-/issues/1move documentation from pads to here2021-04-08T17:18:17Zanarcatmove documentation from pads to herewe have had 10 great sprints during this hackweek, and some notes were taken in pads, which will die in a year if we don't salvage them.
it seems to me we could dump them here.
- [x] [1 Prometheus alerts for anti-censorship metrics](ht...we have had 10 great sprints during this hackweek, and some notes were taken in pads, which will die in a year if we don't salvage them.
it seems to me we could dump them here.
- [x] [1 Prometheus alerts for anti-censorship metrics](https://gitlab.torproject.org/tpo/community/hackweek/-/merge_requests/7) (@cohosh, @anarcat)
- [x] [2 Prototype network-namespace-based torsocks](#2-prototype-network-namespace-based-torsocks) (@jnewsome, @dgoulet)
- [x] [3 Add support for UDP sockets over onion services, possibly with enabling support for WebRTC in Tor Browser](#3-add-support-for-udp-sockets-over-onion-services-possibly-with-enabling-support-for-webrtc-in-tor-browser) (@sysrqb)
- [x] [4 Visualize Tor metrics's data in ways that it can be useful for community](#4-visualize-tor-metricss-data-in-ways-that-it-can-be-useful-for-community) (@gus and @gaba)
- [x] [5 Prototype Rust+Arti-based HTTP frontend cache for directory authorities](#5-prototype-rustarti-based-http-frontend-cache-for-directory-authorities) (@nickm)
- [x] [6 Onionshare download accelerator](#6-onionshare-download-accelerator) (@mikeperry, @micah)
- [x] [7 Vanguards doc updates, bugfixes, packages for onionshare and/or Tor Browser](#7-vanguards-doc-updates-bugfixes-packages-for-onionshare-andor-tor-browser) (@mikeperry)
- [x] [8 Circuit Padding Simulator](#8-circuit-padding-simulator) (@mikeperry)
- [x] [9 Onion service v3 support for arti](#9-onion-service-v3-support-for-arti) (@asn)
- [x] [10 Network Health tooling using Rust and arti](#10-network-health-tooling-using-rust-and-arti) (@dgoulet)https://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/1Create tests for the edge cases where some bandwidth value should be 0 or 12023-03-17T11:19:29ZjugaCreate tests for the edge cases where some bandwidth value should be 0 or 1In sbws there were some bugs resulting from taking 1 or 0 as the minimum to calculate some bandwidth value.
Even thought i tried to take them into account when coding onbasca, i didn't have all of them on the top of my head and it'd be n...In sbws there were some bugs resulting from taking 1 or 0 as the minimum to calculate some bandwidth value.
Even thought i tried to take them into account when coding onbasca, i didn't have all of them on the top of my head and it'd be nice to search for them in the current code to ensure the choice is correct.
Let's create some tests to ensure the choices are correct.onbasca: 1.1https://gitlab.torproject.org/tpo/network-health/helper-scripts/-/issues/18Write script that helps with fd related overload2023-05-23T09:08:50ZGeorg KoppenWrite script that helps with fd related overloadAs we have seen in https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/24#note_2791135 there are quite some spurious fd overload related hits, even if we take only an 18h overload window (instead of the 72h one). However, ...As we have seen in https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/24#note_2791135 there are quite some spurious fd overload related hits, even if we take only an 18h overload window (instead of the 72h one). However, as we've also seen there are some persistently overloaded relays among them.
We should write a script that is doing the analysis for us, daily, and saves every day the fingerprints that have shown up for the past X days (X could be something like 3 or 5 maybe) for someone reaching out to affected operators.https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/logcollector-admin/-/issues/1Support Automatic Bridge Info update2022-09-15T23:28:01ZshelikhooSupport Automatic Bridge Info updateCurrently, bridges from @irl are updated manually and transferred over email.
We are currently working on automating this step to enable Unattended Dynamic Bridge Life Cycle Management. In this way, the bridges will be monitored for acc...Currently, bridges from @irl are updated manually and transferred over email.
We are currently working on automating this step to enable Unattended Dynamic Bridge Life Cycle Management. In this way, the bridges will be monitored for accessibility from various vantage points. The result of this process will be processed by @irl's script to refresh(reincarnate) bridges automatically to generate new connection information that is yet to be blocked. The new list of bridges will be then supplied to the bridge accessibility monitoring probe and distribution methods. When things are working as intended, no human intervention in this process is needed.
Tasks to do:
- [x] Update admin code to receive bridge info update
- [x] validate this process is working as intended
- [x] confirm from irl about testing output is working with irl's automation scriptshelikhooshelikhoohttps://gitlab.torproject.org/tpo/onion-services/onionmine/-/issues/1Benchmark suite2023-06-14T20:17:42ZSilvio RhattoBenchmark suiteCreate a basic benchmarking tool: a log parser that collects `mkp224o` build flags, used filters and statistics.Create a basic benchmarking tool: a log parser that collects `mkp224o` build flags, used filters and statistics.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/62Only include locales that have been over 90% translated2023-02-27T07:28:18ZCecylia BocovichOnly include locales that have been over 90% translatedAs a follow up to the discussion in #61, there were recent changes to how translations are handled in https://gitlab.torproject.org/tpo/translation. We no longer have access to a `_completed` branch, and this repo is now full of partial ...As a follow up to the discussion in #61, there were recent changes to how translations are handled in https://gitlab.torproject.org/tpo/translation. We no longer have access to a `_completed` branch, and this repo is now full of partial or unstarted translations.
Let's only copy over the folders for locales that are over 90% translated.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40249Upstreaming Remove HelloVerify countermeasure2023-03-03T11:45:36ZshelikhooUpstreaming Remove HelloVerify countermeasureWe have already released a version of snowflake with [Remove HelloVerify](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/134) [Orig](https://gitlab.torproject.org/tpo/anti-censorship/plu...We have already released a version of snowflake with [Remove HelloVerify](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/134) [Orig](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/131) countermeasure against Russia's censorship of snowflake. However, as we are currently applying the changes as a series of patch in the forked repo, this situation isn't ideal if that means we need to constantly rebase and maintain this fork.
Thus, we are currently seeking to upstream this change.
Changes to be upstreamed:
1. [DTLS](https://github.com/xiaokangwang/dtls/tree/dev-skiphelloverify) -> [Github Pull Request](https://github.com/pion/dtls/pull/513)
2. [WebRTC](https://github.com/xiaokangwang/webrtc/tree/dev-skiphelloverify) -> [Github Pull Request](https://github.com/pion/webrtc/pull/2407)
See Also: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_requests/637shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40024Blocking of Snowflake in Turkmenistan, 2021-10-242024-02-26T15:39:12ZDavid Fifielddcf@torproject.orgBlocking of Snowflake in Turkmenistan, 2021-10-24On 2021-10-24, the number of Snowflake users in Turkmenistan dropped from 20–30 to almost zero:
[![userstats-bridge-combined-tm-2021-08-01-2021-12-16](/uploads/72fa4c798ac397813e2865642b90a7a6/userstats-bridge-combined-tm-2021-08-01-202...On 2021-10-24, the number of Snowflake users in Turkmenistan dropped from 20–30 to almost zero:
[![userstats-bridge-combined-tm-2021-08-01-2021-12-16](/uploads/72fa4c798ac397813e2865642b90a7a6/userstats-bridge-combined-tm-2021-08-01-2021-12-16.png)](https://metrics.torproject.org/userstats-bridge-combined.html?start=2021-08-01&end=2021-12-16&country=tm)
Previously discussed at:
* https://gitlab.torproject.org/tpo/community/support/-/issues/40030#note_2759213
* http://meetbot.debian.net/tor-meeting/2021/tor-meeting.2021-11-04-15.59.log.html#l-55
```
16:19:56 <anadahz> Confused about the meek client metrics in Turkmenistan -- https://metrics.torproject.org/userstats-bridge-combined.png?start=2021-08-02&end=2021-11-04&country=tm
16:20:39 <anadahz> How come and there are so many meek clients in Turkmenistan?
16:20:54 <dcf1> Here is a graph with some more context
16:20:56 <dcf1> https://people.torproject.org/~dcf/metrics-country.html?start=2021-08-01&end=2021-11-05&country=tm
16:21:00 <meskio> does it look like related to snowflake going down?
16:21:13 <dcf1> however zoom out a bit to get even *more* context (esp. wrt relay users)
16:21:15 <dcf1> https://people.torproject.org/~dcf/metrics-country.html?start=2021-07-01&end=2021-11-05&country=tm
16:21:23 <cohosh> related info on tor blocking in TM: https://gitlab.torproject.org/tpo/community/support/-/issues/40030
16:22:10 <dcf1> to me it looks like OR and meek were rising simultaneously, then snowflake and OR got blocked.
16:22:33 <cohosh> wow
16:22:49 <meskio> blocked? or our failure with probetest?
16:23:45 <dcf1> but snowflake users globally did not go to zero in the same way https://metrics.torproject.org/userstats-bridge-transport.html?start=2021-08-06&end=2021-11-04&transport=snowflake
16:24:05 <anadahz> On 2021-10-31 the amount of meek clients count were almost spike to 1,5 times than before.
16:24:05 <meskio> I see what you mean :(
16:24:09 <cohosh> yeah this looks suspiciously close to zero
```shelikhooshelikhoo