The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-01-24T10:17:10Zhttps://gitlab.torproject.org/tpo/network-health/metrics/metrics-sql-tables/-/issues/9Add `exit_policy_summary` and `exit_policy_v6_summary` entries to `server_sta...2024-01-24T10:17:10ZGeorg KoppenAdd `exit_policy_summary` and `exit_policy_v6_summary` entries to `server_status` tableFor our server status and our NetworkStatus API we miss `exit_policy_summary` and `exit_policy_v6_summary`.For our server status and our NetworkStatus API we miss `exit_policy_summary` and `exit_policy_v6_summary`.https://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/78Assemble `exit_policy_summary` and `exit_policy_v6_summary` in router status ...2024-01-24T10:17:09ZGeorg KoppenAssemble `exit_policy_summary` and `exit_policy_v6_summary` in router status if availableRequires https://gitlab.torproject.org/tpo/network-health/metrics/metrics-sql-tables/-/issues/9.Requires https://gitlab.torproject.org/tpo/network-health/metrics/metrics-sql-tables/-/issues/9.https://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/76extra_info_descriptor table default or wrong values2024-01-24T10:15:16Zjugaextra_info_descriptor table default or wrong valuesWorking on tpo/network-health/team#313, i thought to include whether a relay is overloaded in the grafana panels, so i tried this query:
```
select overload_ratelimits_version, overload_ratelimits_timestamp, overload_ratelimits_ratelimit...Working on tpo/network-health/team#313, i thought to include whether a relay is overloaded in the grafana panels, so i tried this query:
```
select overload_ratelimits_version, overload_ratelimits_timestamp, overload_ratelimits_ratelimit, overload_ratelimits_burstlimit , overload_ratelimits_read_count, overload_ratelimits_write_count, overload_fd_exhausted_version, overload_fd_exhausted_timestamp
from extra_info_descriptor
where fingerprint='0E13738FADDE15FC896E7CDB998C694F89F4E4B2';
```
which returns many rows as:
```
overload_ratelimits_version | overload_ratelimits_timestamp | overload_ratelimits_ratelimit | overload_ratelimits_burstlimit | overload_ratelimits_read_count | overload_ratelimits_write_count | overload_fd_exhausted_version | overload_fd_exhausted_timestamp
-----------------------------+-------------------------------+-------------------------------+--------------------------------+--------------------------------+---------------------------------+-------------------------------+---------------------------------
0 | 1969-12-31 23:59:59.999 | -1 | -1 | -1 | -1 | 0 | 1969-12-31 23:59:59.999
```
Maybe we could allow all these values to be NULL if the relay isn't overloaded?
I then tried to filter overload_ratelimits_read_count and overload_ratelimits_write_count without `-1` values and had to treat them as strings for that:
```
select count (*)
from extra_info_descriptor
where overload_ratelimits_write_count!='-1' and overload_ratelimits_read_count!='-1';
count
--------
169536
```
So maybe there's a bug here?
Maybe this was introduced by #47 (which i reviewed, ahem ;))
On a different issue, i think it'd be very helpful to add a VictoriaMetric metric to know whether a relay is overloaded.https://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/77Assemble `dir_address` in a router status if available2024-01-24T09:53:03ZGeorg KoppenAssemble `dir_address` in a router status if availableRequires https://gitlab.torproject.org/tpo/network-health/metrics/metrics-sql-tables/-/issues/8.Requires https://gitlab.torproject.org/tpo/network-health/metrics/metrics-sql-tables/-/issues/8.https://gitlab.torproject.org/tpo/core/arti/-/issues/1167Implement a new revision-counter algorithm2024-01-23T17:22:20Zgabi-250Implement a new revision-counter algorithmIf we decide the answer to #1166 is that we should indeed continue including the next TP in the secondary ring, then this [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1828#note_2976777) will need to be addres...If we decide the answer to #1166 is that we should indeed continue including the next TP in the secondary ring, then this [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1828#note_2976777) will need to be addressed.
@nickm suggests
```
Okay. What's the right way for us to avoid that? I see a few options:
Just don't upload before the start of the time period.
Adjust our zero so that it is the start of the previous time period (or something like that), and increment the other values accordingly. We might need to increase the maximum on our OPE.
Kludge our OPE so that we can encrypt -N through 0 and usually get results in the same area as our C code.
Option 1 would presumably make us less reliable. (How far in advance do we upload, though? And are we right to do so?)
Option 2 would make our OPE less compatible with the C OPE. I think that's okay, though.
Option 3 would take some design, but I think I could figure something out.
```Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/1252OnionServicePrefs2024-01-23T16:54:08Zgabi-250OnionServicePrefsThe following discussion from !1887 should be addressed:
- [ ] @nickm started a [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1887#note_2984621): (+5 comments)
> Here's a thought. What would you think ...The following discussion from !1887 should be addressed:
- [ ] @nickm started a [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1887#note_2984621): (+5 comments)
> Here's a thought. What would you think about adding a new `prefs` argument to OnionService here? It could, for example, include information about whether we should construct the keys if they are not already found.Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/1213ipt manager should have more unit tests2024-01-23T15:59:20ZIan Jacksoniwj@torproject.orgipt manager should have more unit testsThere are some unit tests but they don't test all the exciting things that can happen. See the TODOs in the codebase tagged with this ticket.There are some unit tests but they don't test all the exciting things that can happen. See the TODOs in the codebase tagged with this ticket.Arti: Onion service supportIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/network-health/metrics/metrics-sql-tables/-/issues/8Add a `dir_address` column for `server_status` table2024-01-23T12:30:30ZGeorg KoppenAdd a `dir_address` column for `server_status` table`dir_port`s are still a thing, e.g. for directory authorities: `"DirPort" is its current directory port, or "0" for "none".`. Thus, we should add a `dir_address` column to our `server_status` table, so that we can provide the same output...`dir_port`s are still a thing, e.g. for directory authorities: `"DirPort" is its current directory port, or "0" for "none".`. Thus, we should add a `dir_address` column to our `server_status` table, so that we can provide the same output as Onionoo currently does. Either an IP address + port or it's omitted.https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/39Make lox-distributor listening port configurable2024-01-22T15:15:35ZCecylia BocovichMake lox-distributor listening port configurableRight now we have the lox distributor [hard-coded to listen on port 8001](https://gitlab.torproject.org/tpo/anti-censorship/lox/-/blob/main/crates/lox-distributor/src/main.rs?ref_type=heads#L351). We should make this configurable.Right now we have the lox distributor [hard-coded to listen on port 8001](https://gitlab.torproject.org/tpo/anti-censorship/lox/-/blob/main/crates/lox-distributor/src/main.rs?ref_type=heads#L351). We should make this configurable.https://gitlab.torproject.org/tpo/tpa/team/-/issues/31957automate upgrades2024-01-19T19:44:51Zanarcatautomate upgradesupgrades take up a significant chunk of time every week and distract sysadmins (or at least me) from focusing on other projects.
upgrades should be therefore automated, as much as possible.
see also legacy/trac#31239 about auomated ins...upgrades take up a significant chunk of time every week and distract sysadmins (or at least me) from focusing on other projects.
upgrades should be therefore automated, as much as possible.
see also legacy/trac#31239 about auomated installs and this is part of the wider "ops card questionnaire", where we answered no to a question about this, see legacy/trac#30881.
checklist:
* [x] install needrestart everywhere, in interactive mode
* [x] switch needrestart to automatic mode
* [x] install unattended-upgrades everywhere
* [x] fix major upgrades docs to disable unattended-upgrades during the upgrade run
* ~~[ ] automate reboots~~ see legacy/trac#33406 insteadHiroHirohttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41415design and implement backup strategy for MinIO buckets or the entire server2024-01-19T18:57:23Zanarcatdesign and implement backup strategy for MinIO buckets or the entire serverWe're considering using MinIO for more and more things, mainly GitLab (artifacts storage in #41403 and gitaly backups in #40518) but possibly other (e.g. metrics storage in tpo/network-health/metrics/collector#40023).
Right now, we don'...We're considering using MinIO for more and more things, mainly GitLab (artifacts storage in #41403 and gitaly backups in #40518) but possibly other (e.g. metrics storage in tpo/network-health/metrics/collector#40023).
Right now, we don't have any backups of that server, which is probably fine: we only store container images there, which can be regenerated in case of a catastrophe. But if we start storing gitaly backups and gitlab artifacts, it needs to be permanent now.
Research how backups can be performed, develop a policy and implement it.
Next steps:
* [x] research articles anarcat found on the topic (see wallabag)
* [x] discuss the idea in the network
* [x] decide if we want this per bucket or per site
* [ ] write up a proposal
* [ ] implement proposal
* [ ] document and test backup/restore proceduresanarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41482Automate renewal of self-signed LDAP cert2024-01-19T17:07:36ZKezAutomate renewal of self-signed LDAP certIn #41479 I renewed the self-signed LDAP cert for two years (730 days). That means that next time we renew it will be right after the holidays in 2026. It's not too much of a pain since it's only every 2 years, but it would be nice to no...In #41479 I renewed the self-signed LDAP cert for two years (730 days). That means that next time we renew it will be right after the holidays in 2026. It's not too much of a pain since it's only every 2 years, but it would be nice to not have to renew it right after we come back from our holiday break.
We could either automate the procedure entirely, or I could renew it again in a month or so so that the current cert will expire in February 2026. @anarcat any preferences or suggestions?Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42370Missing Tor Browser for Android store icon for F-droid2024-01-19T16:32:55ZclairehurstMissing Tor Browser for Android store icon for F-droid<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
The listing on F-droid doesn't have an icon for Tor Browser for Android for both stable and alpha (see screenshot belo...<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
The listing on F-droid doesn't have an icon for Tor Browser for Android for both stable and alpha (see screenshot below)
### Environment
**Which operating system are you using? For example: Debian GNU/Linux 10.1, Windows 10, Ubuntu Xenial, FreeBSD 12.2, etc.**
**Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.**
F-droid Basic, Calyxos 5.2.0, Android 14, pixel4a
### Relevant logs and/or screenshots
![Screenshot_20240116-122120](/uploads/324de075c1bfb2a67a0f773e03e3e104/Screenshot_20240116-122120.png){width=25%}clairehurstclairehursthttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41219Tor Browser for Android nightly (9/14) does not start: "Cookie Auth file not ...2024-01-18T17:38:54ZGeorg KoppenTor Browser for Android nightly (9/14) does not start: "Cookie Auth file not created"While testing the first nightly on an aarch64 system I did not get very far:
```
09-17 12:05:12.777 29655 29802 I OnionProxyManager: Starting Tor
09-17 12:05:12.778 29655 29802 I OnionProxyManager: Starting process
09-17 12:05:12.790 296...While testing the first nightly on an aarch64 system I did not get very far:
```
09-17 12:05:12.777 29655 29802 I OnionProxyManager: Starting Tor
09-17 12:05:12.778 29655 29802 I OnionProxyManager: Starting process
09-17 12:05:12.790 29655 29802 I OnionProxyManager: Waiting for control port
09-17 12:05:12.812 29655 29821 I OnionProxyManager: Sep 17 12:05:12.804
[notice] Tor 0.4.5.0-alpha-dev (git-1c4b140427aeb36d) running on Linux
with Libevent 2.1.11-stable, OpenSSL 1.1.1g, Zlib 1.2.11, Liblzma N/A,
Libzstd 1.4.4 and Unknown N/A as libc.
09-17 12:05:12.813 29655 29821 I OnionProxyManager: Sep 17 12:05:12.805
[notice] Tor can't help you if you use it wrong! Learn how to be safe at
https://www.torproject.org/download/download#warning
09-17 12:05:12.813 29655 29821 I OnionProxyManager: Sep 17 12:05:12.806
[notice] This version is not a stable Tor release. Expect more bugs than
usual.
09-17 12:05:12.813 29655 29821 I OnionProxyManager: Sep 17 12:05:12.806
[notice] Read configuration file
"/data/user/0/org.torproject.torbrowser_alpha/app_torservice/torrc".
09-17 12:05:12.815 29823 29823 I Tor : Tor 0.4.5.0-alpha-dev
(git-1c4b140427aeb36d) running on Linux with Libevent 2.1.11-stable,
OpenSSL 1.1.1g, Zlib 1.2.11, Liblzma N/A, Libzstd 1.4.4 and Unknown N/A
as libc.
09-17 12:05:12.815 29823 29823 I Tor : Tor 0.4.5.0-alpha-dev
(git-1c4b140427aeb36d) running on Linux with Libevent 2.1.11-stable,
OpenSSL 1.1.1g, Zlib 1.2.11, Liblzma N/A, Libzstd 1.4.4 and Unknown N/A
as libc.
09-17 12:05:12.815 29823 29823 I Tor : Tor can't help you if you use
it wrong! Learn how to be safe at
https://www.torproject.org/download/download#warning
09-17 12:05:12.815 29823 29823 I Tor : Tor can't help you if you use
it wrong! Learn how to be safe at
https://www.torproject.org/download/download#warning
09-17 12:05:12.815 29823 29823 I Tor : This version is not a stable
Tor release. Expect more bugs than usual.
09-17 12:05:12.815 29823 29823 I Tor : This version is not a stable
Tor release. Expect more bugs than usual.
09-17 12:05:12.815 29655 29821 I OnionProxyManager: Sep 17 12:05:12.814
[notice] Opening Control listener on 127.0.0.1:0
09-17 12:05:12.815 29823 29823 I Tor : Read configuration file
"/data/user/0/org.torproject.torbrowser_alpha/app_torservice/torrc".
09-17 12:05:12.815 29823 29823 I Tor : Read configuration file
"/data/user/0/org.torproject.torbrowser_alpha/app_torservice/torrc".
09-17 12:05:12.815 29823 29823 I Tor : Opening Control listener on
127.0.0.1:0
09-17 12:05:12.815 29823 29823 I Tor : Opening Control listener on
127.0.0.1:0
09-17 12:05:12.815 29823 29823 I Tor : Control listener listening on
port 43604.
09-17 12:05:12.815 29655 29821 I OnionProxyManager: Sep 17 12:05:12.814
[notice] Control listener listening on port 43604.
09-17 12:05:12.815 29823 29823 I Tor : Control listener listening on
port 43604.
09-17 12:05:12.815 29823 29823 I Tor : Opened Control listener
connection (ready) on 127.0.0.1:43604
09-17 12:05:12.815 29823 29823 I Tor : Opened Control listener
connection (ready) on 127.0.0.1:43604
09-17 12:05:12.815 29823 29823 I Tor : DisableNetwork is set. Tor
will not make or accept non-control network connections. Shutting down
all existing connections.
09-17 12:05:12.815 29655 29821 I OnionProxyManager: Sep 17 12:05:12.814
[notice] Opened Control listener connection (ready) on 127.0.0.1:43604
09-17 12:05:12.815 29823 29823 I Tor : DisableNetwork is set. Tor
will not make or accept non-control network connections. Shutting down
all existing connections.
09-17 12:05:12.815 29655 29821 I OnionProxyManager: Sep 17 12:05:12.814
[notice] DisableNetwork is set. Tor will not make or accept non-control
network connections. Shutting down all existing connections.
09-17 12:05:12.815 29823 29823 W Tor : Your log may contain
sensitive information - you disabled SafeLogging, and you're logging
more than "notice". Don't log unless it serves an important reason.
Overwrite the log afterwards.
09-17 12:05:12.816 29823 29823 W Tor : Your log may contain
sensitive information - you disabled SafeLogging, and you're logging
more than "notice". Don't log unless it serves an important reason.
Overwrite the log afterwards.
09-17 12:05:12.816 29823 29823 I Tor :
options_commit_listener_transaction: Recomputed OOS thresholds:
ConnLimit 1000, ConnLimit_ 1292, ConnLimit_high_thresh 1228,
ConnLimit_low_thresh 969
09-17 12:05:12.816 29823 29823 I Tor :
options_commit_listener_transaction: Recomputed OOS thresholds:
ConnLimit 1000, ConnLimit_ 1292, ConnLimit_high_thresh 1228,
ConnLimit_low_thresh 969
09-17 12:05:12.816 29823 29823 I Tor : crypto_openssl_late_init: NOT
using OpenSSL engine support.
09-17 12:05:12.816 29823 29823 I Tor : crypto_openssl_late_init: NOT
using OpenSSL engine support.
09-17 12:05:12.816 29823 29823 I Tor : evaluate_evp_for_aes: This
version of OpenSSL has a known-good EVP counter-mode implementation.
Using it.
09-17 12:05:12.816 29823 29823 I Tor : evaluate_evp_for_aes: This
version of OpenSSL has a known-good EVP counter-mode implementation.
Using it.
09-17 12:05:12.816 29823 29823 D Tor : tor_disable_debugger_attach:
Attemping to disable debugger attachment to Tor for unprivileged users.
09-17 12:05:12.816 29823 29823 D Tor : tor_rename: Renaming
/data/user/0/org.torproject.torbrowser_alpha/app_torservice/lib/tor/control.txt.tmp
to
/data/user/0/org.torproject.torbrowser_alpha/app_torservice/lib/tor/control.txt
09-17 12:05:12.817 29823 29823 I Tor : tor_lockfile_lock: Locking
"/data/user/0/org.torproject.torbrowser_alpha/app_torservice/.tor/lock"
09-17 12:05:12.817 29823 29823 I Tor : tor_lockfile_lock: Locking
"/data/user/0/org.torproject.torbrowser_alpha/app_torservice/.tor/lock"
09-17 12:05:12.817 29823 29823 W Tor : It looks like another Tor
process is running with the same data directory. Waiting 5 seconds to
see if it goes away.
09-17 12:05:12.817 29823 29823 W Tor : It looks like another Tor
process is running with the same data directory. Waiting 5 seconds to
see if it goes away.
09-17 12:05:12.817 29655 29802 I OnionProxyManager: Created control port
file: time = 27ms
09-17 12:05:12.821 29655 29802 I OnionProxyManager: Waiting for cookie
auth file
09-17 12:05:17.818 29823 29823 I Tor : tor_lockfile_lock: Locking
"/data/user/0/org.torproject.torbrowser_alpha/app_torservice/.tor/lock"
09-17 12:05:17.818 29823 29823 I Tor : tor_lockfile_lock: Locking
"/data/user/0/org.torproject.torbrowser_alpha/app_torservice/.tor/lock"
09-17 12:05:17.818 29823 29823 E Tor : No, it's still there. Exiting.
09-17 12:05:17.818 29823 29823 E Tor : No, it's still there. Exiting.
09-17 12:05:17.818 29823 29823 E Tor : set_options: Bug: Acting on
config options left us in a broken state. Dying. (on Tor
0.4.5.0-alpha-dev 1c4b140427aeb36d)
09-17 12:05:17.818 29823 29823 E Tor : set_options: Bug: Acting on
config options left us in a broken state. Dying. (on Tor
0.4.5.0-alpha-dev 1c4b140427aeb36d)
09-17 12:05:17.819 29823 29823 E Tor : Reading config failed--see
warnings above.
09-17 12:05:17.819 29823 29823 E Tor : Reading config failed--see
warnings above.
09-17 12:05:17.828 29823 29823 D Tor : channel_tls_free_all:
Shutting down TLS channels...
09-17 12:05:17.828 29823 29823 D Tor : channel_tls_free_all: Done
shutting down TLS channels
09-17 12:05:17.828 29823 29823 D Tor : channel_free_all: Shutting
down channels...
09-17 12:05:17.828 29823 29823 D Tor : channel_free_all: Freeing
channel_identity_map
09-17 12:05:17.828 29823 29823 D Tor : channel_free_all: Freeing
channel_gid_map
09-17 12:05:17.829 29823 29823 D Tor : channel_free_all: Done
cleaning up after channels
09-17 12:05:17.830 29823 29823 D Tor : connection_free_minimal:
closing fd 7.
09-17 12:05:17.830 29823 29823 D Tor : scheduler_free_all: Shutting
down scheduler
09-17 12:05:17.831 29823 29823 D Tor : subsystems_shutdown_downto:
Shutting down dirauth
09-17 12:05:17.832 29823 29823 D Tor : subsystems_shutdown_downto:
Shutting down btrack
09-17 12:05:17.832 29823 29823 D Tor : subsystems_shutdown_downto:
Shutting down relay
09-17 12:05:17.832 29823 29823 D Tor : subsystems_shutdown_downto:
Shutting down or
09-17 12:05:17.832 29823 29823 D Tor : subsystems_shutdown_downto:
Shutting down mainloop
09-17 12:05:17.833 29823 29823 D Tor : subsystems_shutdown_downto:
Shutting down process
09-17 12:05:17.834 29823 29823 D Tor : subsystems_shutdown_downto:
Shutting down evloop
09-17 12:05:17.834 29823 29823 D Tor : subsystems_shutdown_downto:
Shutting down network
09-17 12:05:17.835 29823 29823 D Tor : subsystems_shutdown_downto:
Shutting down crypto
09-17 12:05:17.835 29823 29823 D Tor : subsystems_shutdown_downto:
Shutting down log
09-17 12:05:27.828 29655 29802 E BaseEventBroadcaster: Unable to start
Tor: java.io.IOException: Cookie Auth file not created:
/data/user/0/org.torproject.torbrowser_alpha/app_torservice/lib/tor/control_auth_cookie,
len = 0
09-17 12:05:27.828 29655 29802 E BaseEventBroadcaster:
java.io.IOException: Cookie Auth file not created:
/data/user/0/org.torproject.torbrowser_alpha/app_torservice/lib/tor/control_auth_cookie,
len = 0
09-17 12:05:27.828 29655 29802 E BaseEventBroadcaster: at
com.msopentech.thali.toronionproxy.OnionProxyManager.start(OnionProxyManager.java:47)
09-17 12:05:27.828 29655 29802 E BaseEventBroadcaster: at
com.msopentech.thali.android.toronionproxy.AndroidOnionProxyManager.start(AndroidOnionProxyManager.java:1)
09-17 12:05:27.828 29655 29802 E BaseEventBroadcaster: at
org.torproject.android.service.TorService.startTor(TorService.java:12)
09-17 12:05:27.828 29655 29802 E BaseEventBroadcaster: at
org.torproject.android.service.TorService.access$1000(TorService.java:1)
09-17 12:05:27.828 29655 29802 E BaseEventBroadcaster: at
org.torproject.android.service.TorService$IncomingIntentRouter.run(TorService.java:17)
09-17 12:05:27.828 29655 29802 E BaseEventBroadcaster: at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
09-17 12:05:27.828 29655 29802 E BaseEventBroadcaster: at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
09-17 12:05:27.828 29655 29802 E BaseEventBroadcaster: at
java.lang.Thread.run(Thread.java:784)
```
There are bunch of things weird here. First of all, I don't have any
other Tor Browser running nor Orbot installed on that tablet. So, it's
not obvious what is interfering with Tor Browser.
Secondly, for some reason two tor's are started (and both are dying
later) which seems wrong to me.https://gitlab.torproject.org/tpo/core/onionmasq/-/issues/64Error handling UX reminder2024-01-18T16:23:38ZetaError handling UX reminderI need to write up something in tpo/applications/vpn about how to handle connection failures (with logs); this is a reminder ticket to do that :pI need to write up something in tpo/applications/vpn about how to handle connection failures (with logs); this is a reminder ticket to do that :pVPN pre-alpha 05etaetahttps://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/75Include fallback dir update script logic into descriptorParser2024-01-18T08:19:59ZHiroInclude fallback dir update script logic into descriptorParserWe have an ant task for the website that runs a python script and update the fallback dirs list on the website. We should have that logic in descriptorParser and add the flag to the appropriate relays.We have an ant task for the website that runs a python script and update the fallback dirs list on the website. We should have that logic in descriptorParser and add the flag to the appropriate relays.https://gitlab.torproject.org/tpo/core/arti/-/issues/1139Create fs-mistrust wrapper for WalkDir2024-01-17T20:23:21Zgabi-250Create fs-mistrust wrapper for WalkDirWe need an `fs-mistrust`-based alternative to [`WalkDir`](https://crates.io/crates/walkdir).
This is a follow-up from !1769 (see [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1769#note_2970121))We need an `fs-mistrust`-based alternative to [`WalkDir`](https://crates.io/crates/walkdir).
This is a follow-up from !1769 (see [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1769#note_2970121))Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/onionmasq/-/issues/63Exception handling for failing exit node selection2024-01-17T15:00:52ZcybertaException handling for failing exit node selectionIn context of https://gitlab.torproject.org/tpo/applications/vpn/-/issues/38, the client/tor-vpn should be informed if a selected exit node country doesn't provide any internet connectivty, e.g. since there's no exit node available in th...In context of https://gitlab.torproject.org/tpo/applications/vpn/-/issues/38, the client/tor-vpn should be informed if a selected exit node country doesn't provide any internet connectivty, e.g. since there's no exit node available in the respective country. This could be implemented as a specific exception that gets thrown in this case.
These exceptions could be thrown in refreshCircuits(), refreshCircuitsForApp() and startProxy().https://gitlab.torproject.org/tpo/core/arti/-/issues/1250Add CLI tests for `arti hss`2024-01-17T13:57:38Zgabi-250Add CLI tests for `arti hss`Arti: Onion service supporthttps://gitlab.torproject.org/tpo/web/donate-neo/-/issues/15Promote common styles, assets and components to lego successor2024-01-16T22:12:42ZdonutsPromote common styles, assets and components to lego successorDescription TBD.Description TBD.