The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-01-10T20:11:25Zhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1196Remove all vestiges of HsClientIntroAuthKeypair and friends2024-01-10T20:11:25ZNick MathewsonRemove all vestiges of HsClientIntroAuthKeypair and friendsThese are deprecated, and we can probably afford to remove them soon.These are deprecated, and we can probably afford to remove them soon.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42362"New window" missing from File menu on macOS2024-01-10T07:30:30Zdonuts"New window" missing from File menu on macOSAt some point we seem to have lost the option to open a new window via the File menu on macOS.
[macos-file-menu](/uploads/aa06119db881fb40797f7500c3057e1c/macos-file-menu.png)At some point we seem to have lost the option to open a new window via the File menu on macOS.
[macos-file-menu](/uploads/aa06119db881fb40797f7500c3057e1c/macos-file-menu.png)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/311 webtunnel bridge instead of two!2024-02-27T19:09:02Zcypherpunks1 webtunnel bridge instead of two!You should give at least two bridges for conflux to work.You should give at least two bridges for conflux to work.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42350newwin: consider exempting some `moz-extension://` scheme windows2024-03-12T09:04:47ZThorinnewwin: consider exempting some `moz-extension://` scheme windowsI'm not sure of the ramifications here, because once a window is created it can be used - but not if the urlbar etc is missing, so we can probably detect that
https://github.com/mullvad/mullvad-browser/issues/202
tl;dr: bitwarden chang...I'm not sure of the ramifications here, because once a window is created it can be used - but not if the urlbar etc is missing, so we can probably detect that
https://github.com/mullvad/mullvad-browser/issues/202
tl;dr: bitwarden changed from using a new window (in reality in a new tab) to a using a small resized window anchored to the top right - for UX reasons - the problem is, RFP's new win will open it at 1400 x 900 max.
here's how it should look (I'm just using a blank page, it makes more sense on a login)
![bitwarden](/uploads/b71c4f91ac347512424899f1dbf2a882/bitwarden.png)
here's what actually happens
- if you have the width, it actually positions top/left correctly, but the dimensions is the issue. I have just moved the second window for this image
![bitwarden-RFP](/uploads/aca05e5e8988dcc829d9c01dc76581b4/bitwarden-RFP.png)
Note: the scheme is `moz-extension://` and the window has no tabstrip, urlbar, toolbar - so this means it's useless to repurpose for loading websites, so we should be good to exempt these cases from newwin dimensions
@ma1 cc @pierovma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42347Add a banner warning users about the upcoming EOL for Win ≤8.1 and macOS ≤10.142024-02-01T14:39:44ZPier Angelo VendrameAdd a banner warning users about the upcoming EOL for Win ≤8.1 and macOS ≤10.1413.5 will be the last Windows version, Mozilla bumped the requirement to Windows 10.
We could add a warning to Windows 7 users somewhere, e.g., in about:tor.
We can check the version of the OS with `Services.sysinfo.getProperty("versio...13.5 will be the last Windows version, Mozilla bumped the requirement to Windows 10.
We could add a warning to Windows 7 users somewhere, e.g., in about:tor.
We can check the version of the OS with `Services.sysinfo.getProperty("version")`. It's `10.0` in my Windows 10 VM, and `6.1` in my Windows 7 VM.
Maybe the first versions of Windows 10 also use 6.1, but if that's the case, they're unsupported too.https://gitlab.torproject.org/tpo/tpa/team/-/issues/41454Migrate metrics-store-01 to object storage2024-01-04T19:34:23ZHiroMigrate metrics-store-01 to object storageWe have agreed we can migrate metrics-store-01 to object storage.We have agreed we can migrate metrics-store-01 to object storage.HiroHirohttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42344Dragging and dropping files on Tor Browser triggers an assertion2024-01-08T11:13:11ZPier Angelo VendrameDragging and dropping files on Tor Browser triggers an assertionDropping a file on Tor Browser to open it triggers an assertion when they are enabled, on the validity of the event timestamp.
I haven't checked if Firefox also has this problem yet, because I don't have a debug build of Firefox.
Verif...Dropping a file on Tor Browser to open it triggers an assertion when they are enabled, on the validity of the event timestamp.
I haven't checked if Firefox also has this problem yet, because I don't have a debug build of Firefox.
Verified on Linux, for now, but might happen also on other platforms.
```c++
TimeDuration operator-(const TimeStamp& aOther) const {
MOZ_ASSERT(!IsNull(), "Cannot compute with a null value");
MOZ_ASSERT(!aOther.IsNull(), "Cannot compute with aOther null value"); // <-- this is the assertion
```
<details><summary>Stack trace</summary>
```
mozilla::TimeStamp::operator-(mozilla::TimeStamp const&) const (/home/piero/Tor/tor-browser/obj-x86_64-pc-linux-gnu/dist/include/mozilla/TimeStamp.h:478)
mozilla::TimeStamp mozilla::SystemTimeConverter<unsigned int, mozilla::TimeStamp>::GetTimeStampFromSystemTime<mozilla::CurrentX11TimeGetter>(unsigned int, mozilla::CurrentX11TimeGetter&) (/home/piero/Tor/tor-browser/widget/SystemTimeConverter.h:110)
nsWindow::GetEventTimeStamp(unsigned int) (/home/piero/Tor/tor-browser/widget/gtk/nsWindow.cpp:4925)
nsWindow::GetWidgetEventTime(unsigned int) (/home/piero/Tor/tor-browser/widget/gtk/nsWindow.cpp:4893)
nsWindow::OnEnterNotifyEvent(_GdkEventCrossing*) (/home/piero/Tor/tor-browser/widget/gtk/nsWindow.cpp:4237)
enter_notify_event_cb(_GtkWidget*, _GdkEventCrossing*) (/home/piero/Tor/tor-browser/widget/gtk/nsWindow.cpp:8023)
___lldb_unnamed_symbol9265 (@___lldb_unnamed_symbol9265:49)
___lldb_unnamed_symbol908 (@___lldb_unnamed_symbol908:104)
___lldb_unnamed_symbol1115 (@___lldb_unnamed_symbol1115:160)
g_signal_emit_valist (@g_signal_emit_valist:21)
g_signal_emit (@g_signal_emit:29)
___lldb_unnamed_symbol17566 (@___lldb_unnamed_symbol17566:109)
gtk_main_do_event (@gtk_main_do_event:474)
___lldb_unnamed_symbol2629 (@___lldb_unnamed_symbol2629:15)
___lldb_unnamed_symbol4021 (@___lldb_unnamed_symbol4021:14)
___lldb_unnamed_symbol2528 (@___lldb_unnamed_symbol2528:128)
___lldb_unnamed_symbol2539 (@___lldb_unnamed_symbol2539:151)
g_main_context_iteration (@g_main_context_iteration:18)
nsAppShell::ProcessNextNativeEvent(bool) (/home/piero/Tor/tor-browser/widget/gtk/nsAppShell.cpp:422)
nsBaseAppShell::DoProcessNextNativeEvent(bool) (/home/piero/Tor/tor-browser/widget/nsBaseAppShell.cpp:131)
nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, bool) (/home/piero/Tor/tor-browser/widget/nsBaseAppShell.cpp:250)
non-virtual thunk to nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, bool) (/home/piero/Tor/tor-browser/widget/nsBaseAppShell.cpp:0)
nsThread::ProcessNextEvent(bool, bool*) (/home/piero/Tor/tor-browser/xpcom/threads/nsThread.cpp:1154)
NS_ProcessNextEvent(nsIThread*, bool) (/home/piero/Tor/tor-browser/xpcom/threads/nsThreadUtils.cpp:479)
mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (/home/piero/Tor/tor-browser/ipc/glue/MessagePump.cpp:85)
MessageLoop::RunHandler() (/home/piero/Tor/tor-browser/ipc/chromium/src/base/message_loop.cc:361)
MessageLoop::Run() (/home/piero/Tor/tor-browser/ipc/chromium/src/base/message_loop.cc:343)
nsBaseAppShell::Run() (/home/piero/Tor/tor-browser/widget/nsBaseAppShell.cpp:148)
nsAppStartup::Run() (/home/piero/Tor/tor-browser/toolkit/components/startup/nsAppStartup.cpp:295)
XREMain::XRE_mainRun() (/home/piero/Tor/tor-browser/toolkit/xre/nsAppRunner.cpp:5826)
XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) (/home/piero/Tor/tor-browser/toolkit/xre/nsAppRunner.cpp:6026)
XRE_main(int, char**, mozilla::BootstrapConfig const&) (/home/piero/Tor/tor-browser/toolkit/xre/nsAppRunner.cpp:6082)
do_main(int, char**, char**) (/home/piero/Tor/tor-browser/browser/app/nsBrowserApp.cpp:227)
main (/home/piero/Tor/tor-browser/browser/app/nsBrowserApp.cpp:445)
__libc_start_call_main (@__libc_start_call_main:26)
__libc_start_main_impl (@__libc_start_main@@GLIBC_2.34:43)
_start (@_start:14)
```
</details>
Other kind of drag and drops (e.g., tabs/links from Firefox) work, but I haven't done an extended test.ma1ma1https://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/69`unmeasured`, `vote` (and `consensus_bandwidth_is_unmeasured`) keywords are n...2024-01-16T13:49:09ZGeorg Koppen`unmeasured`, `vote` (and `consensus_bandwidth_is_unmeasured`) keywords are not properly treatedHave a look at the following 2 bw lines and there representation in our DB:
```
./16/2023-12-16-12-38-04-bandwidth-95BC922FA3DB2DDFC7E98ED4A9FFD0138A17BB1DEAD638852C601E55BD5878CF:bw=1 error_circ=5 error_destination=0 error_misc=0 error_...Have a look at the following 2 bw lines and there representation in our DB:
```
./16/2023-12-16-12-38-04-bandwidth-95BC922FA3DB2DDFC7E98ED4A9FFD0138A17BB1DEAD638852C601E55BD5878CF:bw=1 error_circ=5 error_destination=0 error_misc=0 error_second_relay=0 error_stream=0 master_key_ed25519=8VJa1wrFEuyszRnbE9z3D7acLWLvMrRgqodyrZzF1XM nick=TORPi node_id=FFDC0E2EA1D56C555978920C6D26EBA6AFF248FE relay_in_recent_consensus_count=103 relay_recent_measurement_attempt_count=5 relay_recent_measurements_excluded_error_count=5 relay_recent_priority_list_count=5 success=0 time=2023-12-16T00:41:02 unmeasured=1 vote=0 xoff_recv=0 xoff_sent=0
digest | bw | bw_mean | bw_median | consensus_bandwidth | consensus_bandwidth_is_unmeasured | desc_bw_avg | desc_bw_bur | desc_bw_obs_last | desc_bw_obs_mean | error_circ | error_destination | error_misc | error_second_relay | error_stream | master_key_ed25519 | nick | node_id | rtt | relay_in_recent_consensus_count | relay_recent_measurement_attempt_count | relay_recent_measurements_excluded_error_count | relay_recent_measurement_failure_count | relay_recent_measurements_excluded_near_count | relay_recent_measurements_excluded_old_count | relay_recent_measurements_excluded_few_count | relay_recent_priority_list_count | under_min_report | unmeasured | vote | xoff_recv | xoff_sent | success | time | bandwidth_file | r_strm | r_strm_filt
---------------------------------------------+----+---------+-----------+---------------------+-----------------------------------+-------------+-------------+------------------+------------------+------------+-------------------+------------+--------------------+--------------+---------------------------------------------+-------+------------------------------------------+-----+---------------------------------+----------------------------------------+------------------------------------------------+----------------------------------------+-----------------------------------------------+----------------------------------------------+----------------------------------------------+----------------------------------+------------------+------------+------+-----------+-----------+---------+---------------------+---------------------------------------------+--------+-------------
ehnR7l7BXiy24GF9TaeNYXjZBzWPCYff0VmoLRJL22I | 1 | -1 | -1 | -1 | f | -1 | -1 | -1 | -1 | 5 | 0 | 0 | 0 | 0 | 8VJa1wrFEuyszRnbE9z3D7acLWLvMrRgqodyrZzF1XM | TORPi | FFDC0E2EA1D56C555978920C6D26EBA6AFF248FE | 0 | 103 | 5 | 5 | 0 | 0 | 0 | 0 | 5 | f | f | f | 0 | 0 | 0 | 2023-12-16 00:41:02 | lbySL6PbLd/H6Y7Uqf/QE4oXux3q1jiFLGAeVb1YeM8 | 0 | 0
```
and
```
./16/2023-12-16-12-36-10-bandwidth-8AB15BA0804A1CB8B8D251523118156C49107E7DA4B1888965B196365A309864:bw=33000 bw_mean=1157384 bw_median=991611 consensus_bandwidth=34000000 consensus_bandwidth_is_unmeasured=False desc_bw_avg=1073741824 desc_bw_bur=1073741824 desc_bw_obs_last=25973760 desc_bw_obs_mean=30132316 error_circ=0 error_destination=0 error_misc=0 error_second_relay=0 error_stream=0 master_key_ed25519=zak6whupYxRKeYPtIfYJBlQrksWKIVeUYXuyc+WZBM4 nick=Najdorf node_id=$FAF0A8829E39063669FA609B904E0FB8D5E1F23F relay_in_recent_consensus_count=120 relay_recent_measurement_attempt_count=15 relay_recent_priority_list_count=15 success=15 time=2023-12-16T07:41:31
digest | bw | bw_mean | bw_median | consensus_bandwidth | consensus_bandwidth_is_unmeasured | desc_bw_avg | desc_bw_bur | desc_bw_obs_last | desc_bw_obs_mean | error_circ | error_destination | error_misc | error_second_relay | error_stream | master_key_ed25519 | nick | node_id | rtt | relay_in_recent_consensus_count | relay_recent_measurement_attempt_count | relay_recent_measurements_excluded_error_count | relay_recent_measurement_failure_count | relay_recent_measurements_excluded_near_count | relay_recent_measurements_excluded_old_count | relay_recent_measurements_excluded_few_count | relay_recent_priority_list_count | under_min_report | unmeasured | vote | xoff_recv | xoff_sent | success | time | bandwidth_file | r_strm | r_strm_filt
---------------------------------------------+-------+---------+-----------+---------------------+-----------------------------------+-------------+-------------+------------------+------------------+------------+-------------------+------------+--------------------+--------------+---------------------------------------------+---------+-------------------------------------------+-----+---------------------------------+----------------------------------------+------------------------------------------------+----------------------------------------+-----------------------------------------------+----------------------------------------------+----------------------------------------------+----------------------------------+------------------+------------+------+-----------+-----------+---------+---------------------+---------------------------------------------+--------+-------------
NzLgVvhWGgCgxBAaWw/XgeLQxHe3JT1OcZ2ChZWBHSU | 33000 | 1157384 | 991611 | 34000000 | f | 1073741824 | 1073741824 | 25973760 | 30132316 | 0 | 0 | 0 | 0 | 0 | zak6whupYxRKeYPtIfYJBlQrksWKIVeUYXuyc+WZBM4 | Najdorf | $FAF0A8829E39063669FA609B904E0FB8D5E1F23F | 0 | 120 | 15 | 0 | 0 | 0 | 0 | 0 | 15 | f | f | f | 0 | 0 | 15 | 2023-12-16 07:41:31 | irFboIBKHLi40lFSMRgVbEkQfn2ksYiJZbGWNlowmGQ | 0 | 0
```
The first one has `unmeasured=1` and `vote=0` while the latter has both of them missing. Yet in the DB both entries are `f`.
I guess in the first case the `unmeasured` should be `t` and `vote` should be `f` and in the second one it should be `f` and `t`, respectively?
/cc @jugahttps://gitlab.torproject.org/tpo/core/tor/-/issues/40901Document for the Relay Operator community how to debug relays that are slower...2023-12-19T07:53:56ZAlexander Færøyahf@torproject.orgDocument for the Relay Operator community how to debug relays that are slower than what the operator expectsThis idea origins from a conversation betweeh @beth, @gk and I on #tor-dev today.
We often release new features of C Tor to the relay operators that causes discussions/conversations around whether Tor has gotten faster/slower/uses (more...This idea origins from a conversation betweeh @beth, @gk and I on #tor-dev today.
We often release new features of C Tor to the relay operators that causes discussions/conversations around whether Tor has gotten faster/slower/uses (more|less) memory/crashes (more|less) often/etc. many of these items are hard to give a definitive "yes, the cause of this is X" and it's very time consuming for the Network Team to debug each item individually with the operator.
It would be very useful to have a document in place that informs relay operators about the different situations that may impact performance and how they can get some performance measurements they can then compare to and see if our performance have truly regressed. This can also be used to push MetricsPort to more operators.
We can expand upon the document over time as we discover new ways to do this analysis and/or from feedback from the relay operator community.
This is related to:
- https://lists.torproject.org/pipermail/tor-relays/2023-December/021409.html
- https://lists.torproject.org/pipermail/tor-relays/2023-December/021407.html
This may be relevant to Arti Relay too.
CC @mikeperry for awareness.https://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/67Avoid NullPointerException when trying to get an exception message2024-01-16T13:49:11ZGeorg KoppenAvoid NullPointerException when trying to get an exception messageWile going over our parser logs I found this interesting bit:
```
2023-12-16 11:50:51,346 WARN o.t.m.d.u.DateTimeHelper:149 VoteParser run().
java.lang.NullPointerException: Cannot invoke "String.length()" because "s" is null
at java.ba...Wile going over our parser logs I found this interesting bit:
```
2023-12-16 11:50:51,346 WARN o.t.m.d.u.DateTimeHelper:149 VoteParser run().
java.lang.NullPointerException: Cannot invoke "String.length()" because "s" is null
at java.base/java.util.Formatter.parse(Formatter.java:2717)
at java.base/java.util.Formatter.format(Formatter.java:2671)
at java.base/java.util.Formatter.format(Formatter.java:2625)
at java.base/java.lang.String.format(String.java:4145)
at org.torproject.metrics.descriptorparser.parsers.VoteParser.addNetworkStatusVote(VoteParser.java:226)
at org.torproject.metrics.descriptorparser.parsers.VoteParser.run(VoteParser.java:85)
at org.torproject.metrics.descriptorparser.Main.run(Main.java:147)
at org.torproject.metrics.descriptorparser.Main.exec(Main.java:36)
at org.torproject.metrics.descriptorparser.Main.main(Main.java:32)
```
I guess what that means is we should be a bit more careful with blocks like
```
} catch (Exception ex) {
logger.warn("Exception. {}".format(ex.getMessage()));
ex.printStackTrace();
}
```
making sure we only try to get a message if it is not `null` (`NullPointerException`s have no messages, for instance, IIRC).https://gitlab.torproject.org/tpo/tpa/team/-/issues/41450Move collector.torproject.org to serve files stored in object storage2024-01-04T19:33:19ZHiroMove collector.torproject.org to serve files stored in object storageIn https://gitlab.torproject.org/tpo/tpa/team/-/issues/41416 we have discussed how we can move the tarballs from metrics-store-01 and those collector creates to object storage.
For metrics-store-01 we can just move the files, and once w...In https://gitlab.torproject.org/tpo/tpa/team/-/issues/41416 we have discussed how we can move the tarballs from metrics-store-01 and those collector creates to object storage.
For metrics-store-01 we can just move the files, and once we have the bucket, we can just update the links in the wiki where we list our archives.
For collector we need a way for people to browse the archives and download tarballs recursively if needed. I am thinking that we should preserve what we serve on collector.tpo, just have the links point to the buckets.
Once this is done, we can also discuss how we could generate the tarballs and move them to minio.https://gitlab.torproject.org/tpo/core/arti/-/issues/1162Allow configuring other paths with respect to state_dir.2024-01-09T19:34:42ZNick MathewsonAllow configuring other paths with respect to state_dir.If you override `state_dir`, you might think that you've done enough to avoid using the default state directory in `${ARTI_LOCAL_DATA}` ... but you'd be wrong! The keystore location also defaults to `${ARTI_LOCAL_DATA}/keystore`, so you'...If you override `state_dir`, you might think that you've done enough to avoid using the default state directory in `${ARTI_LOCAL_DATA}` ... but you'd be wrong! The keystore location also defaults to `${ARTI_LOCAL_DATA}/keystore`, so you'd need to override that too.
It would be neat if we could define a directory as `${state_dir}/keystore`. But in order to do that, we would need to have the ability to let some `CfgPath`-like types get defined with respect to other `CfgPath`s. We would need some kind of a multi-step path resolution process.
To keep this simple, I'd suggest that we declare that there is only one level of dependencies here: that other paths may be defined in terms of `${state_dir}`, but that we don't allow every possible path to depend on every other possible path.
Is this worth doing?Arti: Onion service supporthttps://gitlab.torproject.org/tpo/community/outreach/-/issues/40054Coordinate Tor session at TNC 20242024-03-18T16:25:17ZRoger DingledineCoordinate Tor session at TNC 2024I have teamed up with Jessica Schumacher from Switch to submit a session proposal for TNC in June 2024, https://tnc24.geant.org/
"TNC, the largest and most prestigious research and education networking conference, attracts a diverse aud...I have teamed up with Jessica Schumacher from Switch to submit a session proposal for TNC in June 2024, https://tnc24.geant.org/
"TNC, the largest and most prestigious research and education networking conference, attracts a diverse audience of over 800 participants from more than 70 countries and offers a unique collaborative experience."
This is the venue that several people from European NRENs suggested in terms of how to reach other folks at NRENs who either like Tor or need to learn more about it.Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/arti/-/issues/1158Do we want an "enabled" option for onion services?2023-12-12T20:08:05ZNick MathewsonDo we want an "enabled" option for onion services?We had the idea of having an "enabled" option on each onion service so you could turn it off without having to remove it from the configuration.
I can add this without too much effort by making it another overlay item in the combined pr...We had the idea of having an "enabled" option on each onion service so you could turn it off without having to remove it from the configuration.
I can add this without too much effort by making it another overlay item in the combined proxy configuration. But do we want to do this at all? We could just tell people to comment out onion services they don't want.Ian Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/29Docker installation stopped working 4 days ago (after reboot)2024-03-11T17:42:37Zzfgwsi7xDocker installation stopped working 4 days ago (after reboot)My docker setup stopped working and I can no longer connect to the webtunnel:
Debian 12 6.1.0-13-cloud-amd64
Firewall (also opened on the cloud provider's firewall)
```sh
$ sudo ufw status
80/tcp ALLOW Anywher...My docker setup stopped working and I can no longer connect to the webtunnel:
Debian 12 6.1.0-13-cloud-amd64
Firewall (also opened on the cloud provider's firewall)
```sh
$ sudo ufw status
80/tcp ALLOW Anywhere
443 ALLOW Anywhere
<SSH> ALLOW Anywhere
80/tcp (v6) ALLOW Anywhere (v6)
443 (v6) ALLOW Anywhere (v6)
<SSH> (v6) ALLOW Anywhere (v6)
```
Docker processes
```sh
$ sudo docker ps
ID IMAGE COMMAND CREATED STATUS PORTS NAMES
<ID> containrrr/watchtower:latest "/watchtower" 4 weeks ago Up 20 hours (healthy) 8080/tcp debian-watchtower-1
<ID> thetorproject/webtunnel-bridge:latest "/usr/local/bin/star…" 3 months ago Up 20 hours 127.0.0.1:15000->15000/tcp, 0.0.0.0:<ORPORT>-><ORPORT>/tcp, :::<ORPORT>-><ORPORT>/tcp webtunnelBridge
[debian@jep
```
Logs (these lines keep repeating thousands of times)
```sh
$ sudo docker logs webtunnelBridge
Dec 11 17:27:22.000 [warn] Your server has not managed to confirm reachability for its ORPort(s) at <IP>:<ORPORT>. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.
Dec 11 17:27:22.000 [notice] Unable to find IPv6 address for ORPort <ORPORT>. You might want to specify IPv4Only to it or set an explicit address or set Address. [59 similar message(s) suppressed in last 3540 seconds]
Dec 11 17:47:22.000 [warn] Your server has not managed to confirm reachability for its ORPort(s) at <IP>:<ORPORT>. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.
Dec 11 18:27:22.000 [notice] Unable to find IPv6 address for ORPort <ORPORT>. You might want to specify IPv4Only to it or set an explicit address or set Address. [60 similar message(s) suppressed in last 3540 seconds]
Dec 11 18:43:24.000 [notice] No circuits are opened. Relaxed timeout for circuit 738 (a Testing circuit 3-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway. [19 similar message(s) suppressed in last 8520 seconds]
```
My setup steps:
1. Secure Debian server as usual
2. Follow the docs: https://community.torproject.org/relay/setup/webtunnel/ (choose docker installation)
3. Get bridge address and connect with tor-browser alpha (`sudo docker compose exec webtunnel-bridge get-bridge-line.sh`)
Tor Browser Alpha logs
```sh
2023-12-11 20:00:59.141 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2023-12-11 20:00:59.156 [NOTICE] Opening Socks listener on 127.0.0.1:9150
2023-12-11 20:00:59.156 [NOTICE] Opened Socks listener connection (ready) on 127.0.0.1:9150
2023-12-11 20:01:00.140 [NOTICE] Bootstrapped 1% (conn_pt): Connecting to pluggable transport
2023-12-11 20:01:00.141 [NOTICE] Bootstrapped 2% (conn_done_pt): Connected to pluggable transport
2023-12-11 20:01:00.226 [WARN] Proxy Client: unable to connect OR connection (handshaking (proxy)) with <IPV6>:443 ID=<none> RSA_ID=<RSA_ID>
2023-12-11 20:01:00.229 [WARN] Proxy Client: unable to connect OR connection (handshaking (proxy)) with <IPV6>:443 ID=<none> RSA_ID=<RSA_ID> ("general SOCKS server failure")
2023-12-11 20:01:06.262 [WARN] Proxy Client: unable to connect OR connection (handshaking (proxy)) with <IPV6>:443 ID=<none> RSA_ID=<RSA_ID> ("general SOCKS server failure")
2023-12-11 20:01:06.271 [WARN] Proxy Client: unable to connect OR connection (handshaking (proxy)) with <IPV6>:443 ID=<none> RSA_ID=<RSA_ID> ("general SOCKS server failure")
2023-12-11 20:01:06.776 [NOTICE] Application request when we haven't used client functionality lately. Optimistically trying known bridges again.
2023-12-11 20:01:30.981 [WARN] Proxy Client: unable to connect OR connection (handshaking (proxy)) with <IPV6>:443 ID=<none> RSA_ID=<RSA_ID> ("general SOCKS server failure")
2023-12-11 20:01:31.000 [WARN] Proxy Client: unable to connect OR connection (handshaking (proxy)) with <IPV6>:443 ID=<none> RSA_ID=<RSA_ID> ("general SOCKS server failure")
```shelikhooshelikhoohttps://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/65`exit_addresses` in `exit_node` stored in wrong format2024-01-16T13:49:11ZMattia Righetti`exit_addresses` in `exit_node` stored in wrong format`exit_addresses` in table `exit_node` has wrong format. At the moment we have comma separated values, it could be useful to make the column an array of strings for easier parsing:
- `22.22.22.22` should be `["22.22.22.22"]`
- `22.22.22.2...`exit_addresses` in table `exit_node` has wrong format. At the moment we have comma separated values, it could be useful to make the column an array of strings for easier parsing:
- `22.22.22.22` should be `["22.22.22.22"]`
- `22.22.22.22, 10.10.10.10, 11.12.13.14` should be `["22.22.22.22", "10.10.10.10", "11.12.13.14"]`https://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/64Inconsistencies in some `server_status` columns data format2024-01-16T13:49:09ZMattia RighettiInconsistencies in some `server_status` columns data formatMost of the inconsistencies involve columns that should contain an array of strings:
- `verified_hostname`, `unverified_host_names` should contain an array of strings but some rows contain `"null"`, we should make those values `NULL` or...Most of the inconsistencies involve columns that should contain an array of strings:
- `verified_hostname`, `unverified_host_names` should contain an array of strings but some rows contain `"null"`, we should make those values `NULL` or `[]`.
- `diff_or_addresses` should contain an array of strings but some rows contain `NULL`, `[]` and empty strings, we should standardize the column so that it's easier to parse.
- `unreachable_or_address` should contain an array of strings but a lot of rows contain an empty string, we should make those empty string `NULL` or `[]`.
- `effective_family`, `declared_family` should contain an array of strings but some rows contain a single effective family value, we should standardize that column so that it's easier to parse (i.e `1111111111111111111111111111111111111111` should be `["1111111111111111111111111111111111111111"]`).https://gitlab.torproject.org/tpo/ux/design/-/issues/66Create a new color system2024-01-29T22:18:17ZdonutsCreate a new color systemIn order to support the creation of the new style guide, we need to develop a new and more complex color system that's flexible enough to serve our brand needs and semantic use cases for web and app design. At minimum, we require scales ...In order to support the creation of the new style guide, we need to develop a new and more complex color system that's flexible enough to serve our brand needs and semantic use cases for web and app design. At minimum, we require scales based on the following brand colors:
- Purple
- Green
- Gray
- Blue
- Amber
- Read
And to support dark themes, an alternate background scale (e.g. dark gray, indigo, or dark purple).
Previous work in this area has included the explorations done by Ura Design in https://gitlab.torproject.org/tpo/web/styleguide/-/issues/19.design-dot MVPdonutsdonutshttps://gitlab.torproject.org/tpo/core/arti/-/issues/1152We need an API for unix sockets2024-02-28T12:49:52ZNick MathewsonWe need an API for unix socketsRight now we have a facility to listen on unix sockets for RPC, and we might want to have that for dns and socks as well. Additionally, we want the ability to have onion services (via tor-hsrproxy) *connect* to local unix sockets.
And ...Right now we have a facility to listen on unix sockets for RPC, and we might want to have that for dns and socks as well. Additionally, we want the ability to have onion services (via tor-hsrproxy) *connect* to local unix sockets.
And to complicate things further, we might eventually want to involve Windows named sockets, and whatever else exists in this area.
This won't be too hard to build but there are design issues to think about.
* Should this be a new API for tor-rtcompat?
* Should this be an optional `UnixSocketProvider` that is only present when building for `target_family = "unix"`?
* Should there be an `AbstractSocketProvider` that can take AF_UNIX addresses as well as `SocketAddr`s?
If I were building this without guidance, I think I would answer all three of those questions "yes". But what do you think? (cc @gabi-250 @Diziet)
See also #827 for nomenclature, which I am sure I am getting wrong here.Arti: Onion service supportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41040Add configuration to rbm.conf to select channel and platforms2024-01-09T15:00:50ZboklmAdd configuration to rbm.conf to select channel and platformsCurrently we select the channel and platforms of a release with the make
command we use to start the build. I think we could define this
somewhere in `rbm.conf`, so that we can start the build with something
like `make torbrowser` or `ma...Currently we select the channel and platforms of a release with the make
command we use to start the build. I think we could define this
somewhere in `rbm.conf`, so that we can start the build with something
like `make torbrowser` or `make mullvadbrowser`, automatically selecting
the right channel and platforms to build.
The information about which platforms a release is for can also be used
for #40994.
At the same time we can also rename `var/torbrowser_version`,
`var/torbrowser_build`, `var/torbrowser_incremental_from` to remove the
torbrowser part (since this is used in mullvadbrowser too).