Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-07-14T22:24:24Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32338Warn about more relative file paths when validating options2020-07-14T22:24:24ZteorWarn about more relative file paths when validating optionsTor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32349hs-v2: Intro point circuit TIMEOUT failure is not reported2021-06-23T17:23:06ZDavid Gouletdgoulet@torproject.orghs-v2: Intro point circuit TIMEOUT failure is not reportedThis was found while I was working on legacy/trac#32020.
For v2, we report a TIMEOUT circuit failure within `circuit_about_to_free()`. The following code is the snippet on how we check if the circuit timed out:
```
int reason = circ->m...This was found while I was working on legacy/trac#32020.
For v2, we report a TIMEOUT circuit failure within `circuit_about_to_free()`. The following code is the snippet on how we check if the circuit timed out:
```
int reason = circ->marked_for_close_reason;
int timed_out = (reason == END_CIRC_REASON_TIMEOUT);
```
However, in `circuit_mark_for_close_()`, if the circuit is an origin one, which is the case for all HS client circuit, the `marked_for_close_reason` is set to `END_CIRC_REASON_NONE` so we don't send back that reason back within the destroy cell.
The fix is that we should be looking at `marked_for_close_orig_reason` instead.
We need to backport this.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32352Stop adding a space when dumping an empty config value2020-07-14T22:24:09ZteorStop adding a space when dumping an empty config valueWe unconditionally add a space when dumping torrc files, even if there is no option value. (Which is rare, but does happen with some list options.)
The extra space is unnecessary and we should remove it.
This bug has been around since ...We unconditionally add a space when dumping torrc files, even if there is no option value. (Which is rare, but does happen with some list options.)
The extra space is unnecessary and we should remove it.
This bug has been around since Tor 0.0.9pre6.
The fix is in this commit, I need to extract it and add a changes file:
https://github.com/torproject/tor/pull/1477/commits/67d0178f1aba0a424364acc1c9f9dff2c72886a4Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32356hs-v3: Memory leak in rend_client_get_random_intro_impl()2021-06-23T17:23:06ZDavid Gouletdgoulet@torproject.orghs-v3: Memory leak in rend_client_get_random_intro_impl()From coverity report:
```
** CID 1455168: Resource leaks (RESOURCE_LEAK)
/src/feature/rend/rendclient.c: 1061 in rend_client_get_random_intro_impl()
___________________________________________________________________________________...From coverity report:
```
** CID 1455168: Resource leaks (RESOURCE_LEAK)
/src/feature/rend/rendclient.c: 1061 in rend_client_get_random_intro_impl()
________________________________________________________________________________________________________
*** CID 1455168: Resource leaks (RESOURCE_LEAK)
/src/feature/rend/rendclient.c: 1061 in rend_client_get_random_intro_impl()
1055 usable_nodes = smartlist_new();
1056 smartlist_add_all(usable_nodes, entry->parsed->intro_nodes);
1057
1058 /* Get service ID so we can use it to query the failure cache. If we fail to
1059 * parse it, this cache entry is no good. */
1060 if (BUG(rend_get_service_id(entry->parsed->pk, service_id) < 0)) {
>>> CID 1455168: Resource leaks (RESOURCE_LEAK)
>>> Variable "usable_nodes" going out of scope leaks the storage it points to.
1061 return NULL;
1062 }
```
Was just introduced couple days ago.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32357Coverity reports leak-on-BUG() in rend_client_get_random_intro_impl()2020-06-27T13:48:56ZNick MathewsonCoverity reports leak-on-BUG() in rend_client_get_random_intro_impl() ```
_______________________________________________________________________________________________________
*** CID 1455168: Resource leaks (RESOURCE_LEAK)
/src/feature/rend/rendclient.c: 1061 in rend_client_get_random_intro_impl()
10... ```
_______________________________________________________________________________________________________
*** CID 1455168: Resource leaks (RESOURCE_LEAK)
/src/feature/rend/rendclient.c: 1061 in rend_client_get_random_intro_impl()
1055 usable_nodes = smartlist_new();
1056 smartlist_add_all(usable_nodes, entry->parsed->intro_nodes);
1057
1058 /* Get service ID so we can use it to query the failure cache. If we fail to
1059 * parse it, this cache entry is no good. */
1060 if (BUG(rend_get_service_id(entry->parsed->pk, service_id) < 0)) {
>>> CID 1455168: Resource leaks (RESOURCE_LEAK)
>>> Variable "usable_nodes" going out of scope leaks the storage it points to.
1061 return NULL;
1062 }
1063
1064 /* Remove the intro points that have timed out during this HS
1065 * connection attempt from our list of usable nodes. */
1066 SMARTLIST_FOREACH_BEGIN(usable_nodes, const rend_intro_point_t *, ip) {
```Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32368Use the same tor binary in all our test scripts2020-06-27T13:48:56ZteorUse the same tor binary in all our test scriptsTor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32369Should rename_c_identifier.py also update practracker/exceptions.txt2020-06-27T13:48:56ZteorShould rename_c_identifier.py also update practracker/exceptions.txtIn legacy/trac#32213, I got a commit hook error, because rename_c_identifier.py renamed some functions, but did not rename their entries in practracker/exceptions.txt.
Should we rename entries in practracker/exceptions.txt automatically?In legacy/trac#32213, I got a commit hook error, because rename_c_identifier.py renamed some functions, but did not rename their entries in practracker/exceptions.txt.
Should we rename entries in practracker/exceptions.txt automatically?Tor: unspecifiedNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32370Fix "make autostyle" in out of tree builds2020-06-27T13:48:56ZteorFix "make autostyle" in out of tree buildsThe paths were relative to cwd, not top_srcdirThe paths were relative to cwd, not top_srcdirTor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32371Fix update_versions.py in out of tree builds2020-06-27T13:48:56ZteorFix update_versions.py in out of tree buildsOne file wasn't relative to abs_top_srcdir.One file wasn't relative to abs_top_srcdir.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32376test: Possible NULL deref in free_fake_orcirc()2020-07-14T18:41:13ZDavid Gouletdgoulet@torproject.orgtest: Possible NULL deref in free_fake_orcirc()Introduced with legacy/trac#32196.
Found by coverity:
```
*** CID 1455207: Null pointer dereferences (FORWARD_NULL)
/src/test/test_relay.c: 116 in test_relay_close_circuit()
110 if (orcirc) {
111 circuitmux_detach_circu...Introduced with legacy/trac#32196.
Found by coverity:
```
*** CID 1455207: Null pointer dereferences (FORWARD_NULL)
/src/test/test_relay.c: 116 in test_relay_close_circuit()
110 if (orcirc) {
111 circuitmux_detach_circuit(nchan->cmux, TO_CIRCUIT(orcirc));
112 circuitmux_detach_circuit(pchan->cmux, TO_CIRCUIT(orcirc));
113 cell_queue_clear(&orcirc->base_.n_chan_cells);
114 cell_queue_clear(&orcirc->p_chan_cells);
115 }
>>> CID 1455207: Null pointer dereferences (FORWARD_NULL)
>>> Passing null pointer "orcirc" to "free_fake_orcirc", which dereferences it.
116 free_fake_orcirc(orcirc);
```Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32378Doxygen: fix \refdir output2021-07-22T16:19:07ZNick MathewsonDoxygen: fix \refdir outputI thought that I had a working `\refdir` command for doxygen that would generate correct links to directory documentation, even in out-of-tree builds. Unfortunately, it only worked for out-of-tree builds whose `@srcdir@` did not contain...I thought that I had a working `\refdir` command for doxygen that would generate correct links to directory documentation, even in out-of-tree builds. Unfortunately, it only worked for out-of-tree builds whose `@srcdir@` did not contain the string `../`.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32382Stop messing with HardwareAccel option2020-06-27T13:48:55ZNick MathewsonStop messing with HardwareAccel optionWe have some old code that modifies the options in place; we try to avoid doing that, however, since it can confuse users.
One instance is when we see that AccelName is set, but HardwareAccel is not. Let's fix that, since I'm touching ...We have some old code that modifies the options in place; we try to avoid doing that, however, since it can confuse users.
One instance is when we see that AccelName is set, but HardwareAccel is not. Let's fix that, since I'm touching this code anyway.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32385doxygen: respect --enable-fatal-warnings2021-07-22T16:19:07ZNick Mathewsondoxygen: respect --enable-fatal-warningsDoxygen has an option to fail with an error if any warning message occurs. We can enable it, if we disable missing documentation warnings. We should have another option to turn missing documentation warnings back on.Doxygen has an option to fail with an error if any warning message occurs. We can enable it, if we disable missing documentation warnings. We should have another option to turn missing documentation warnings back on.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32386Doxygen: Make output more C-like2020-06-27T13:48:55ZNick MathewsonDoxygen: Make output more C-likeThere are a couple of options we should set to make our doxygen output more C-like and less C++-like.
The TYPEDEF_HIDES_STRUCT option tells doxygen to handle `typedef struct foo_t foo_t` by making `foo_t` and `struct foo_t` synonymous. ...There are a couple of options we should set to make our doxygen output more C-like and less C++-like.
The TYPEDEF_HIDES_STRUCT option tells doxygen to handle `typedef struct foo_t foo_t` by making `foo_t` and `struct foo_t` synonymous. This lets doxygen find documentation that it would otherwise miss: otherwise, if it sees documentation for "int func(foo_t *)" and a prototype for "int func(struct foo_t)", it will think that the prototype is undocumented.
The HIDE_SCOPE_NAMES option tells doxygen to describe a member "member" of a struct "container" as "member", not "container::member".Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32387Doxygen: enable source code browser2020-06-27T13:48:54ZNick MathewsonDoxygen: enable source code browserDoxygen has support for outputting an annotated cross-referenced version of our C source. We should enable this to make it more useful.Doxygen has support for outputting an annotated cross-referenced version of our C source. We should enable this to make it more useful.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32399Fix "make test-stem" after merging #32339 and #323442020-06-27T13:48:54ZteorFix "make test-stem" after merging #32339 and #32344In legacy/trac#32339 and legacy/trac#32344, we broke "make test-stem", but we didn't notice before merging, because "make test-stem" is allow_failure in Travis CI.
It looks like we need to get stem to launch a new tor process for more t...In legacy/trac#32339 and legacy/trac#32344, we broke "make test-stem", but we didn't notice before merging, because "make test-stem" is allow_failure in Travis CI.
It looks like we need to get stem to launch a new tor process for more tests. Or our immutability checks are too strict.
Here is one of the errors:
```
======================================================================
FAIL: test_take_ownership_via_controller
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/dev/stem/stem/util/test_tools.py", line 152, in <lambda>
self.method = lambda test: self.result(test) # method that can be mixed into TestCases
File "/home/dev/stem/stem/util/test_tools.py", line 227, in result
test.fail(self._result.msg)
AssertionError: Traceback (most recent call last):
File "/home/dev/stem/stem/util/test_tools.py", line 169, in _wrapper
runner(*args) if args else runner()
File "/home/dev/stem/test/integ/process.py", line 641, in test_take_ownership_via_controller
take_ownership = True,
File "/home/dev/stem/stem/process.py", line 285, in launch_tor_with_config
return launch_tor(tor_cmd, ['-f', '-'], None, completion_percent, init_msg_handler, timeout, take_ownership, close_output, stdin = config_str)
File "/home/dev/stem/stem/process.py", line 158, in launch_tor
raise OSError('Process terminated: %s' % last_problem)
OSError: Process terminated: Failed to bind one of the listener ports.
----------------------------------------------------------------------
```Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32401Fix variable typos in configure's lzma and zstd support2020-06-27T13:48:53ZteorFix variable typos in configure's lzma and zstd supportNo user-visible changes, so no changes file required.No user-visible changes, so no changes file required.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32402Actually check most shell scripts for errors2020-06-27T13:48:53ZteorActually check most shell scripts for errorsThe find command in checkShellScripts.sh is wrong.The find command in checkShellScripts.sh is wrong.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32404Add a CFLG_OBSOLETE flag, and handle it at the confvar layer2020-06-27T13:48:53ZteorAdd a CFLG_OBSOLETE flag, and handle it at the confvar layerFollow up to legacy/trac#32295 for 0.4.3.
nickm says:
My suggestion would be to change how OBSOLETE is implemented: it doesn't really make sense as a type. Instead, there should be an "empty" type for fields that can't be read or writt...Follow up to legacy/trac#32295 for 0.4.3.
nickm says:
My suggestion would be to change how OBSOLETE is implemented: it doesn't really make sense as a type. Instead, there should be an "empty" type for fields that can't be read or written, and a CFLG_OBSOLETE flag that causes these warnings. The CFLG_OBSOLETE flag should be handled at the confvar layer, I think.
This is a bug caused by sponsor 31, so it's a must-have.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32406Add ability to make an accelname required.2020-06-27T13:48:53ZNick MathewsonAdd ability to make an accelname required.This will help test legacy/trac#30866.This will help test legacy/trac#30866.Tor: 0.4.3.x-final