Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:44:46Zhttps://gitlab.torproject.org/legacy/trac/-/issues/31545CID 1452819: nul-terminated string handling, possibly spurious2020-06-13T15:44:46ZteorCID 1452819: nul-terminated string handling, possibly spuriousBug introduced by #21003, copying sponsors and tags.
```
/src/feature/nodelist/describe.c: 77 in format_node_description()
71 }
72 if (addr32h && has_addr) {
73 memcpy(cp, " and ", 5);
74 cp += 5;
75 }
...Bug introduced by #21003, copying sponsors and tags.
```
/src/feature/nodelist/describe.c: 77 in format_node_description()
71 }
72 if (addr32h && has_addr) {
73 memcpy(cp, " and ", 5);
74 cp += 5;
75 }
76 if (has_addr) {
CID 1452819: (STRING_NULL)
Passing unterminated string "cp" to "tor_addr_to_str", which expects a null-terminated string.
77 tor_addr_to_str(cp, addr, TOR_ADDR_BUF_LEN, 1);
78 }
79
80 return buf;
81 }
82
/src/feature/nodelist/describe.c: 70 in format_node_description()
64 cp += 4;
65 }
66 if (addr32h) {
67 struct in_addr in;
68 in.s_addr = htonl(addr32h);
69 tor_inet_ntoa(&in, cp, INET_NTOA_BUF_LEN);
CID 1452819: (STRING_NULL)
Passing unterminated string "cp" to "strlen", which expects a null-terminated string.
70 cp += strlen(cp);
71 }
72 if (addr32h && has_addr) {
73 memcpy(cp, " and ", 5);
74 cp += 5;
75 }
```
I think the best fix for this issue is using strncpy() rather than memcpy().Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31418Fix some typos in the man page2020-06-13T15:44:19ZteorFix some typos in the man pageTor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31366Move the connection_edge_process_relay_cell() assignment out of the if statem...2020-06-13T15:44:08ZNeel Chauhanneel@neelc.orgMove the connection_edge_process_relay_cell() assignment out of the if statement in circuit_receive_relay_cell()As mentioned in #31207 by nickm:
>This is fine. I'd also take a patch to extract the assignment entirely, since using assignment in this way is error-prone.As mentioned in #31207 by nickm:
>This is fine. I'd also take a patch to extract the assignment entirely, since using assignment in this way is error-prone.Tor: 0.4.2.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/31320Add an IPv6 ORPort example to the torrc.minimal.in-staging and torrc.sample.i...2020-06-13T15:43:59ZteorAdd an IPv6 ORPort example to the torrc.minimal.in-staging and torrc.sample.in filesWe don't currently have any IPv6 ORPorts in the example torrc files, but we should.We don't currently have any IPv6 ORPorts in the example torrc files, but we should.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30967Make shellcheck ignore user-created directories, and run it during pre-commit2020-06-13T15:42:56ZteorMake shellcheck ignore user-created directories, and run it during pre-commitAt the moment, we shellcheck all the directories inside the tor directory, even user directories like .git, user-specified build directories, and directories that are added during tests.
This change will conflict with #30963, so it shou...At the moment, we shellcheck all the directories inside the tor directory, even user directories like .git, user-specified build directories, and directories that are added during tests.
This change will conflict with #30963, so it should be based on that branch.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/30955Update the fallback entry in the man page2020-06-13T15:42:52ZteorUpdate the fallback entry in the man page"FallbackDir ipv4address:port"
"FallbackDir ipv4address:dirport"
"DirAuthority [nickname] [flags] ipv4address:port"
"DirAuthority [nickname] [flags] ipv4address:dirport"
And similarly for orport.
"The provided port value is a dirport;..."FallbackDir ipv4address:port"
"FallbackDir ipv4address:dirport"
"DirAuthority [nickname] [flags] ipv4address:port"
"DirAuthority [nickname] [flags] ipv4address:dirport"
And similarly for orport.
"The provided port value is a dirport; clients ignore this in favor of the specified "orport=" value."
"Clients always use the orport. Relays prefer the dirport, but will use the orport in some circumstances."
Add something to the FallbackDir entry talking about how the DirPort is used by the checking script?Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/30841Allow TOR_MASTER_NAME and TOR_WKT_NAME to be overridden in the git scripts2020-06-13T15:42:26ZteorAllow TOR_MASTER_NAME and TOR_WKT_NAME to be overridden in the git scriptsLet's make all the things configurable.Let's make all the things configurable.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/30840Stop hard-coding the bash path in the git scripts2020-06-13T15:42:26ZteorStop hard-coding the bash path in the git scriptsSome OSes (BSD) don't install bash by default. Others (macOS) have an ancient version of bash, which is too old for our git scripts.Some OSes (BSD) don't install bash by default. Others (macOS) have an ancient version of bash, which is too old for our git scripts.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/30821Fix a typo in test_rebind.sh2020-06-13T15:42:21ZteorFix a typo in test_rebind.shTor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/30279Test IPv6-only v3 onion services in Chutney's CI, once homebrew tor stable su...2020-06-13T13:31:03ZteorTest IPv6-only v3 onion services in Chutney's CI, once homebrew tor stable supports themWhen #23588 merges, we should replace single-onion-ipv6-md with single-onion-v23-ipv6-md in Chutney's CI.When #23588 merges, we should replace single-onion-ipv6-md with single-onion-v23-ipv6-md in Chutney's CI.teorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/30261Add "How do I find bug or feature versions?" to doc/HACKING2020-06-13T15:40:55ZteorAdd "How do I find bug or feature versions?" to doc/HACKINGWe need to find bugfix versions for changes files and backports, and feature versions for specifications.
Let's document the git commands to do that.
For an example, see:
https://trac.torproject.org/projects/tor/ticket/30224#comment:4We need to find bugfix versions for changes files and backports, and feature versions for specifications.
Let's document the git commands to do that.
For an example, see:
https://trac.torproject.org/projects/tor/ticket/30224#comment:4Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/30224Add the tor versions for bridge-distribution-request2020-06-13T15:40:52ZteorAdd the tor versions for bridge-distribution-requestdir-spec says it's not implemented, but it was implemented in 0.3.2.3-alpha and backported.
#18329 was Sponsor M, but the relevant current sponsor is Sponsor 19.dir-spec says it's not implemented, but it was implemented in 0.3.2.3-alpha and backported.
#18329 was Sponsor M, but the relevant current sponsor is Sponsor 19.Tor: 0.4.1.x-finalteorteorhttps://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/30119cert-spec uses binary encodings but does not specify byte order2020-06-13T15:40:35Zirlcert-spec uses binary encodings but does not specify byte orderFrom looking at the Tor implementation (in a black box way, didn't look at the source code) these seem to be big endian byte order. We should have a note in cert-spec for implementors so they don't have to guess.From looking at the Tor implementation (in a black box way, didn't look at the source code) these seem to be big endian byte order. We should have a note in cert-spec for implementors so they don't have to guess.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30114Also fetch tor-github when we git-pull-all.sh2020-06-13T15:40:33ZteorAlso fetch tor-github when we git-pull-all.shIf we don't automatically fetch tor-github, then someone will eventually merge an old version of a pull request.If we don't automatically fetch tor-github, then someone will eventually merge an old version of a pull request.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/30058Chutney bootstrap-network script uses the wrong network flavour2020-06-13T13:30:53ZoparaChutney bootstrap-network script uses the wrong network flavourThe 'tools/bootstrap-network.sh' script doesn't actually use its program argument (the network flavour). This means that the incorrect network is started.
The line:
`export CHUTNEY_NETWORK="$CHUTNEY_PATH/networks/$NETWORK_FLAVOUR"`
sh...The 'tools/bootstrap-network.sh' script doesn't actually use its program argument (the network flavour). This means that the incorrect network is started.
The line:
`export CHUTNEY_NETWORK="$CHUTNEY_PATH/networks/$NETWORK_FLAVOUR"`
should be:
`export CHUTNEY_NETWORK="$CHUTNEY_PATH/networks/$flavour"`teorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/30001test failure: dir_handle_get/status_vote_next_bandwidth2020-06-13T15:40:12ZNick Mathewsontest failure: dir_handle_get/status_vote_next_bandwidthFound by travis: https://travis-ci.org/torproject/tor/jobs/515199996
```
dir_handle_get/status_vote_next_bandwidth:
FAIL src/test/test_dir_handle_get.c:2535: assert(strstr(header, expires))
[status_vote_next_bandwidth FAILED]
```
...Found by travis: https://travis-ci.org/torproject/tor/jobs/515199996
```
dir_handle_get/status_vote_next_bandwidth:
FAIL src/test/test_dir_handle_get.c:2535: assert(strstr(header, expires))
[status_vote_next_bandwidth FAILED]
```
To me this looks like a race condition: the clock probably has advanced by a second between the call to directory_handle_command_get() and the call to time(NULL).Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/29961Update the Tor version for bandwidth-file-digest in torspec2020-06-13T15:40:01ZteorUpdate the Tor version for bandwidth-file-digest in torspecSee my pull request:
https://github.com/torproject/torspec/pull/73See my pull request:
https://github.com/torproject/torspec/pull/73Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29960Actually check for errors in digest256_to_base64() and callers2020-06-13T15:40:00ZteorActually check for errors in digest256_to_base64() and callersWe don't propagate errors from base64_encode() to digest256_to_base64() and its callers.
Discovered as part of #29959.We don't propagate errors from base64_encode() to digest256_to_base64() and its callers.
Discovered as part of #29959.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29959Actually include the bandwidth file digest in the vote2020-06-13T15:40:00ZteorActually include the bandwidth file digest in the voteThe original code in #26698 had a logic error, so the bandwidth file digest was never included in the vote.The original code in #26698 had a logic error, so the bandwidth file digest was never included in the vote.Tor: 0.4.0.x-finalteorteor