The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-06-24T14:57:08Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31228Support spawning multiple transport instances2022-06-24T14:57:08ZPhilipp Winterphw@torproject.orgSupport spawning multiple transport instancesOne Tor instance can only handle one transport instance, i.e., one cannot run two obfs4 instances in one tor. Adding support for this use case will require changes in our PT spec, in PT spec implementations, and in tor.
As pointed out [...One Tor instance can only handle one transport instance, i.e., one cannot run two obfs4 instances in one tor. Adding support for this use case will require changes in our PT spec, in PT spec implementations, and in tor.
As pointed out [in this comment](https://trac.torproject.org/projects/tor/ticket/29285#comment:5), tor would need the config options `ServerTransportPlugin`, `ServerTransportListenAddr`, and `ServerTransportOptions` to support multiple instances of a single transport. One way to accomplish this would be to append a numeric, incrementing suffix to a transport's name, e.g.:
```
ServerTransportPlugin obfs4-0 exec /usr/bin/obfs4proxy
ServerTransportPlugin obfs4-1 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4-0 0.0.0.0:10000
ServerTransportListenAddr obfs4-1 0.0.0.0:20000
```
legacy/trac#11211 is vaguely related in that it aims to add dual stack support for bridges so that, say, an obfs4 instance can listen on both an IPv4 and IPv6 address. legacy/trac#29285 is also related because it tracks our PT spec improvement process and supporting multiple instances of a transport is one potential improvement.https://gitlab.torproject.org/tpo/core/tor/-/issues/31221Line unexpectedly reached at channel_tls_handle_cell at ../src/core/or/channe...2020-06-27T13:49:46Zweasel (Peter Palfrader)Line unexpectedly reached at channel_tls_handle_cell at ../src/core/or/channeltls.c:1111via https://bugs.debian.org/932789
might be a duplicate of legacy/trac#31136.
```
+---
| Tor[2185]: Bug: Line unexpectedly reached at channel_tls_handle_cell at ../src/core/or/channeltls.c:1111. Stack trace: (on Tor 0.3.5.8
+)
| Tor[21...via https://bugs.debian.org/932789
might be a duplicate of legacy/trac#31136.
```
+---
| Tor[2185]: Bug: Line unexpectedly reached at channel_tls_handle_cell at ../src/core/or/channeltls.c:1111. Stack trace: (on Tor 0.3.5.8
+)
| Tor[2185]: Bug: /usr/bin/tor(log_backtrace_impl+0x46) [0x55d7f7455aa6] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /usr/bin/tor(tor_bug_occurred_+0xc0) [0x55d7f74511c0] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /usr/bin/tor(channel_tls_handle_cell+0x49a) [0x55d7f72db71a] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /usr/bin/tor(+0x9a16a) [0x55d7f72ff16a] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /usr/bin/tor(connection_handle_read+0x99d) [0x55d7f72c918d] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /usr/bin/tor(+0x69ebe) [0x55d7f72ceebe] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7fe17bc599ba] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7fe17bc5a537] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /usr/bin/tor(do_main_loop+0xb0) [0x55d7f72d0290] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /usr/bin/tor(tor_run_main+0x10e5) [0x55d7f72be0d5] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /usr/bin/tor(tor_main+0x3a) [0x55d7f72bb30a] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /usr/bin/tor(main+0x19) [0x55d7f72baec9] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7fe17b53b09b] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /usr/bin/tor(_start+0x2a) [0x55d7f72baf1a] (on Tor 0.3.5.8 )
+---
(on a Debian buster system)
```Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31219Nautilus-S - FSB contractor project to spy on tor users2020-07-29T12:56:37ZcypherpunksNautilus-S - FSB contractor project to spy on tor usershttps://gizmodo.com/hackers-reportedly-break-into-sytech-a-contractor-for-1836584241https://gizmodo.com/hackers-reportedly-break-into-sytech-a-contractor-for-1836584241https://gitlab.torproject.org/tpo/core/tor/-/issues/31207Space out first connection_edge_process_relay_cell() line in circuit_receive_...2020-06-27T13:49:46ZNeel Chauhanneel@neelc.orgSpace out first connection_edge_process_relay_cell() line in circuit_receive_relay_cell()
The first `if` statement containing `connection_edge_process_relay_cell()` looks like this
```
if ((reason=connection_edge_process_relay_cell(cell, circ, conn, NULL))
< 0) {
```
Whereas the second looks like this:
...
The first `if` statement containing `connection_edge_process_relay_cell()` looks like this
```
if ((reason=connection_edge_process_relay_cell(cell, circ, conn, NULL))
< 0) {
```
Whereas the second looks like this:
```
if ((reason = connection_edge_process_relay_cell(cell, circ, conn,
layer_hint)) < 0) {
```
We should space out the firstTor: 0.4.2.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31202Refactor practracker's issue-listing code to return a generator2021-09-16T14:23:38ZNick MathewsonRefactor practracker's issue-listing code to return a generatorRight now, this issue-listing code exposes the problems with "print()". Instead, it should yield them as a generator, so that the invoking code can decide what to do with them.Right now, this issue-listing code exposes the problems with "print()". Instead, it should yield them as a generator, so that the invoking code can decide what to do with them.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31190List all valid DirPort urls2021-09-16T14:23:38ZDamian JohnsonList all valid DirPort urlsHi network team. Every so often folks stumble on DirPort resources Stem doesn't recognize...
https://trac.torproject.org/projects/tor/ticket/30930
https://trac.torproject.org/projects/tor/ticket/31187
Unfortunately section 'B' is the c...Hi network team. Every so often folks stumble on DirPort resources Stem doesn't recognize...
https://trac.torproject.org/projects/tor/ticket/30930
https://trac.torproject.org/projects/tor/ticket/31187
Unfortunately section 'B' is the closest enumeration we have, but even it doesn't include everything...
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n3888
Could we spec a listing of all urls the DirPort supports (similar to the GETINFO section in the control-spec)?
Thanks!https://gitlab.torproject.org/tpo/core/tor/-/issues/31189potential docs update needed for GuardLifetime?2020-07-14T22:24:18Zcypherpunkspotential docs update needed for GuardLifetime?The documentation for the GuardLifetime torrc option says:
```
If nonzero, and UseEntryGuards is set, minimum time to keep a guard before
picking a new one. If zero, we use the GuardLifetime parameter from the
consensus directo...The documentation for the GuardLifetime torrc option says:
```
If nonzero, and UseEntryGuards is set, minimum time to keep a guard before
picking a new one. If zero, we use the GuardLifetime parameter from the
consensus directory. No value here may be less than 1 month or greater
than 5 years; out-of-range values are clamped. (Default: 0)
```
In commit hash 385602e9826e79dbf0d8b51abfd925e59f275708 it appears that there was a behavior change which allows guard lifetimes of 1 day or greater (grep for `get_options()->GuardLifetime >= 86400`). `git blame` indicated the docs for the `GuardLifetime` option haven't been touched in 6-7 years, so I think they need an update after this change.
Is the expected behavior that setting `UseEntryGuards 1` and `GuardLifetime 1 day` will result in guards being used for no longer than one day?Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31188make[1]: don't know how to make ./src/rust/target/release/libtor_rust.a2022-06-17T18:31:31ZTracmake[1]: don't know how to make ./src/rust/target/release/libtor_rust.aHi,
I'm trying to add the option to build tor with Rust to pkgsrc. On NetBSD 9 (8.99.48) amd64, this fails at the moment:
...
CC src/trunnel/libor_trunnel_a-socks5.oCC src/trunnel/libor_trunnel_a-netinfo.oCC src/t...Hi,
I'm trying to add the option to build tor with Rust to pkgsrc. On NetBSD 9 (8.99.48) amd64, this fails at the moment:
...
CC src/trunnel/libor_trunnel_a-socks5.oCC src/trunnel/libor_trunnel_a-netinfo.oCC src/trunnel/libor_trunnel_a-circpad_negotiation.oAR src/trunnel/libor-trunnel.aCC src/lib/trace/trace.oAR src/lib/libtor-trace.a
make[1]: don't know how to make ./src/rust/target/release/libtor_rust.a. Stop
make[1]: stopped in /usr/work/pkgsrc-ng0/tor/work/tor-0.4.0.5
*** Error code 2
Stop.
make: stopped in /usr/work/pkgsrc-ng0/tor/work/tor-0.4.0.5
*** Error code 1
Stop.
make[1]: stopped in /usr/pkgsrc/pkgsrc-ng0/tor
*** Error code 1
Stop.
make: stopped in /usr/pkgsrc/pkgsrc-ng0/tor
rust and cargo are available in the build environment, and the crates are made available ahead of time and TOR_RUST_DEPENDENCIES points to the directory they are in.
Questions: to verify if I hit an error on tor's side or Rust specifics wrt NetBSD, and not on my side, do you support verbose builds?
If you have seen this kind of error before in to on other platforms, was there a resolution (I have seen 3 vaguely similar tickets).
Disclaimer: I'm a contributor to pkgsrc, but I'm not the pkgsrc maintainer for tor, so this is more of a personal exploration to see if I can propose it.
Thanks.
**Trac**:
**Username**: ng0https://gitlab.torproject.org/tpo/core/tor/-/issues/31182Add more typesafe containers to tor2020-07-29T12:57:52ZNick MathewsonAdd more typesafe containers to torAs we migrate slowly towards Rust, we'll want a solution that lets us move to type-safe containers like vec and hashmap.As we migrate slowly towards Rust, we'll want a solution that lets us move to type-safe containers like vec and hashmap.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31181Deprecate more options in 0.4.32020-07-29T12:47:28ZNick MathewsonDeprecate more options in 0.4.3In 0.4.3, we should look for more options that nobody uses (or nobody _should_ use) and deprecate them.In 0.4.3, we should look for more options that nobody uses (or nobody _should_ use) and deprecate them.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31180Remove easy deprecated options in 0.4.52021-11-06T13:24:19ZNick MathewsonRemove easy deprecated options in 0.4.5We have accumulated a handful of deprecated options; We should remove some of them in 0.4.5.We have accumulated a handful of deprecated options; We should remove some of them in 0.4.5.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31179Eliminate non tor_queue.h linked lists.2020-06-27T13:49:47ZNick MathewsonEliminate non tor_queue.h linked lists.We should use tor_queue.h in place of anywhere that we currently manually manage a next and prev. (This may be a duplicate.)
We are planning to only do a couple of these for S31, though we might do more, time permitting.We should use tor_queue.h in place of anywhere that we currently manually manage a next and prev. (This may be a duplicate.)
We are planning to only do a couple of these for S31, though we might do more, time permitting.https://gitlab.torproject.org/tpo/core/tor/-/issues/31178Scripts to help with backport branches2020-06-27T13:49:47ZNick MathewsonScripts to help with backport branchesTeor mentioned wanting to create a helper script for use when backporting branches to older versions of Tor. It would behave like "merge-forward", but instead create a set of candidate branches -- and maybe pull requests for those branc...Teor mentioned wanting to create a helper script for use when backporting branches to older versions of Tor. It would behave like "merge-forward", but instead create a set of candidate branches -- and maybe pull requests for those branches too.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31177Start conversation about auto-formatting our C code2020-06-27T13:49:47ZNick MathewsonStart conversation about auto-formatting our C codeWith legacy/trac#29226 we want to automate our C formatting. But to do so, we will need to come to agreement about our style, and for that, we should start the discussion well in advance.With legacy/trac#29226 we want to automate our C formatting. But to do so, we will need to come to agreement about our style, and for that, we should start the discussion well in advance.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31176Teach practracker about .may_include files2021-09-16T14:23:38ZNick MathewsonTeach practracker about .may_include filesWe would like to introduce a second category of .may_include rules: those that should only apply on an advisory basis. We would treat violations of these rules as a best practices violation rather than an error. It would allow us to st...We would like to introduce a second category of .may_include rules: those that should only apply on an advisory basis. We would treat violations of these rules as a best practices violation rather than an error. It would allow us to start ratcheting down the number of layering violations.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31175Teach practracker to apply separate rules for C headers2020-06-27T13:49:48ZNick MathewsonTeach practracker to apply separate rules for C headersWe might want to impose stricter limits for length and includes on header files than we do on C files.We might want to impose stricter limits for length and includes on header files than we do on C files.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31163A flag to use hostname than IP as relay2020-07-29T12:47:04ZTracA flag to use hostname than IP as relayThough we can add a hostname in the `Address` field in torrc, it finally resolves the name time to time and pushes the descriptor.
However, that hurts the dynamic IP relays. If tor could work on pure hostnames (yes, that'd cause a resol...Though we can add a hostname in the `Address` field in torrc, it finally resolves the name time to time and pushes the descriptor.
However, that hurts the dynamic IP relays. If tor could work on pure hostnames (yes, that'd cause a resolving overhead on every connection) then a whole range of dynamic IP relays could come into the picture which might strengthen the Tor network.
**Trac**:
**Username**: cyberbothttps://gitlab.torproject.org/tpo/core/tor/-/issues/31156Add support of TBytes keyword to torrc for AccountingMax setting (and maybe o...2020-07-30T20:37:37ZTracAdd support of TBytes keyword to torrc for AccountingMax setting (and maybe others)Happening on Debian 9 with Tor 0.2.9.16 from the standard apt repo.
(Sorry, if this is already resolved in newer versions. In that case just close and ignore.)
Syslog output:
```
Jul 14 10:50:38 systemd[1]: Starting Anonymizing overla...Happening on Debian 9 with Tor 0.2.9.16 from the standard apt repo.
(Sorry, if this is already resolved in newer versions. In that case just close and ignore.)
Syslog output:
```
Jul 14 10:50:38 systemd[1]: Starting Anonymizing overlay network for TCP...
Jul 14 10:50:39 tor[530]: Jul 14 10:50:39.082 [notice] Tor 0.2.9.16 (git-9ef571339967c1e5) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0k and Zlib 1.2.8.
Jul 14 10:50:39 tor[530]: Jul 14 10:50:39.082 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jul 14 10:50:39 tor[530]: Jul 14 10:50:39.082 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jul 14 10:50:39 tor[530]: Jul 14 10:50:39.082 [notice] Read configuration file "/etc/tor/torrc".
Jul 14 10:50:39 tor[530]: Jul 14 10:50:39.085 [warn] Unknown unit 'TBytes'.
Jul 14 10:50:39 tor[530]: Jul 14 10:50:39.085 [warn] Failed to parse/validate config: Value 'AccountingMax 5 TBytes' is malformed or out of bounds.
Jul 14 10:50:39 tor[530]: Jul 14 10:50:39.085 [err] Reading config failed--see warnings above.
Jul 14 10:50:39 systemd[1]: tor@default.service: Control process exited, code=exited status=1
Jul 14 10:50:39 systemd[1]: Failed to start Anonymizing overlay network for TCP.
```
Additionally, please note that /var/tor/log didn't give any hint of this, instead it went to syslog. Suboptimal.
**Trac**:
**Username**: tlahttps://gitlab.torproject.org/tpo/core/tor/-/issues/31149Tor is stuck at "Loading Network Status"2020-07-29T12:41:21ZTracTor is stuck at "Loading Network Status"Tor Version: 8.5.4
Operating System: Windows 7
This is the Log I get after clicking:https://paste2.org/mUggK824
**Trac**:
**Username**: bornadxTor Version: 8.5.4
Operating System: Windows 7
This is the Log I get after clicking:https://paste2.org/mUggK824
**Trac**:
**Username**: bornadxTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31147Check tor_vasprintf for error return values.2020-06-27T13:49:48ZTracCheck tor_vasprintf for error return values.In case of error, a negative value will be returned or NULL written into
first supplied argument.
This patch uses both cases to comply with style in the specific files.
A tor_vasprintf error in process_vprintf would lead to a NULL dere...In case of error, a negative value will be returned or NULL written into
first supplied argument.
This patch uses both cases to comply with style in the specific files.
A tor_vasprintf error in process_vprintf would lead to a NULL dereference
later on in buf_add, because the return value -1 casted to size_t would
pass an assertion check inside of buf_add.
On the other hand, common systems will fail on such an operation, so it
is not a huge difference to a simple assertion. Yet it is better to
properly fail instead of relying on such behaviour on all systems.
**Trac**:
**Username**: paldiumTor: 0.4.2.x-final