Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T16:15:53Zhttps://gitlab.torproject.org/legacy/trac/-/issues/30184release-0.2.9 doesn't compile on old rhel2020-06-13T16:15:53ZRoger Dingledinerelease-0.2.9 doesn't compile on old rhelOn rhel6, building release-0.2.9 (git commit ca008906), I get
```
CC src/or/src_or_libtor_testing_a-rephist.o
src/or/rephist.c:91: error: redefinition of typedef ‘bw_array_t’
src/or/rephist.h:120: note: previous declaration of ‘bw_...On rhel6, building release-0.2.9 (git commit ca008906), I get
```
CC src/or/src_or_libtor_testing_a-rephist.o
src/or/rephist.c:91: error: redefinition of typedef ‘bw_array_t’
src/or/rephist.h:120: note: previous declaration of ‘bw_array_t’ was here
make[1]: *** [src/or/src_or_libtor_testing_a-rephist.o] Error 1
```
Looks like when we backported some stuff, we didn't backport all of the subsequent fixes on the stuff.
Here is a fix that lets it compile again (there could for sure be a better fix than this):
```
index dc86fad..d8f7eb2 100644
--- a/src/or/rephist.c
+++ b/src/or/rephist.c
@@ -88,7 +88,6 @@
static void bw_arrays_init(void);
static void predicted_ports_init(void);
-typedef struct bw_array_t bw_array_t;
STATIC uint64_t find_largest_max(bw_array_t *b);
STATIC void commit_max(bw_array_t *b);
STATIC void advance_obs(bw_array_t *b);
diff --git a/src/or/rephist.h b/src/or/rephist.h
index c464b34..072987f 100644
--- a/src/or/rephist.h
+++ b/src/or/rephist.h
@@ -114,10 +114,10 @@ void rep_hist_log_link_protocol_counts(void);
extern uint64_t rephist_total_alloc;
extern uint32_t rephist_total_num;
+typedef struct bw_array_t bw_array_t;
#ifdef TOR_UNIT_TESTS
extern int onion_handshakes_requested[MAX_ONION_HANDSHAKE_TYPE+1];
extern int onion_handshakes_assigned[MAX_ONION_HANDSHAKE_TYPE+1];
-typedef struct bw_array_t bw_array_t;
extern bw_array_t *write_array;
#endif
```
(My bwauth still runs on 0.2.9, since I'm under the impression that's the last version that works well with bwauths. That's how I noticed.)Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/29665hs: circuit_expire_old_circuits_serverside() should check for RP circuits2020-06-13T15:38:59ZDavid Gouletdgoulet@torproject.orghs: circuit_expire_old_circuits_serverside() should check for RP circuitsThanks to a single onion service operator on IRC in the #tor channel (`slingamn`), armadev and I were able to identify this issue.
Any clients connecting to a single onion service and then being idle for 60 seconds would get disconnecte...Thanks to a single onion service operator on IRC in the #tor channel (`slingamn`), armadev and I were able to identify this issue.
Any clients connecting to a single onion service and then being idle for 60 seconds would get disconnected as in the rendezvous circuit closed.
It turns out that the rendezvous point closes the service circuit through this function `circuit_expire_old_circuits_serversid()` if is idle for more than 60 seconds (only for single onion service). The faulty condition is:
```
if (or_circ->p_chan && channel_is_client(or_circ->p_chan) &&
!circ->n_chan &&
!or_circ->n_streams && !or_circ->resolving_streams &&
channel_when_last_xmit(or_circ->p_chan) <= cutoff) {
```
The RP is the end of the service circuit (`or_circ`), all data is spliced to the client circuit which makes it that `n_streams` and `n_chan` are NULL and thus validating the condition.
Also possible to hit this if `channel_is_client()` is a false positive for the exit point.
The fix here is to check if the circuit being looked at is a rendezvous point and ignore it if so. The `or_circ->rend_splice` should be non-NULL if so.
This needs to be backported and affects v2 and v3 hidden service.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/29612Update the documentation for ExitRelay2020-06-13T15:38:45ZteorUpdate the documentation for ExitRelayIn #21530 in 0.3.5, we changed the default of ExitRelay: relays used to be exits by default, but now they are not.
But we forgot to update the documentation.In #21530 in 0.3.5, we changed the default of ExitRelay: relays used to be exits by default, but now they are not.
But we forgot to update the documentation.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29144Log the correct "auto" port number for listening sockets2020-06-13T15:37:06ZTracLog the correct "auto" port number for listening socketsWhen `auto` is used for the port number for a listening socket, the message that gets logged after opening the socket incorrectly says port 0 instead of the actual port being used.
A contrived config like this
```
ControlPort auto
Sock...When `auto` is used for the port number for a listening socket, the message that gets logged after opening the socket incorrectly says port 0 instead of the actual port being used.
A contrived config like this
```
ControlPort auto
SocksPort 127.0.0.1:auto
ORPort 127.0.0.1:auto
ORPort [::1]:auto
```
gives log messages like this
Jan 21 12:38:05.741 [notice] Opening Socks listener on 127.0.0.1:0
Jan 21 12:38:05.741 [notice] Socks listener listening on port 22840.
**Jan 21 12:38:05.741 [notice] Opened Socks listener on 127.0.0.1:0**
Jan 21 12:38:05.741 [notice] Opening Control listener on 127.0.0.1:0
Jan 21 12:38:05.741 [notice] Control listener listening on port 14414.
**Jan 21 12:38:05.741 [notice] Opened Control listener on 127.0.0.1:0**
Jan 21 12:38:05.741 [notice] Opening OR listener on 127.0.0.1:0
Jan 21 12:38:05.741 [notice] OR listener listening on port 19719.
**Jan 21 12:38:05.741 [notice] Opened OR listener on 127.0.0.1:0**
Jan 21 12:38:05.741 [notice] Opening OR listener on [::1]:0
Jan 21 12:38:05.742 [notice] OR listener listening on port 4298.
**Jan 21 12:38:05.742 [notice] Opened OR listener on [::1]:0**
An upcoming PR will fix this so that the log messages will have the actual port numbers like this
Jan 21 12:38:57.709 [notice] Opening Socks listener on 127.0.0.1:0
Jan 21 12:38:57.709 [notice] Socks listener listening on port 5236.
**Jan 21 12:38:57.709 [notice] Opened Socks listener on 127.0.0.1:5236**
Jan 21 12:38:57.709 [notice] Opening Control listener on 127.0.0.1:0
Jan 21 12:38:57.709 [notice] Control listener listening on port 14584.
**Jan 21 12:38:57.709 [notice] Opened Control listener on 127.0.0.1:14584**
Jan 21 12:38:57.709 [notice] Opening OR listener on 127.0.0.1:0
Jan 21 12:38:57.709 [notice] OR listener listening on port 15220.
**Jan 21 12:38:57.709 [notice] Opened OR listener on 127.0.0.1:15220**
Jan 21 12:38:57.709 [notice] Opening OR listener on [::1]:0
Jan 21 12:38:57.709 [notice] OR listener listening on port 36901.
**Jan 21 12:38:57.709 [notice] Opened OR listener on [::1]:36901**
This was introduced by commit 27c868eff19dbcc208f6db66ec3e2de2104fa754 and occurs in 0.3.5.1-alpha.
**Trac**:
**Username**: kjakTor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/29017PaddingStatistics should be disabled when ExtraInfoStatistics is 02020-06-13T15:36:26ZteorPaddingStatistics should be disabled when ExtraInfoStatistics is 0The man page entry for PaddingStatistics says that it is disabled when ExtraInfoStatistics is 0. But that isn't the case: the statistics are published regardless of ExtraInfoStatistics.
As far as I can tell, PaddingStatistics are collec...The man page entry for PaddingStatistics says that it is disabled when ExtraInfoStatistics is 0. But that isn't the case: the statistics are published regardless of ExtraInfoStatistics.
As far as I can tell, PaddingStatistics are collected on bridges, but the man page says "Relays only."Tor: 0.3.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/28698When circuit times are fixed, they can't be "relaxed"2020-06-13T15:35:04ZteorWhen circuit times are fixed, they can't be "relaxed"In #28639, we had trouble diagnosing a sbws bug. tor said that circuit times were "relaxed", even when LearnCircuitBuildTimeout was 0.
When circuit_build_times_disabled() is true, we should change these log messages so that they make se...In #28639, we had trouble diagnosing a sbws bug. tor said that circuit times were "relaxed", even when LearnCircuitBuildTimeout was 0.
When circuit_build_times_disabled() is true, we should change these log messages so that they make sense:
https://github.com/torproject/tor/blob/b058f64cc002b44e6dd48616ca3163a01c3f3e14/src/core/or/circuituse.c#L591
I think relaxed_timeout is meaningless when circuit_build_times_disabled() is true, but that's another issue.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/27199panic inside rust extern "C" function is undefined behavior2020-06-13T15:29:38ZTracpanic inside rust extern "C" function is undefined behavior`panic="abort"` needs to be set for all profiles in Cargo.toml, at least until the upstream bug is fixed: https://github.com/rust-lang/rust/issues/52652
This is already set for `[profile.release]` builds, but not for the others.
**Trac...`panic="abort"` needs to be set for all profiles in Cargo.toml, at least until the upstream bug is fixed: https://github.com/rust-lang/rust/issues/52652
This is already set for `[profile.release]` builds, but not for the others.
**Trac**:
**Username**: cyberpunksTor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23790rend_service_prune_list_impl_() doesn't copy over desc_is_dirty when copying ...2020-06-13T15:15:24ZTracrend_service_prune_list_impl_() doesn't copy over desc_is_dirty when copying intro pointsIn `rend_service_prune_list_impl_(void)` (src/or/rendservice.c), the introduction points are copied over from the old to new `rend_service_t`:
```
smartlist_add_all(new->intro_nodes, old->intro_nodes);
```
but, the `desc_is_dirty` fiel...In `rend_service_prune_list_impl_(void)` (src/or/rendservice.c), the introduction points are copied over from the old to new `rend_service_t`:
```
smartlist_add_all(new->intro_nodes, old->intro_nodes);
```
but, the `desc_is_dirty` field is not copied over.
If a reload occurs between after a hidden service is added, but before its descriptor is published for the first time (triggered via `desc_is_dirty`), it will not publish its first descriptor until:
```
rendinitialpostdelay + crypto_rand_int(2*rendpostperiod)
```
It looks like it's simply missing `new->desc_is_dirty = old->desc_is_dirty;` prior to copying of introduction points.
**Trac**:
**Username**: jlTor: 0.2.9.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/13221Misleading error messages about bind_ipv4_only and bind_ipv6_only?2020-06-13T14:39:00ZRoger DingledineMisleading error messages about bind_ipv4_only and bind_ipv6_only?```
if (bind_ipv4_only && tor_addr_family(&addr) == AF_INET6) {
log_warn(LD_CONFIG, "Could not interpret %sPort address as IPv6",
portname);
goto err;
}
```
Is this warn mixed up? Same with t...```
if (bind_ipv4_only && tor_addr_family(&addr) == AF_INET6) {
log_warn(LD_CONFIG, "Could not interpret %sPort address as IPv6",
portname);
goto err;
}
```
Is this warn mixed up? Same with the one below it.Tor: 0.3.5.x-final