The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:49:21Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31772MAPADDRESS control command2020-06-27T13:49:21ZTracMAPADDRESS control commandI'm using the control socket to execute MAPADDRESS commands.
Since TorBrowser 8.5.5 (Linux64) with Tor 0.4.1.5 the behavior changed.
On TorBrowser 8.5.4 (Linux64) with Tor 0.4.0.5 the following command worked:
MAPADDRESS *.torproject.o...I'm using the control socket to execute MAPADDRESS commands.
Since TorBrowser 8.5.5 (Linux64) with Tor 0.4.1.5 the behavior changed.
On TorBrowser 8.5.4 (Linux64) with Tor 0.4.0.5 the following command worked:
MAPADDRESS *.torproject.org=127.0.0.1
250 *.torproject.org=127.0.0.1
On TorBrowser 8.5.5 (Linux64) with Tor 0.4.1.5 the following happens:
MAPADDRESS *.torproject.org=127.0.0.1
512 syntax error: not enough arguments to mapaddress.
However, I found out that the following works:
MAPADDRESS foo *.torproject.org=127.0.0.1
250 *.torproject.org=127.0.0.1
I could not find any information about a change in the MAPADDRESS command specification.
Did the MAPADDRESS command change or may this be a bug in the command parsing?
**Trac**:
**Username**: kowenkiTor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31770Divide connection_edge.c into separate files.2020-10-22T15:12:32ZNick MathewsonDivide connection_edge.c into separate files.The connection_edge.c file was already above our threshold for file size, and in 0.4.2.x it has gotten bigger. Practracker is warning about it; let's split it up.The connection_edge.c file was already above our threshold for file size, and in 0.4.2.x it has gotten bigger. Practracker is warning about it; let's split it up.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31769-Wextra-semi causes build failure on debian bullseye2020-06-27T13:49:22ZNick Mathewson-Wextra-semi causes build failure on debian bullseyeFrom jenkins: https://jenkins.torproject.org/job/tor-ci-linux-master/ARCHITECTURE=amd64,SUITE=bullseye/4153/consoleFull
```
09:00:39 cc1: warning: command line option '-Wextra-semi' is valid for C++/ObjC++ but not for C
```
The logical...From jenkins: https://jenkins.torproject.org/job/tor-ci-linux-master/ARCHITECTURE=amd64,SUITE=bullseye/4153/consoleFull
```
09:00:39 cc1: warning: command line option '-Wextra-semi' is valid for C++/ObjC++ but not for C
```
The logical solution here is to remove the flag.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31766INTERNAL_ERROR in map_anon.c2020-06-27T13:49:22ZTracINTERNAL_ERROR in map_anon.cThe following is seen with Tor v0.4.1.5 on start up. No problem with the prior release (0.4.0.5).
This is built and is running on CentOS v6.10/x86_64, in an OpenVZ container. Please let me know if I can provide any further information...The following is seen with Tor v0.4.1.5 on start up. No problem with the prior release (0.4.0.5).
This is built and is running on CentOS v6.10/x86_64, in an OpenVZ container. Please let me know if I can provide any further information, or do any testing, to resolve this.
Please see attached file "tor-0.4.1.5-fault-output.txt" for full fault output.
----------------------------------
INTERNAL ERROR: Raw assertion failed at src/lib/malloc/map_anon.c:213: nodump_result == 0/usr/bin/tor(dump_stack_symbols_to_error_fds+0x33)[0x2af1bc71bda3]
/usr/bin/tor(tor_raw_assertion_failed_msg_+0x91)[0x2af1bc71c6a1]
**Trac**:
**Username**: tmpname0901https://gitlab.torproject.org/tpo/core/tor/-/issues/31762Add GETINFO dir/status-vote/current/consensus-microdesc to the control spec2020-06-27T13:49:22ZteorAdd GETINFO dir/status-vote/current/consensus-microdesc to the control specHere:
https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n811
With "added in Tor 0.4.3.1-alpha"Here:
https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n811
With "added in Tor 0.4.3.1-alpha"Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31759Make "annotate_ifdef_directives" script comply with line-width limits2020-06-27T13:49:22ZNick MathewsonMake "annotate_ifdef_directives" script comply with line-width limitsRight now, our annotate_ifdef_directives script generates output that is wider than 80 columns. This is okay for now, when we're applying it by hand, but won't be okay in the long run, when we eventually want to have autostyle run befor...Right now, our annotate_ifdef_directives script generates output that is wider than 80 columns. This is okay for now, when we're applying it by hand, but won't be okay in the long run, when we eventually want to have autostyle run before every commit.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31757test_parseconf.sh: apparently not reliable on Appveyor2022-06-17T16:18:40ZNick Mathewsontest_parseconf.sh: apparently not reliable on AppveyorFor some reason, I'm seeing intermittent failure from test_parseconf on appveyor. Since we're close to a release, I think that for now I should make this test become allowed-to-fail on windows for now, and investigate it more after 0.4....For some reason, I'm seeing intermittent failure from test_parseconf on appveyor. Since we're close to a release, I think that for now I should make this test become allowed-to-fail on windows for now, and investigate it more after 0.4.2.1-alpha is released.https://gitlab.torproject.org/tpo/core/tor/-/issues/31756Cover all configuration options with test_parseconf.sh2022-06-17T13:41:03ZNick MathewsonCover all configuration options with test_parseconf.shWe now have a shell script to test whether parsing different configuration options works. Right now there are some options it can't test, however, since they only work on some platforms. There are also some that we aren't testing with ...We now have a shell script to test whether parsing different configuration options works. Right now there are some options it can't test, however, since they only work on some platforms. There are also some that we aren't testing with it yet--and a bunch of remaining error cases that it doesn't test.
Let's see if we can get all of our options tested.https://gitlab.torproject.org/tpo/core/tor/-/issues/31754Add HS DoS defence stats to heartbeat2022-10-11T23:39:34ZGeorge KadianakisAdd HS DoS defence stats to heartbeatWe should add entries to our heartbeat about the new DoS defences we added to see how helpful and prevalent they are.
In particular:
- We should mention how many single-hop connections we blocked (legacy/trac#24962)
- How many times we ...We should add entries to our heartbeat about the new DoS defences we added to see how helpful and prevalent they are.
In particular:
- We should mention how many single-hop connections we blocked (legacy/trac#24962)
- How many times we applied rate-limiting as an introduction point (legacy/trac#15516).
(Marking this as easy since the heartbeat module is not too hard to figure out)Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31742Write a script or makefile target to install git hooks2020-06-27T20:23:24Zrl1987Write a script or makefile target to install git hooksAt this point we have to manually copy git hook scripts into .git/hooks directory and make them executable. Having a scripted way to do this would be more convenient.At this point we have to manually copy git hook scripts into .git/hooks directory and make them executable. Having a scripted way to do this would be more convenient.https://gitlab.torproject.org/tpo/core/tor/-/issues/31737Change handling of relative paths in %include directives?2022-09-01T21:42:48ZNick MathewsonChange handling of relative paths in %include directives?Right now, relative paths in %include directives are handled relative to Tor's working directory, which doesn't make a lot of sense. Handling them relative to the configuration file might make more sense?
We'd want to figure out a way ...Right now, relative paths in %include directives are handled relative to Tor's working directory, which doesn't make a lot of sense. Handling them relative to the configuration file might make more sense?
We'd want to figure out a way to handle this that won't break existing users.https://gitlab.torproject.org/tpo/core/tor/-/issues/31736Stop using mutex_destroy(), when multiple threads can still access the mutex2020-07-14T22:24:26ZteorStop using mutex_destroy(), when multiple threads can still access the mutexPart of legacy/trac#31614, alternative to legacy/trac#31735.
If we can't join all the threads before destroying a mutex (legacy/trac#31735), and we can't otherwise prevent multiple thread access, we should stop destroying that mutex. (B...Part of legacy/trac#31614, alternative to legacy/trac#31735.
If we can't join all the threads before destroying a mutex (legacy/trac#31735), and we can't otherwise prevent multiple thread access, we should stop destroying that mutex. (Because destroying a locked thread invokes undefined behaviour.)
There may be some other pattern that helps us destroy all but one mutex. But that involves a "mutex-destruction" mutex. Which is terribly complex.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31735Exit and join all threads, before destroying any mutexes in the main thread2022-06-17T17:38:26ZteorExit and join all threads, before destroying any mutexes in the main threadOtherwise, the mutex could be locked by another thread, and destroying a locked mutex triggers undefined behaviour.
~~Part of legacy/trac#31614.~~
Updated to add:
Instead of exiting and joining threads, we can initialize the mutex onc...Otherwise, the mutex could be locked by another thread, and destroying a locked mutex triggers undefined behaviour.
~~Part of legacy/trac#31614.~~
Updated to add:
Instead of exiting and joining threads, we can initialize the mutex once, and never destroy it. If we use a sentinel value, like log_mutex_initialized, then we won't re-initialize the mutex when we re-initialize everything else.https://gitlab.torproject.org/tpo/core/tor/-/issues/31734Add accessor functions for cb_buf, which enforce locking and unlocking2020-07-14T22:24:25ZteorAdd accessor functions for cb_buf, which enforce locking and unlockingPart of legacy/trac#31614Part of legacy/trac#31614Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31713Automatically run the autostyle scripts before every commit2020-07-29T13:03:12ZteorAutomatically run the autostyle scripts before every commitLet's try out our auto-formatting workflow by running:
scripts/maint/rectify_include_paths.py .
before every commit.
We occasionally miss include paths:
https://github.com/torproject/tor/pull/1319/commits/a90d1918af5d2b6c6e6dd2c0797f8a6...Let's try out our auto-formatting workflow by running:
scripts/maint/rectify_include_paths.py .
before every commit.
We occasionally miss include paths:
https://github.com/torproject/tor/pull/1319/commits/a90d1918af5d2b6c6e6dd2c0797f8a63d4042bfa
We should only ever run auto-formatting on master.
Edited to add:
We'll need to use a similar strategy to practracker, where we check for the presence of a file before running the autostyle scripts.
We can't use "make autostyle" directly, because some commit directories haven't run configure, so they don't have a Makefile. Instead, we should do what we do with all the other hook scripts, and copy the code from "make autostyle" to the hook. (Or even better, create a style script, and call it from "make autostyle" and the hook.)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31707Better handling and UX for missing and expired guard descriptors2022-06-16T19:40:07ZteorBetter handling and UX for missing and expired guard descriptorsSplit off legacy/trac#31657:
Replying to teor:
> How do we reliably detect pathological cases?
> Suppress the message, until it occurs a few times within a short timeframe?
dgoulet:
That's a good question I don't have an answer for.
...Split off legacy/trac#31657:
Replying to teor:
> How do we reliably detect pathological cases?
> Suppress the message, until it occurs a few times within a short timeframe?
dgoulet:
That's a good question I don't have an answer for.
Unfortunately, I don't think that's the kind of message that occurs multiple times, looking at legacy/trac#30746 (and friends) this seems to be able to cause havoc with just a single repeatition.
I'm not sure why this is the case, since `router_have_minimum_dir_info()` seems to be called all the time and that should eventually call `entry_guards_get_err_str_if_dir_info_missing()` which is the source of the log message... Things are kinda messy between these two functions tho, so it's kinda hard to understand what's the issue.https://gitlab.torproject.org/tpo/core/tor/-/issues/31706Expose config flags to the controller2022-06-17T17:40:58ZteorExpose config flags to the controllerIn legacy/trac#31625, we refactored the config behaviours into an orthogonal set of flags.
We should expose at least settable to the controller. We may decide to expose them all.In legacy/trac#31625, we refactored the config behaviours into an orthogonal set of flags.
We should expose at least settable to the controller. We may decide to expose them all.https://gitlab.torproject.org/tpo/core/tor/-/issues/31705Add sufficient coccinelle tooling to run coccinelle without stress2020-06-27T13:49:24ZNick MathewsonAdd sufficient coccinelle tooling to run coccinelle without stressI think we need two pieces of coccinelle tooling to be able to use it effectively:
1) A script that tells us which files have parsing problems.
2) A script to invoke spatch with the right arguments.
Based on 1 and 2, we can improve ou...I think we need two pieces of coccinelle tooling to be able to use it effectively:
1) A script that tells us which files have parsing problems.
2) A script to invoke spatch with the right arguments.
Based on 1 and 2, we can improve our tor-coccinelle.h file to handle more of our codebase, and we can apply coccinelle scripts without trying to remember the name of the "-macro-file-builtins" flag.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31699Remove unused configure.ac checks2021-07-09T17:22:51ZNick MathewsonRemove unused configure.ac checksHere is a little script to find macros in orconfig.h.in that are not actually mentioned in our code:
```
#/bin/bash
for macroname in $(grep '#undef' orconfig.h.in | awk -e '{ print $2; }') ; do
git grep -l "$macroname" src >/dev/null...Here is a little script to find macros in orconfig.h.in that are not actually mentioned in our code:
```
#/bin/bash
for macroname in $(grep '#undef' orconfig.h.in | awk -e '{ print $2; }') ; do
git grep -l "$macroname" src >/dev/null || echo "$macroname"
done
```
Some of these macros are used in system header files, but we can safely remove the autoconf checks for the ones that are not. I think they are:
```
HAVE_EVENT2_BUFFEREVENT_SSL_H
HAVE_EVENT2_DNS_H
HAVE_EVENT2_EVENT_H
HAVE_EVP_SHA3_256
HAVE_GETPASS
HAVE_HTONLL
HAVE_LIBCAP
HAVE_MALLOC_MALLOC_H
HAVE_MALLOC_NP_H
HAVE_STRUCT_TCP_INFO_TCPI_SND_MSS
HAVE_STRUCT_TCP_INFO_TCPI_UNACKED
HAVE_SYS_SYSLIMITS_H
HAVE_U_CHAR
SRCDIR
```https://gitlab.torproject.org/tpo/core/tor/-/issues/31698Reconsider HAVE_XXX_H usage in the Tor code2021-09-16T14:22:37ZAlexander Færøyahf@torproject.orgReconsider HAVE_XXX_H usage in the Tor codeWe currently sometimes have code like:
```
#ifdef HAVE_STRING_H
# include <string.h>
#endif
```
But we don't expect to work on systems that do not have, for example, string.h available. We should not do these check in every .c and .h ...We currently sometimes have code like:
```
#ifdef HAVE_STRING_H
# include <string.h>
#endif
```
But we don't expect to work on systems that do not have, for example, string.h available. We should not do these check in every .c and .h file, but instead just have our configure script fail if these headers are not available.