The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-03-16T08:54:25Zhttps://gitlab.torproject.org/tpo/network-health/team/-/issues/285Set bwscanner_cc to 22023-03-16T08:54:25ZGeorg KoppenSet bwscanner_cc to 2For the sbws optimizations to take effect we need to set `bwscanner_cc=2` in our consensus parameters. /cc @jugaFor the sbws optimizations to take effect we need to set `bwscanner_cc=2` in our consensus parameters. /cc @jugaSponsor 61 - Making the Tor network faster & more reliable for users in Internet-repressive placesGeorg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40769Add end-to-end onionservice measurements to oniontrace2023-03-16T10:59:50Zgabi-250Add end-to-end onionservice measurements to oniontraceIn addition to the `onionservice Circuit Build Time (s)` plot, it might be useful to also have a measurement for the end-to-end HS client to HS service connection duration (for example, we could have something similar to [this](https://m...In addition to the `onionservice Circuit Build Time (s)` plot, it might be useful to also have a measurement for the end-to-end HS client to HS service connection duration (for example, we could have something similar to [this](https://metrics.torproject.org/torperf.html?start=2023-02-01&end=2023-03-09&server=onion&filesize=50kb), where we measure download times).
This might require some changes in oniontrace.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41058Hide `currentBridges` description when the section itself is hidden2023-03-16T14:50:11ZdonutsHide `currentBridges` description when the section itself is hiddenThe `torPreferences-currentBridges-description` string is currently visible even when the "Your Current Bridges" section is hidden:
![bridges-section-hidden](/uploads/18e4336bb46598599876da689f7ef574/bridges-section-hidden.png)
When th...The `torPreferences-currentBridges-description` string is currently visible even when the "Your Current Bridges" section is hidden:
![bridges-section-hidden](/uploads/18e4336bb46598599876da689f7ef574/bridges-section-hidden.png)
When the section is enabled however, it does appear in its proper place:
![bridges-section-visible](/uploads/852664254f3c206e77d4158fe50ebeb0/bridges-section-visible.png)
Can we hide this string when the section itself is not present please? I'm not sure if this is a bug or is intentional, but "too much text" was a point of feedback we received in user testing with prior designs of this page, and I'd prefer to progressively reveal this string instead to break it up a little.
Thanks!Sponsor 30 - Objective 3.5Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40151Figure out why destinations get disabled after deploying #401502023-03-16T16:44:51ZjugaFigure out why destinations get disabled after deploying #40150After deploying #40150 in longclaw's bwauth, it disabled the web servers after 4 days.
We don't know whether there's still some bug in sbws, tor CC or it's due waiting for SS=0.
To try to figure out, we've deployed #40150 with 2 thread...After deploying #40150 in longclaw's bwauth, it disabled the web servers after 4 days.
We don't know whether there's still some bug in sbws, tor CC or it's due waiting for SS=0.
To try to figure out, we've deployed #40150 with 2 threads instead of 3 and we're also going to try to measure the uploads without waiting for SS=0 to arrive.sbws: 1.6.x-finaljugajugahttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40265Standalone proxy - error polling probe - 'certificate is not standards compli...2023-03-16T17:40:24ZMarkCStandalone proxy - error polling probe - 'certificate is not standards compliant'@meskio As requested.
Yesterday I updated one of my proxies after !136 completed. When I run the proxy it starts, then begins probetest, then immediately (and repeatedly) returns an error:
2023/03/16 00:45:47 error polling probe: x509:...@meskio As requested.
Yesterday I updated one of my proxies after !136 completed. When I run the proxy it starts, then begins probetest, then immediately (and repeatedly) returns an error:
2023/03/16 00:45:47 error polling probe: x509: “snowflake-broker.torproject.net” certificate is not standards compliant
2023/03/16 00:45:47 NAT type: unknown
2023/03/16 00:45:48 error polling broker: x509: “snowflake-broker.torproject.net” certificate is not standards compliant
2023/03/16 00:45:48 Error reading broker response: unexpected end of JSON input
2023/03/16 00:45:48 body:
2023/03/16 00:45:48 bad offer from broker
Here’s the log of the start up (note that the git pull in this sequence says 'already up to date' because I ran it a second time as a double check).
[proxy_error_polling_broker_-_03_15_23.txt](/uploads/e8d343dc26e784d66e59880530374774/proxy_error_polling_broker_-_03_15_23.txt)
On the previous build everything was functioning properly.
@itchyonion Might this result be caused by the bug you mentioned in #40108 yesterday?itchyonionitchyonionhttps://gitlab.torproject.org/tpo/network-health/tor-weather/-/issues/29tor-weather crashes on start when creating database schema2023-03-16T18:47:59ZKeztor-weather crashes on start when creating database schemastarting the tor-weather service creates the database schema, but then tor-weather immediately crashes with an exception related to creating the schema. i assume each of the gunicorn workers (there's 5 right now) tries to create the data...starting the tor-weather service creates the database schema, but then tor-weather immediately crashes with an exception related to creating the schema. i assume each of the gunicorn workers (there's 5 right now) tries to create the database schema, and only the first one succeeds because of the lack of `IF NOT EXISTS` in the sql command.
```
Mar 14 16:50:20 weather-01 poetry[2234087]: [2023-03-14 16:50:20 +0000] [2234087] [INFO] Worker exiting (pid: 2234087)
Mar 14 16:50:20 weather-01 poetry[2234085]: [2023-03-14 16:50:20 +0000] [2234085] [ERROR] Exception in worker process
Mar 14 16:50:20 weather-01 poetry[2234085]: Traceback (most recent call last):
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/sqlalchemy/engine/base.py", line 1964, in _exec_single_context
Mar 14 16:50:20 weather-01 poetry[2234085]: self.dialect.do_execute(
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/sqlalchemy/engine/default.py", line 747, in do_execute
Mar 14 16:50:20 weather-01 poetry[2234085]: cursor.execute(statement, parameters)
Mar 14 16:50:20 weather-01 poetry[2234085]: psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "pg_type_typname_nsp_index"
Mar 14 16:50:20 weather-01 poetry[2234085]: DETAIL: Key (typname, typnamespace)=(admin_id_seq, 2200) already exists.
Mar 14 16:50:20 weather-01 poetry[2234085]: The above exception was the direct cause of the following exception:
Mar 14 16:50:20 weather-01 poetry[2234085]: Traceback (most recent call last):
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/gunicorn/arbiter.py", line 589, in spawn_worker
Mar 14 16:50:20 weather-01 poetry[2234085]: worker.init_process()
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/gunicorn/workers/base.py", line 134, in init_process
Mar 14 16:50:20 weather-01 poetry[2234085]: self.load_wsgi()
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/gunicorn/workers/base.py", line 146, in load_wsgi
Mar 14 16:50:20 weather-01 poetry[2234085]: self.wsgi = self.app.wsgi()
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/gunicorn/app/base.py", line 67, in wsgi
Mar 14 16:50:20 weather-01 poetry[2234085]: self.callable = self.load()
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/gunicorn/app/wsgiapp.py", line 58, in load
Mar 14 16:50:20 weather-01 poetry[2234085]: return self.load_wsgiapp()
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/gunicorn/app/wsgiapp.py", line 48, in load_wsgiapp
Mar 14 16:50:20 weather-01 poetry[2234085]: return util.import_app(self.app_uri)
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/gunicorn/util.py", line 359, in import_app
Mar 14 16:50:20 weather-01 poetry[2234085]: mod = importlib.import_module(module)
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
Mar 14 16:50:20 weather-01 poetry[2234085]: return _bootstrap._gcd_import(name[level:], package, level)
Mar 14 16:50:20 weather-01 poetry[2234085]: File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
Mar 14 16:50:20 weather-01 poetry[2234085]: File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
Mar 14 16:50:20 weather-01 poetry[2234085]: File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
Mar 14 16:50:20 weather-01 poetry[2234085]: File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
Mar 14 16:50:20 weather-01 poetry[2234085]: File "<frozen importlib._bootstrap_external>", line 790, in exec_module
Mar 14 16:50:20 weather-01 poetry[2234085]: File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/tor-weather/tor_weather/app.py", line 5, in <module>
Mar 14 16:50:20 weather-01 poetry[2234085]: app: Flask = create_app()
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/tor-weather/tor_weather/__init__.py", line 32, in create_app
Mar 14 16:50:20 weather-01 poetry[2234085]: configure_database(app)
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/tor-weather/tor_weather/__init__.py", line 106, in configure_database
Mar 14 16:50:20 weather-01 poetry[2234085]: db.create_all()
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/flask_sqlalchemy/extension.py", line 868, in create_all
Mar 14 16:50:20 weather-01 poetry[2234085]: self._call_for_binds(bind_key, "create_all")
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/flask_sqlalchemy/extension.py", line 849, in _call_for_binds
Mar 14 16:50:20 weather-01 poetry[2234085]: getattr(metadata, op_name)(bind=engine)
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/sqlalchemy/sql/schema.py", line 5558, in create_all
Mar 14 16:50:20 weather-01 poetry[2234085]: bind._run_ddl_visitor(
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/sqlalchemy/engine/base.py", line 3220, in _run_ddl_visitor
Mar 14 16:50:20 weather-01 poetry[2234085]: conn._run_ddl_visitor(visitorcallable, element, **kwargs)
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/sqlalchemy/engine/base.py", line 2427, in _run_ddl_visitor
Mar 14 16:50:20 weather-01 poetry[2234085]: visitorcallable(self.dialect, self, **kwargs).traverse_single(element)
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/sqlalchemy/sql/visitors.py", line 677, in traverse_single
Mar 14 16:50:20 weather-01 poetry[2234085]: return meth(obj, **kw)
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/sqlalchemy/sql/ddl.py", line 928, in visit_metadata
Mar 14 16:50:20 weather-01 poetry[2234085]: self.traverse_single(
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/sqlalchemy/sql/visitors.py", line 677, in traverse_single
Mar 14 16:50:20 weather-01 poetry[2234085]: return meth(obj, **kw)
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/sqlalchemy/sql/ddl.py", line 962, in visit_table
Mar 14 16:50:20 weather-01 poetry[2234085]: CreateTable(
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/sqlalchemy/sql/ddl.py", line 321, in _invoke_with
Mar 14 16:50:20 weather-01 poetry[2234085]: return bind.execute(self)
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/sqlalchemy/engine/base.py", line 1414, in execute
Mar 14 16:50:20 weather-01 poetry[2234085]: return meth(
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/sqlalchemy/sql/ddl.py", line 185, in _execute_on_connection
Mar 14 16:50:20 weather-01 poetry[2234085]: return connection._execute_ddl(
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/sqlalchemy/engine/base.py", line 1526, in _execute_ddl
Mar 14 16:50:20 weather-01 poetry[2234085]: ret = self._execute_context(
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/sqlalchemy/engine/base.py", line 1842, in _execute_context
Mar 14 16:50:20 weather-01 poetry[2234085]: return self._exec_single_context(
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/sqlalchemy/engine/base.py", line 1983, in _exec_single_context
Mar 14 16:50:20 weather-01 poetry[2234085]: self._handle_dbapi_exception(
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/sqlalchemy/engine/base.py", line 2325, in _handle_dbapi_exception
Mar 14 16:50:20 weather-01 poetry[2234085]: raise sqlalchemy_exception.with_traceback(exc_info[2]) from e
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/sqlalchemy/engine/base.py", line 1964, in _exec_single_context
Mar 14 16:50:20 weather-01 poetry[2234085]: self.dialect.do_execute(
Mar 14 16:50:20 weather-01 poetry[2234085]: File "/home/weather/.cache/pypoetry/virtualenvs/tor-weather-57YGnyhM-py3.9/lib/python3.9/site-packages/sqlalchemy/engine/default.py", line 747, in do_execute
Mar 14 16:50:20 weather-01 poetry[2234085]: cursor.execute(statement, parameters)
Mar 14 16:50:20 weather-01 poetry[2234085]: sqlalchemy.exc.IntegrityError: (psycopg2.errors.UniqueViolation) duplicate key value violates unique constraint "pg_type_typname_nsp_index"
Mar 14 16:50:20 weather-01 poetry[2234085]: DETAIL: Key (typname, typnamespace)=(admin_id_seq, 2200) already exists.
Mar 14 16:50:20 weather-01 poetry[2234085]: [SQL:
Mar 14 16:50:20 weather-01 poetry[2234085]: CREATE TABLE admin (
Mar 14 16:50:20 weather-01 poetry[2234085]: id SERIAL NOT NULL,
Mar 14 16:50:20 weather-01 poetry[2234085]: email VARCHAR(64) NOT NULL,
Mar 14 16:50:20 weather-01 poetry[2234085]: created_on TIMESTAMP WITHOUT TIME ZONE NOT NULL,
Mar 14 16:50:20 weather-01 poetry[2234085]: last_login TIMESTAMP WITHOUT TIME ZONE,
Mar 14 16:50:20 weather-01 poetry[2234085]: PRIMARY KEY (id)
Mar 14 16:50:20 weather-01 poetry[2234085]: )
Mar 14 16:50:20 weather-01 poetry[2234085]: ]
Mar 14 16:50:20 weather-01 poetry[2234085]: (Background on this error at: https://sqlalche.me/e/20/gkpj)
Mar 14 16:50:20 weather-01 poetry[2234085]: [2023-03-14 16:50:20 +0000] [2234085] [INFO] Worker exiting (pid: 2234085)
Mar 14 16:50:20 weather-01 poetry[2234086]: [2023-03-14 16:50:20 +0000] [2234086] [INFO] Worker exiting (pid: 2234086)
Mar 14 16:50:20 weather-01 poetry[2234088]: [2023-03-14 16:50:20 +0000] [2234088] [INFO] Worker exiting (pid: 2234088)
Mar 14 16:50:20 weather-01 poetry[2234089]: [2023-03-14 16:50:20 +0000] [2234089] [INFO] Worker exiting (pid: 2234089)
Mar 14 16:50:20 weather-01 poetry[2234082]: [2023-03-14 16:50:20 +0000] [2234082] [WARNING] Worker with pid 2234087 was terminated due to signal 15
Mar 14 16:50:20 weather-01 poetry[2234082]: [2023-03-14 16:50:20 +0000] [2234082] [INFO] Shutting down: Master
Mar 14 16:50:20 weather-01 poetry[2234082]: [2023-03-14 16:50:20 +0000] [2234082] [INFO] Reason: Worker failed to boot.
Mar 14 16:50:20 weather-01 systemd[1]: tor-weather.service: Main process exited, code=exited, status=3/NOTIMPLEMENTED
Mar 14 16:50:20 weather-01 systemd[1]: tor-weather.service: Failed with result 'exit-code'.
Mar 14 16:50:20 weather-01 systemd[1]: tor-weather.service: Consumed 2.815s CPU time.
```Sarthik Guptasarthikg@icloud.comSarthik Guptasarthikg@icloud.comhttps://gitlab.torproject.org/tpo/web/newsletter/-/issues/34Add March 2023 newsletter to newsletter.torproject.org2023-03-16T19:02:51Zal smithAdd March 2023 newsletter to newsletter.torproject.orgHi @lavamind or @kez, can you help me by adding the latest newsletter to the site, following the practice of previous editions? (Usually Gus helps me but he's not available this week).
Files:
[03.2023_newsletter_-_html.txt](/uploads/93...Hi @lavamind or @kez, can you help me by adding the latest newsletter to the site, following the practice of previous editions? (Usually Gus helps me but he's not available this week).
Files:
[03.2023_newsletter_-_html.txt](/uploads/93e061f216bb57b94003cb4fb570f928/03.2023_newsletter_-_html.txt)
[03.2023_newsletter_-_plain_text.txt](/uploads/baab1449721123bc3e810d5fe616ff25/03.2023_newsletter_-_plain_text.txt)
Subject: Tor News | Status of the Tor network, Tor user support on WhatsApp, welcome new board membershttps://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/140Proxy rdsys requests to bridgestrap and answer combining bridgestrap response...2023-03-17T10:42:55ZjugaProxy rdsys requests to bridgestrap and answer combining bridgestrap response and bridge scanner ratioThis depends on what we decide at https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/150.This depends on what we decide at https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/150.jugajugahttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40122Check whether any bwauth is contributing to more than the 50% of the consensu...2023-03-17T11:43:48ZjugaCheck whether any bwauth is contributing to more than the 50% of the consensus weight after implementing #40022As commented at https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40119#note_2773618, once it is implemented, it should not be the case that the bwauth latency depends so much on being close to fast exits.As commented at https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40119#note_2773618, once it is implemented, it should not be the case that the bwauth latency depends so much on being close to fast exits.sbws: 1.6.x-finalhttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40119gabelmoo's sbws weight sum is greater than the 50% of the consensus2023-03-17T11:43:50Zjugagabelmoo's sbws weight sum is greater than the 50% of the consensusAs explained at #40115 gabelmoo's sbws is reporting this warning.
```
It looks like gabelmoo's had always greatest consensus weight sum (see for instance the total consensus weight graph back in 2018 when the log was created: https://met...As explained at #40115 gabelmoo's sbws is reporting this warning.
```
It looks like gabelmoo's had always greatest consensus weight sum (see for instance the total consensus weight graph back in 2018 when the log was created: https://metrics.torproject.org/totalcw.png?start=2018-10-01&end=2018-10-31), what it probably due gabelmoo's location (Germany). What i'm not sure is whether it was as much as the 50% before because relays were getting stuck in bandwidth partitions with torflow or we just didn't notice cause torflow wasn't logging that.
```
This issue is to investigate why this is happening.sbws: 1.3.x-finaljugajugahttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40021Use network overload information to stop inflating/decrease relay weight2023-03-17T11:44:34ZMike PerryUse network overload information to stop inflating/decrease relay weightOnce https://gitlab.torproject.org/tpo/core/tor/-/issues/40158 is spec'ed and deployed, sbws should inspect relay descriptors for that overload info and either stop adding weight, or decrease the weights of such relays that are overloaded.Once https://gitlab.torproject.org/tpo/core/tor/-/issues/40158 is spec'ed and deployed, sbws should inspect relay descriptors for that overload info and either stop adding weight, or decrease the weights of such relays that are overloaded.jugajugahttps://gitlab.torproject.org/tpo/core/tor/-/issues/40158Specify overload relay descriptors for load balancing and network health2023-03-17T11:44:35ZMike PerrySpecify overload relay descriptors for load balancing and network healthWe need to specify descriptor fields to signify when relays:
1. [ ] Are at or near CPU overload
2. [ ] Are at or near OOM killer invocation
3. [ ] Are at or near connection count limits
4. [ ] At or near their token bucket limit
5. [ ] ...We need to specify descriptor fields to signify when relays:
1. [ ] Are at or near CPU overload
2. [ ] Are at or near OOM killer invocation
3. [ ] Are at or near connection count limits
4. [ ] At or near their token bucket limit
5. [ ] Accumulating too many cells in queues (circuitmux, tls outbuf, aes)
6. [ ] Are failing too many onionskins, tls handshakes, other things?
7. [ ] Flag/checks to signify which relays are on the same machine
The specification should only emit enough information to determine if relays are at or near various forms of overload. They should *not* report detailed statistics, as these may aid in DoS attacks and traffic analysis.
With this information, we will use sbws to avoid allocating extra load to these relays, as well as use these fields to report unhealthy relays on the metrics portal, and investigate other misbehavior.
I can work on this spec but I will need much input from @dgoulet.Sponsor 61 - Making the Tor network faster & more reliable for users in Internet-repressive placesDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40153State file corrupted after full disk2023-03-17T11:49:55ZSebastian HahnState file corrupted after full diskIt seems that when the disk is full, sbws corrupts its state file (completely truncates it) rather than noticing and not touching it. On subsequent runs of `generate`, sbws chokes on the empty file:
```
Traceback (most recent call last)...It seems that when the disk is full, sbws corrupts its state file (completely truncates it) rather than noticing and not touching it. On subsequent runs of `generate`, sbws chokes on the empty file:
```
Traceback (most recent call last):
File "/usr/bin/sbws", line 33, in <module>
sys.exit(load_entry_point('sbws==1.5.2', 'console_scripts', 'sbws')())
File "/usr/lib/python3/dist-packages/sbws/sbws.py", line 93, in main
exit(comm["f"](*comm["a"], **comm["kw"]))
File "/usr/lib/python3/dist-packages/sbws/core/generate.py", line 174, in main
bw_file = V3BWFile.from_results(
File "/usr/lib/python3/dist-packages/sbws/lib/v3bwfile.py", line 1129, in from_results
header = V3BWHeader.from_results(
File "/usr/lib/python3/dist-packages/sbws/lib/v3bwfile.py", line 373, in from_results
generator_started = cls.generator_started_from_file(state_fpath)
File "/usr/lib/python3/dist-packages/sbws/lib/v3bwfile.py", line 485, in generator_started_from_file
state = State(state_fpath)
File "/usr/lib/python3/dist-packages/sbws/util/state.py", line 47, in __init__
self._state = self._read()
File "/usr/lib/python3/dist-packages/sbws/util/state.py", line 54, in _read
return json.load(fd, cls=CustomDecoder)
File "/usr/lib/python3.9/json/__init__.py", line 293, in load
return loads(fp.read(),
File "/usr/lib/python3.9/json/__init__.py", line 359, in loads
return cls(**kw).decode(s)
File "/usr/lib/python3/dist-packages/sbws/util/json.py", line 24, in decode
decoded = super().decode(s, **kwargs)
File "/usr/lib/python3.9/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python3.9/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
```
It started working again after I removed the empty state filehttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40142Change initial upload data to be large and cut it off after X bytes, in a sim...2023-03-17T11:52:52ZjugaChange initial upload data to be large and cut it off after X bytes, in a similar way as download size is calculated when downloading.This issue is another optimization (number 6) for congestion control commented at https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40130#note_2823615:
> Note that also 20MB was just my test file value. It is probably better...This issue is another optimization (number 6) for congestion control commented at https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40130#note_2823615:
> Note that also 20MB was just my test file value. It is probably better to make the POST extremely large (ie: as large as the largest possible sbws download is currently, or larger), and then just have a number of megabytes to cut it off at, after ~~SS=1~~ SS=0. This number of megabytes can be calculated similar to how sbws chooses a file size for GET.sbws: 1.6.x-finaljugajugahttps://gitlab.torproject.org/tpo/web/support/-/issues/321cdr.link add new whatsapp channel2023-03-17T18:23:58ZGuscdr.link add new whatsapp channelCDR/Link staff just created a WhatsApp support channel for us: https://wa.me/447421000612.
Let's include it on the relevant user support pages.
Checklist:
- [x] Tor Browser User Manual
- [x] Support Portal
- [x] Onion Launchpad (thank...CDR/Link staff just created a WhatsApp support channel for us: https://wa.me/447421000612.
Let's include it on the relevant user support pages.
Checklist:
- [x] Tor Browser User Manual
- [x] Support Portal
- [x] Onion Launchpad (thanks, @raya)
- [x] RT template for Russian users (thanks, @nina)
- [x] RT template for Iran users
- [x] Forum post "Iran: Circumventing Censorship with Tor"
- [x] Forum post "Tor blocked in Russia: how to circumvent censorship"GusGushttps://gitlab.torproject.org/tpo/web/donate-static/-/issues/45donate-static vanilla js rewrite2023-03-17T21:24:29ZKezdonate-static vanilla js rewriteThis is a ticket that should've been written around a month ago, but I didn't think to do it then, so I'm writing it now!
The [donate.tpo frontend](https://gitlab.torproject.org/tpo/web/donate-static) is currently written in a mix of re...This is a ticket that should've been written around a month ago, but I didn't think to do it then, so I'm writing it now!
The [donate.tpo frontend](https://gitlab.torproject.org/tpo/web/donate-static) is currently written in a mix of react and lektor (mostly react). Since nobody at TPI knows react very well, we want to rewrite it in vanilla javascript to make it easier for us to maintain, and hopefully allow us to reuse some of the loogic for the upcoming donate.tpo rewrite (#29).
## Plan
Here are the steps I've taken and plan to take to move to vanilla javascript (in no particular order):
- [x] Move all the JSON configuration from settings.js to lektor databags
- [x] Move the countries.json and regions.json files to lektor databags, re-structured to make working with them a bit more pythonic
- [x] Write a script to regenerate the countries.json/regions.json databags from the existing json files
- [x] Scaffold a new `tor-donate-js/` npm project with [esbuild](https://github.com/evanw/esbuild), [eslint](https://eslint.org), and [jsdoc](https://jsdoc.app/)
- [x] Render the cryptocurrency page statically with lektor, with a small amount of javascript to add an event listener to the anonymous donation checkbox, and copy-to-clipboard support for the wallet addresses (defined in `tor-donate-js/src/cryptocurrency.js`)
- [x] Move as many of the react components as possible to jinja2 macros and statically render them with lektor
- [x] Rewrite the donate-form.html template to use the jinja macros and render the donation form statically
- [x] Rewrite the donate form validation logic, interactivity/reactivity, and submit handlers in a vanilla es6 class (eslint and esbuild are using es2021)
- [x] Event handler reactivity:
- [x] Donation frequency selection buttons
- [x] Donation amount buttons
- [x] Other donation amount text box
- [x] No perk checkbox
- [x] Perk selection tiles
- [x] Donation method selection button
- [x] Credit card fields
- [x] Donation amount label
- [x] Gift selection label
- [x] Form field validation
- [x] Stripe API submit handler
- [x] Paypal API submit handler
- [x] Render Paypal buttons
- [x] Paypal button callback functions
- [x] onApprove
- [x] onCancel
- [x] createBillingAgreement
- ~~[ ] createOrder~~
- [x] Implement the giving form class on the donation pages
- [x] Main donation page (the index page)
- [x] Monthly giving page
- [x] Champions of privacy page
- [x] There are a few TODOs (mostly relating to form validation) that need to be cleaned up
- [x] jsdoc comments on all classes, methods, and top-level functions
- [x] Documentation describing the new JS architecture, with a guide to editing, and the build system/contribution process
- [x] Set up translations/l10n in lektor
- [x] Set up a staging site for my fork
The rewrite is mostly finished. I don't have a timeframe for when it should be complete; Paypal, Stripe, and the reactivity each took a bit longer than I expected. I'm hoping to have this done within the next week or so.
## Motivations for the new build system (esbuild, eslint, jsdoc)
esbuild is a fairly new tool, so I want to explain why I chose that instead of parcel, webpack, or rollup.
The main reason is simplicity. Other bundlers I've used usually require a fiarly complex configuration file, and tend to be slow and come with a lot of dependencies. esbuild is a single native binary with no dependencies, and works with a simple cli configuration.
jsdoc was added because the main issue I had with the react site was the complexity and lack of documentation. eslint is used for linting, and also to enforce jsdoc comments.Redesign donate.torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41099update my openpgp key in db.torproject.org2023-03-17T21:49:39Zmeskiomeskio@torproject.orgupdate my openpgp key in db.torproject.orgMy key in db.torproject.org will expire in few weeks. I have extended the expiration date of the same [key](/uploads/5f50d24059168a4f76e6c3c878016faa/meskio.asc). Can you update it there?
Thank you.My key in db.torproject.org will expire in few weeks. I have extended the expiration date of the same [key](/uploads/5f50d24059168a4f76e6c3c878016faa/meskio.asc). Can you update it there?
Thank you.https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/135consider not giving out the moat SR2 bridges on telegram2023-03-19T12:44:18ZRoger Dingledineconsider not giving out the moat SR2 bridges on telegramOur analysis conclusions from last week's work with @shelikhoo include:
* Around 45 of irl's dynamic bridges say "bridge-distribution-request moat" in their descriptor, and around 10 of them say "bridge-distribution-request none" in the...Our analysis conclusions from last week's work with @shelikhoo include:
* Around 45 of irl's dynamic bridges say "bridge-distribution-request moat" in their descriptor, and around 10 of them say "bridge-distribution-request none" in their descriptor.
* I hear that rdsys is giving out all 55ish of them via telegram+new. That is, the moat ones are given out via both moat and telegram+new, and the none ones are given out via telegram+new.
* The moat ones are getting blocked in China because they're enumerating moat. The none ones continue to work in China.
* All of the bridges are working fine in Turkey / Russia.
So if the above is right, that means some of the bridges we're giving out via telegram are already blocked because they had been given out via moat too.
So: giving out all 55 via telegram is optimal in every country but China, but giving out only the 10 via telegram is optimal for China.
Do we know whether the telegram+new channel is getting any use in China? If yes, we can make it work better by not including the moat ones in the pool of telegram+new responses.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetirlirlhttps://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/logcollector-admin/-/issues/7Keep irl's dynamic bridges around for a few days after rotation2023-03-19T12:46:16ZRoger DingledineKeep irl's dynamic bridges around for a few days after rotationRight now as I understand it, the moment we get a "blocked!" result out of bridgestatus in any country, we tell irl's dynamic bridge farm that it's time to rotate that bridge.
This is good from an overall reachability perspective, becau...Right now as I understand it, the moment we get a "blocked!" result out of bridgestatus in any country, we tell irl's dynamic bridge farm that it's time to rotate that bridge.
This is good from an overall reachability perspective, because any waiting, if we're right and the bridge got blocked, is bad for users.
But also, by spinning the old bridge down right then, we lose out on a lot of potential understanding:
* How often are these 'blocked' events false positives? That is, how often do we rotate away from a bridge when actually it was just a brief connectivity issue or a slow bootstrap? These are cases that we are labeling "blocked" in our data yet we don't know how much we're overcounting the blocked cases.
* By rotating the bridge immediately, we make it hard to figure out what happened in other countries. We have what look like a bunch of false positives in Turkey and Russia in the https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/92 analysis, where we get one connection failure from Turkey but it works from other countries, and then the next day the bridge is down, because we intentionally took it down after that first 'blocked' case.
This approach of taking the bridge down after the first failure prevents us from using a more nuanced definition of blocked such as "down three days in a row in this country while still reachable from some other countries during that time".
So my proposed fix is to change irl's dynamic bridge framework to schedule a spin-down of the old bridge for N (e.g. N=3) days in the future. We can still spin up the new one right then, pass the bridge lines back, etc just as we do now.
This way we get a view into the future -- of how that bridge works from each of our countries after the initial potential blocking event.
One downside is that irl might be running more total VM's than he originally expected, for the overlap period. This one seems solvable though.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetirlirlhttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/40Verify WebRTC local IP leaks are no longer occurring in Firefox2023-03-20T13:57:59ZrichardVerify WebRTC local IP leaks are no longer occurring in Firefoxruihildtruihildt