Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:18:19Zhttps://gitlab.torproject.org/legacy/trac/-/issues/4426"[warn] Hidden service with no ports configured; ignoring." should print Hidd...2020-06-13T14:18:19ZRobert Ransom"[warn] Hidden service with no ports configured; ignoring." should print HiddenServiceDirWe just had a user in #tor ask for help configuring a hidden service. He/she/it was using Windows, and had put an extra backslash at the end of the HiddenServiceDir line; Tor interpreted this as meaning that that option was continued on...We just had a user in #tor ask for help configuring a hidden service. He/she/it was using Windows, and had put an extra backslash at the end of the HiddenServiceDir line; Tor interpreted this as meaning that that option was continued on the next line.
If we included the HiddenServiceDir in that log line, (a) users with many HSes would have less trouble finding their mistake, and (b) users who make a trailing-backslash mistake (or the people whom they ask for help) will be able to figure out their problem more quickly.Tor: 0.2.2.x-finalRobert RansomRobert Ransomhttps://gitlab.torproject.org/legacy/trac/-/issues/1882"Failed to find node for hop 0 of our path. Discarding this circuit." log spa...2020-06-13T14:06:09ZSebastian Hahn"Failed to find node for hop 0 of our path. Discarding this circuit." log spam after guard went downI noticed this issue with my torperf setup. A tor client that is started with a single node allowed as entry node will freak out if that entry guard goes offline, however briefly.
It keeps logging "Failed to find node for hop 0 of our p...I noticed this issue with my torperf setup. A tor client that is started with a single node allowed as entry node will freak out if that entry guard goes offline, however briefly.
It keeps logging "Failed to find node for hop 0 of our path. Discarding this circuit." repeatedly, and doesn't seem to recover well at all. I wonder if that means that we are also willing to give up on guards in a regular setup as soon as they go down once, and stop using them.
This might be related to issue #675Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5402#5090 allows post-auth heap overflow2020-06-13T14:18:16ZRoger Dingledine#5090 allows post-auth heap overflowRobert Connolly from Matta Consulting reports that the config parsing bug in #5090 (which he found independently) is exploitable.
Examples for triggering it include
```
SETCONF aaaa="bbbbbbbbbbbb\x"bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb...Robert Connolly from Matta Consulting reports that the config parsing bug in #5090 (which he found independently) is exploitable.
Examples for triggering it include
```
SETCONF aaaa="bbbbbbbbbbbb\x"bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
```
and setting a torrc line of
```
ContactInfo "Here I \x"amaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
```
Fortunately, it looks like it can only be triggered once you've authenticated to the control port (in which case you can already screw the user) or if you can edit the torrc file (same). So it's not harmful.
Is that really true? Are there any other instances of the bug? Any other ways of reaching it? Does the different trust model for the control socket change the above paragraph?
Jake opened #5210 to avoid future things like this being exploitable in practice.
And Nick points out:
```
We ought to audit uses of get_escaped_string_length in control.c
nevertheless. It is a *PHENOMINALLY BAD IDEA* in C to have
independent functions that count the length of something and that
parse it. We should look for other cases of that antipattern too.
```
(This ticket started out as a secteam discussion, until we decided that it didn't look like a remote execution bug.)Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/3963'--service install' does not prevent Tor from running normally2020-06-13T14:13:09ZRobert Ransom'--service install' does not prevent Tor from running normally```
C:\WORK\Tor\bin>tor --service install -f C:/WORK/Tor/etc/torrc
OpenSCManager() failed : Access is denied.
Sep 08 14:00:02.451 [notice] Tor v0.2.2.32 (git-877e17749725ab88). This is experimental software. Do not rely on it for strong...```
C:\WORK\Tor\bin>tor --service install -f C:/WORK/Tor/etc/torrc
OpenSCManager() failed : Access is denied.
Sep 08 14:00:02.451 [notice] Tor v0.2.2.32 (git-877e17749725ab88). This is experimental software. Do not rely on it for strong anonymity. (Running on Windows 7 [workstation])
Sep 08 14:00:02.451 [warn] Failed to parse/validate config: Unknown option 'service'. Failing.
Sep 08 14:00:02.451 [err] Reading config failed--see warnings above.
C:\WORK\Tor\bin>
```Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1125(*chp)->next assertion fail?2020-06-13T14:02:52ZRoger Dingledine(*chp)->next assertion fail?I found this on irc. So I have no idea if it's for real. The person indicated
it was on 0.2.2.5-alpha.
[Info] buf_shrink_freelists():
Cleaning freelist for 4096-byte chunks: keeping 9, dropping 1.
[Error] Bug: buffers.c:269: buf_shrink_...I found this on irc. So I have no idea if it's for real. The person indicated
it was on 0.2.2.5-alpha.
[Info] buf_shrink_freelists():
Cleaning freelist for 4096-byte chunks: keeping 9, dropping 1.
[Error] Bug: buffers.c:269: buf_shrink_freelists: Assertion
(*chp)->next fail
He also said "polipo still not starting with vidalai 2.5", so I'm thinking
probably Windows.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/3222+LOADCONF control port command is not documented in control-spec.txt2020-06-13T14:10:42ZRobert Ransom+LOADCONF control port command is not documented in control-spec.txtTor (on maint-0.2.2) implements a control port command named `+LOADCONF`, but control-spec.txt doesn't mention it at all.Tor (on maint-0.2.2) implements a control port command named `+LOADCONF`, but control-spec.txt doesn't mention it at all.Tor: 0.2.2.x-finalRobert RansomRobert Ransomhttps://gitlab.torproject.org/legacy/trac/-/issues/43400.2.2 relays crash without geoip files2020-06-13T14:14:08ZNick Mathewson0.2.2 relays crash without geoip filesFound via chutney:
```
#0 0x00078878 in geoip_note_client_seen (action=GEOIP_CLIENT_NETWORKSTATUS, addr=2130706433, now=1319812719) at geoip.c:439
#1 0x00057cd6 in directory_handle_command (conn=0x21a3d0) at directory.c:2703
#2 0x0005...Found via chutney:
```
#0 0x00078878 in geoip_note_client_seen (action=GEOIP_CLIENT_NETWORKSTATUS, addr=2130706433, now=1319812719) at geoip.c:439
#1 0x00057cd6 in directory_handle_command (conn=0x21a3d0) at directory.c:2703
#2 0x000590e7 in connection_dir_process_inbuf (conn=0x21a3d0) at directory.c:2162
#3 0x0002deb4 in connection_process_inbuf (conn=0x21a3d0, package_partial=<value temporarily unavailable, due to optimizations>) at connection.c:3363
#4 0x000328ae in connection_handle_read (conn=0x21a3d0) at connection.c:2524
#5 0x000806bf in conn_read_callback (fd=15, event=2, _conn=0x21a3d0) at main.c:514
warning: .o file "/Users/nickm/src/libevent-1.4/.libs/event.o" more recent than executable timestamp
#6 0x001a8911 in event_base_loop (base=0x806400, flags=0) at event.c:401
#7 0x0007df52 in do_main_loop () at main.c:1566
#8 0x0007f73b in tor_main (argc=0, argv=0x0) at main.c:2228
#9 0x00002426 in start ()
```
For some reason, I haven't seen this in master yet.
What shall we do? The easiest option is to make geoip_note_client_seen() return early if geoip_countries is NULL. But perhaps we should go over the whole file to look for other places where we might be saying "smartlist_len(geoip_countries)" without first making sure geoip_countries is set. And perhaps also we should disallow being an authority without a geoip file.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/50310.2.2.35 doesn't cache microdescriptors2020-06-13T14:17:07ZSebastian Hahn0.2.2.35 doesn't cache microdescriptorsLooks like we broke something in maint so that we don't cache microdescriptors anymore, at least on fluxe3 I see 0-byte files in its datadir. Hrm.Looks like we broke something in maint so that we don't cache microdescriptors anymore, at least on fluxe3 I see 0-byte files in its datadir. Hrm.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24500.2.2.x manpage mentions country codes for 0.2.2.x EntryNodes option2020-06-13T14:08:27ZSebastian Hahn0.2.2.x manpage mentions country codes for 0.2.2.x EntryNodes option... which isn't supported until 0.2.3.x.... which isn't supported until 0.2.3.x.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/2442A bunch of hidden service warnings should be protocol warnings2020-06-13T14:08:26ZSebastian HahnA bunch of hidden service warnings should be protocol warningsWe've had quite a few reports about log messages such as:
```
Possible replay detected! We received an INTRODUCE2 cell with same first part of Diffie-Hellman handshake 5 seconds ago.
```
and
```
INTRODUCE2 cell is too old. Discarding
``...We've had quite a few reports about log messages such as:
```
Possible replay detected! We received an INTRODUCE2 cell with same first part of Diffie-Hellman handshake 5 seconds ago.
```
and
```
INTRODUCE2 cell is too old. Discarding
```
These are messages that an operator can't do anything about, and they should be in the protocol warnings category instead.Tor: 0.2.2.x-finalRobert RansomRobert Ransomhttps://gitlab.torproject.org/legacy/trac/-/issues/5969A couple of compile warnings with clang 3.12020-06-13T14:19:53ZSebastian HahnA couple of compile warnings with clang 3.1First one is
```
crypto.c:1888:38: error: size argument in 'strlcpy' call appears to be size of
the source; expected the size of the destination
[-Werror,-Wstrlcpy-strlcat-size]
strlcpy(fname_new, fname, strlen(fname) + 8...First one is
```
crypto.c:1888:38: error: size argument in 'strlcpy' call appears to be size of
the source; expected the size of the destination
[-Werror,-Wstrlcpy-strlcat-size]
strlcpy(fname_new, fname, strlen(fname) + 8);
~~~~~~~^~~~~~~~~~
```
second one is
```
compat.c:362:28: error: format string is not a string literal
[-Werror,-Wformat-nonliteral]
r = vsnprintf(str, size, format, args);
~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
/usr/include/secure/_stdio.h:72:63: note: expanded from macro 'vsnprintf'
__builtin___vsnprintf_chk (str, len, 0, __darwin_obsz(str), format, ap)
^
compat.c:412:32: error: format string is not a string literal
[-Werror,-Wformat-nonliteral]
int r = vasprintf(&strp_tmp, fmt, args);
^~~
```Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4838A directory cache will never purge some old descriptors2020-06-13T14:16:33ZTracA directory cache will never purge some old descriptorsBy default, caches don't try to download v2 statuses so have_enough_v2 in routerlist_remove_old_routers() is always false. This is similar to #3543.
I've come up with this modification to check whether we do v2 at all:
```
+ const or_o...By default, caches don't try to download v2 statuses so have_enough_v2 in routerlist_remove_old_routers() is always false. This is similar to #3543.
I've come up with this modification to check whether we do v2 at all:
```
+ const or_options_t *options = get_options();
have_enough_v2 = !caches ||
+ !(authdir_mode_any_main(options) || options->FetchV2Networkstatus) ||
(networkstatus_v2_list &&
smartlist_len(networkstatus_v2_list) > get_n_v2_authorities() / 2);
```
**Trac**:
**Username**: fermenthorTor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/3200After you setconf a bridge you can still reuse old circuits2020-06-13T14:10:37ZRoger DingledineAfter you setconf a bridge you can still reuse old circuitsOne of #2355's patches implies that you can reuse old circuits after you setconf a bridge. I just confirmed it on my Tor client.
(This is #1090 related too.)One of #2355's patches implies that you can reuse old circuits after you setconf a bridge. I just confirmed it on my Tor client.
(This is #1090 related too.)Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/3049Allow a Tor process to be ‘owned’ by a controller process2020-06-13T14:37:21ZRobert RansomAllow a Tor process to be ‘owned’ by a controller processCurrently, most Vidalia users allow Vidalia to start Tor with a new, randomly generated control port password, so if Vidalia crashes, Tor will keep running in the background, but nothing will be able to connect to its control port. This...Currently, most Vidalia users allow Vidalia to start Tor with a new, randomly generated control port password, so if Vidalia crashes, Tor will keep running in the background, but nothing will be able to connect to its control port. This has (at least) two negative consequences: (a) when the user starts Vidalia again, Vidalia will be unable to start a new Tor instance because the old one is still listening on port 9051, and (b) on Windows, the only way to stop the orphaned Tor process without using the control port is equivalent to the Unix SIGKILL, which sucks if that Tor instance is running as a bridge or relay.
We should add a new OwningControllerPID option to Tor, to specify a process which Tor should try to not outlive, and a new TAKEOWNERSHIP control port command to specify that Tor should shut down if that control port connection closes.Tor: 0.2.2.x-finalRobert RansomRobert Ransomhttps://gitlab.torproject.org/legacy/trac/-/issues/2972Allow ControlSocket to be group writable2020-06-13T14:09:53ZLunarAllow ControlSocket to be group writableThis is an attempt to move <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552556> foward.
Right now, ControlPort + CookieAuthFileGroupReadable offers a way for specific users (members of the same group as the Tor process) to controel...This is an attempt to move <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552556> foward.
Right now, ControlPort + CookieAuthFileGroupReadable offers a way for specific users (members of the same group as the Tor process) to controel a system-wide Tor daemon. It would be great to have a similar access control mechanism for ControlSocket.
The attached patch is an attempt to implement such behaviour. It adds a new configuration option, `UnixSocketsGroupWritable`, which when enabled, will make socket `g+rw` upon creation.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/2153Annotation rules not adequately enforced.2020-06-13T14:07:25ZNick MathewsonAnnotation rules not adequately enforced.piebeer on IRC found some potentially nasty bugs in annotation parsing.
Possible fixes in my branch "annotations_fixes". Please review.
I'm tagging this for 0.2.2.x for now, but it is a backport candidate if we're going to do another...piebeer on IRC found some potentially nasty bugs in annotation parsing.
Possible fixes in my branch "annotations_fixes". Please review.
I'm tagging this for 0.2.2.x for now, but it is a backport candidate if we're going to do another 0.2.1.x.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4457Assertion at startup on Windows 7 when socketpair fails2020-06-13T14:14:37ZTracAssertion at startup on Windows 7 when socketpair failsHello,
I talked to "Sebastian" and "helix" on the IRC, and they advised me to report my bug.
I used to run vidalia-bundle-0.2.1.28-0.2.10 but since a security problem was known I had to update it. I installed vidalia-bundle-0.2.2.33-0.2....Hello,
I talked to "Sebastian" and "helix" on the IRC, and they advised me to report my bug.
I used to run vidalia-bundle-0.2.1.28-0.2.10 but since a security problem was known I had to update it. I installed vidalia-bundle-0.2.2.33-0.2.15 and tor quit at the begining.
The error message are
-[Warning] Warning from libevent: evsig_init: socketpair: Permission denied [WSAEACCES ]
-[Warning] Warning from libevent: evthread_make_base_notifiable: socketpair: Permission denied [WSAEACCES ]
-[Error] Error from libevent: event.c:1413: Assertion base failed in event_base_get_method
The new alpha version is working correctly.
If you need to contact me, send me a mail, it's in my info :)
**Trac**:
**Username**: VigdisTor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/3607Assertion failure in start_writing_to_file2020-06-13T14:12:01ZTracAssertion failure in start_writing_to_fileJul 17 22:04:30.422 [Error] start_writing_to_file(): Bug: util.c:1802: start_writing_to_file: Assertion (open_flags & (O_BINARY|O_TEXT)) != 0 failed; aborting.
**Trac**:
**Username**: MorbidJul 17 22:04:30.422 [Error] start_writing_to_file(): Bug: util.c:1802: start_writing_to_file: Assertion (open_flags & (O_BINARY|O_TEXT)) != 0 failed; aborting.
**Trac**:
**Username**: MorbidTor: 0.2.2.x-finalRobert RansomRobert Ransomhttps://gitlab.torproject.org/legacy/trac/-/issues/1868Assertion n_to_skip + n_to_free == freelists[i].cur_length failed2020-06-13T14:06:08ZTracAssertion n_to_skip + n_to_free == freelists[i].cur_length failedAug 26 03:26:49.050 [Info] directory_send_command(): Downloading consensus from XXX.XXX.XXX.XXX:443 using /tor/status-vote/current/consensus/14C131+27B6B5+49015F+585769+805509+D586D1+E8A9C4+ED03BB.z
Aug 26 03:26:49.050 [Info] run_connect...Aug 26 03:26:49.050 [Info] directory_send_command(): Downloading consensus from XXX.XXX.XXX.XXX:443 using /tor/status-vote/current/consensus/14C131+27B6B5+49015F+585769+805509+D586D1+E8A9C4+ED03BB.z
Aug 26 03:26:49.050 [Info] run_connection_housekeeping(): Expiring non-used OR connection to fd 1048 (XXX.XXX.XXX.XXX:4160) [idle 622].
Aug 26 03:26:49.050 [Info] buf_shrink_freelists(): Cleaning freelist for 4096-byte chunks: length 9, keeping 8, dropping 1.
Aug 26 03:26:49.050 [Error] buf_shrink_freelists(): Bug: buffers.c:281: buf_shrink_freelists: Assertion n_to_skip + n_to_free == freelists[i].cur_length failed; aborting.
Win7x64 Limited Account, vidalia x15 alpha (tor error)
If someone can remind me where the dumps in Windows are thrown I can fetch that also.
**Trac**:
**Username**: funkstarTor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4518assign_onionskin_to_cpuworker is too expensive2020-06-13T14:14:50ZNick Mathewsonassign_onionskin_to_cpuworker is too expensiveThe function "assign_onionskin_to_cpuworker()" is 20% of CPU usage on Moritz's profile. If that's so, the likeliest culprit is one of the functions getting inlined there: probably cull_wedged_cpuworkers, which does a linear walk over al...The function "assign_onionskin_to_cpuworker()" is 20% of CPU usage on Moritz's profile. If that's so, the likeliest culprit is one of the functions getting inlined there: probably cull_wedged_cpuworkers, which does a linear walk over all the connections.
(I'm guessing that connection_get_by_type_state, which also does a linear walk over all the connections, doesn't show up in the profile because, on a busy server, the average cpuworker is always busy, so assign_onionskin_to_cpuworker mostly gets called from cpuworker.c to assign an onionskin to a cpuworker that just became idle.)
The easiest fix for this would be to only call cull_wedged_cpuworkers every N seconds, or every N invocations of assign_onionskin_to_cpuworker(). This is easy enough that I'm marking this one for 0.2.2
If connection_get_by_type_state shows up in profiles, we can look into another data structure on connections.Tor: 0.2.2.x-final