The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:01:36Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15195systemd service doesn't work with ControlSocket2020-06-27T14:01:36ZTracsystemd service doesn't work with ControlSocketsystemd[1]: Starting Anonymizing overlay network for TCP...
tor[7288]: Mar 09 09:55:22.363 [notice] Tor v0.2.6.3-alpha (git-7df7e8d71d7afc42) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0
tor[7288]: Mar 09 09:55:22.363 [notic...systemd[1]: Starting Anonymizing overlay network for TCP...
tor[7288]: Mar 09 09:55:22.363 [notice] Tor v0.2.6.3-alpha (git-7df7e8d71d7afc42) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0
tor[7288]: Mar 09 09:55:22.363 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download
tor[7288]: Mar 09 09:55:22.363 [notice] This version is not a stable Tor release. Expect more bugs than usual.
tor[7288]: Mar 09 09:55:22.363 [notice] Read configuration file "/etc/tor/torrc".
tor[7288]: Mar 09 09:55:22.365 [notice] Caching new entry tor for tor
tor[7288]: Mar 09 09:55:22.365 [notice] Caching new entry tor for tor
tor[7288]: Mar 09 09:55:22.365 [notice] Not disabling debugger attaching for unprivileged users.
tor[7288]: Configuration was valid
tor[7291]: Mar 09 09:55:22.740 [notice] Tor v0.2.6.3-alpha (git-7df7e8d71d7afc42) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0
tor[7291]: Mar 09 09:55:22.740 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download
tor[7291]: Mar 09 09:55:22.740 [notice] This version is not a stable Tor release. Expect more bugs than usual.
tor[7291]: Mar 09 09:55:22.740 [notice] Read configuration file "/etc/tor/torrc".
tor[7291]: Mar 09 09:55:22.742 [notice] Opening Socks listener on 127.0.0.1:9050
tor[7291]: Mar 09 09:55:22.742 [notice] Caching new entry tor for tor
tor[7291]: Mar 09 09:55:22.742 [notice] Opening Control listener on /var/run/tor/control
tor[7291]: Mar 09 09:55:22.742 [warn] Could not unlink /var/run/tor/control: Permission denied
tor[7291]: Mar 09 09:55:22.742 [notice] Closing partially-constructed Socks listener on 127.0.0.1:9050
tor[7291]: Mar 09 09:55:22.742 [notice] Closing partially-constructed Socks listener on 127.0.0.1:9150
tor[7291]: Mar 09 09:55:22.742 [warn] Failed to parse/validate config: Failed to bind one of the listener ports.
tor[7291]: Mar 09 09:55:22.742 [err] Reading config failed--see warnings above.
systemd[1]: tor.service: main process exited, code=exited, status=255/n/a
To make it work, I need to add
ReadWriteDirectories = -/var/run/tor
and
CapabilityBoundingSet = CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_OVERRIDE CAP_CHOWN CAP_FOWNER
(the additional capabilities are CAP_DAC_OVERRIDE CAP_CHOWN CAP_FOWNER)
**Trac**:
**Username**: ponchoTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15199Build, Release, Distribute a Tor2web enabled version of Tor2020-06-27T14:01:36ZnaifBuild, Release, Distribute a Tor2web enabled version of TorThis ticket is to propose Tor Project to Build, Release, Distribute a Tor2web enabled version of Tor with the goal to make Tor2web setup process easier.
Today to setup a Tor2web system, an end-user must build a custom Tor version https:...This ticket is to propose Tor Project to Build, Release, Distribute a Tor2web enabled version of Tor with the goal to make Tor2web setup process easier.
Today to setup a Tor2web system, an end-user must build a custom Tor version https://github.com/globaleaks/Tor2web/wiki/Installation-Guide with a quite complex process.
If Tor would automatically build, release and distribute stable and experimental version of Tor with Tor2web enabled, it would become extremely easier to setup a Tor2web node.
Because Tor2web maybe dangerous for general use by end-user, as it's jeopardizing anonymity when connecting to Tor Hidden Service, it shall not be available as a general purpose download option on the Tor option page.
The Tor's binary with Tor2web enabled, shall be available only for Linux Debian and Ubuntu targets.
We may just create a wiki page on Trac that provide guidance for the build, release and distribution of Tor2web enabled version of Tor, as a way to enable only technical people understanding the context/scope of use how to use it.
The Hermes Center's team is available to support this process by volounteering to have it in-place and is kindly willing to support the Tor's developer time with tasty Italian Red Wine.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15202Second argument to strlcpy must always be NUL-terminated.2020-06-27T14:01:36ZNick MathewsonSecond argument to strlcpy must always be NUL-terminated.Even though strlcpy and strlcat stop copying their inputs when further bytes would fill up the output buffer, they keep reading the input string until they find a terminating NUL. This means that if you pass strlcpy or strlcat a non-NUL...Even though strlcpy and strlcat stop copying their inputs when further bytes would fill up the output buffer, they keep reading the input string until they find a terminating NUL. This means that if you pass strlcpy or strlcat a non-NUL-terminated argument, they will keep reading off into the heap, and potentially crash.
We do this in at least one place.
Found while investigating legacy/trac#15083. This can be remotely triggerable on some systems, depending on the behavior of malloc(), and on whether buffer freelists are turned on, and on the phase of the moon.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15203Incorrect port numbers hardcoded in config.c for moria12020-06-27T14:01:35ZTracIncorrect port numbers hardcoded in config.c for moria1While checking out the hardcoded directory authorities, I noticed that the OR and DIR port number for the first one, "moria1", do not correspond to the ones given by https://atlas.torproject.org/#search/128.31.0.39:
```
"moria1 orpor...While checking out the hardcoded directory authorities, I noticed that the OR and DIR port number for the first one, "moria1", do not correspond to the ones given by https://atlas.torproject.org/#search/128.31.0.39:
```
"moria1 orport=9101 "
"v3ident=D586D18309DED4CD6D57C18FDB97EFA96D330566 "
"128.31.0.39:9131 9695 DFC3 5FFE B861 329B 9F1A B04C 4639 7020 CE31",
```
https://gitweb.torproject.org/tor.git/tree/src/or/config.c#n853
According to atlas, the ports should be ORport=9005 and DirPort=9035 instead of ORport=9101 and DirPort=9131.
This might explain why my attempt to connect to the Tor network using a newly extracted TorBrowser, with my firewall blocking ports 80 and 443 failed.
P.S.: I think it might be worth adding a few more directory authorities with common ports like ssh,imap,smtp,ftp,etc for places with extreme firewalls. :)
Or maybe add the directory info in the tor browser bundle?
Is it possible to create/download "cached-microdescs" files from the tor atlas?
**Trac**:
**Username**: lomhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15205There's something fishy in OSX's checked strlcat.2020-06-27T14:01:35ZNick MathewsonThere's something fishy in OSX's checked strlcat.Have a look at https://opensource.apple.com/source/Libc/Libc-1044.1.2/secure/strlcat_chk.c .
When it checks to see whether the destination buffer overlaps with the input buffer in the second case, it isn't checking whether the input ove...Have a look at https://opensource.apple.com/source/Libc/Libc-1044.1.2/secure/strlcat_chk.c .
When it checks to see whether the destination buffer overlaps with the input buffer in the second case, it isn't checking whether the input overlaps with the actual buffer that *will* be written; it's checking whether the input overlaps with the destination buffer, _plus the extra space after the end of the destination buffer that would be written if there were enough room for the whole input._
I believe the second overlap check should be something more like:
```
__chk_overlap(dest, len, src, len - initial_dstlen - 1);
```
To do:
* Check whether any of the BSDs have this problem.
* Check whether older OSXs have this problem.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15206Update to March GeoIP2 database2020-06-27T14:01:35ZKarsten LoesingUpdate to March GeoIP2 database[geoip-mar2015](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-mar2015) contains the updated `geoip` file with IPv4 ranges and is supposed to be merged into maint-0.2.3.
[geoip6-mar2015](https://gitweb.torproject.org/karst...[geoip-mar2015](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-mar2015) contains the updated `geoip` file with IPv4 ranges and is supposed to be merged into maint-0.2.3.
[geoip6-mar2015](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip6-mar2015) contains the updated `geoip6` file with IPv6 ranges and is supposed to be merged into maint-0.2.4 (the first maint-* branch that contains a `geoip6` file).Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15211Audit all asserts to ensure they don't have side effects2020-06-27T14:01:35ZcypherpunksAudit all asserts to ensure they don't have side effectslegacy/trac#15188 fixed one instance, we should make sure there aren't more. Assignments are clearly bad, function calls are potentially bad. Anything else I'm looking for?legacy/trac#15188 fixed one instance, we should make sure there aren't more. Assignments are clearly bad, function calls are potentially bad. Anything else I'm looking for?Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15212Log link protocol version counts as part of heartbeat2020-06-27T14:01:35ZNick MathewsonLog link protocol version counts as part of heartbeatFor legacy/trac#9476, we want to kill off the v2 handshake. But as we do so (in 0.2.7 I hope), we'll want to see if we're getting spikes of v2 handshakes on older 0.2.6 servers, so we can work around that as appropriate.For legacy/trac#9476, we want to kill off the v2 handshake. But as we do so (in 0.2.7 I hope), we'll want to see if we're getting spikes of v2 handshakes on older 0.2.6 servers, so we can work around that as appropriate.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15215Use destination address type in SOCKS5 reply rather than AP address2020-06-27T14:01:34ZMatthew FinkelUse destination address type in SOCKS5 reply rather than AP addressWhen replying, checking the address family of the local address only works under the assumption that the local socket type is the same as the destination socket. This was true, until we began supporting AF_UNIX socksports. The result is ...When replying, checking the address family of the local address only works under the assumption that the local socket type is the same as the destination socket. This was true, until we began supporting AF_UNIX socksports. The result is now that when tor replies to an application over a unix socket, it specifies that it connected to an IPv6 address, when it's possible it connected to an IPv4 address. It seems like a good idea that we base this on the address family of the destination address.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15220Allow SocksSockets writable by arbitrary user2020-06-27T14:01:34ZMatthew FinkelAllow SocksSockets writable by arbitrary userlegacy/trac#12585 implemented SOCKSPort unix socket support, thus allowing proxying inet connections over a unix socket. Unfortunately, the config options only this SOCKSPort to be accessable for the Tor user, or at best, the Tor group (...legacy/trac#12585 implemented SOCKSPort unix socket support, thus allowing proxying inet connections over a unix socket. Unfortunately, the config options only this SOCKSPort to be accessable for the Tor user, or at best, the Tor group (i.e. debian-tor). This makes it quite unuseful for normal users who aren't usually members of that group. Perhaps a new config option should be added which specifies the file socket ownership.
(dgoulet reminded me SocksSocket was merged into SocksPort)Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15221Tor crash : bad syscall attempt (syscall prlimit64)2020-06-27T14:01:34ZcypherpunksTor crash : bad syscall attempt (syscall prlimit64)
SandBox 1
ControlSocket /var/run/tor/control
As soon I attach arm on the control socket , tor dies :
```
[Time...] [notice] Tor 0.2.7.0-alpha-dev (git-189f357f9790c30e) opening log file.
...
[Time...] [notice] New control connection o...
SandBox 1
ControlSocket /var/run/tor/control
As soon I attach arm on the control socket , tor dies :
```
[Time...] [notice] Tor 0.2.7.0-alpha-dev (git-189f357f9790c30e) opening log file.
...
[Time...] [notice] New control connection opened.
============================================================ T= 1426029732
(Sandbox) Caught a bad syscall attempt (syscall prlimit64)
/usr/sbin/tor(+0x15aaec)[0xb762faec]
linux-gate.so.1(__kernel_vsyscall+0x10)[0xb74b3bbc]
linux-gate.so.1(__kernel_vsyscall+0x10)[0xb74b3bbc]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(getrlimit64+0x2b)[0xb70a5bbb]
/usr/sbin/tor(set_max_file_descriptors+0x3a)[0xb7614d6a]
/usr/sbin/tor(+0xf9861)[0xb75ce861]
/usr/sbin/tor(connection_control_process_inbuf+0x260c)[0xb75d654c]
/usr/sbin/tor(+0xdd86d)[0xb75b286d]
/usr/sbin/tor(+0xe8d6f)[0xb75bdd6f]
/usr/sbin/tor(+0x2ac69)[0xb74ffc69]
/usr/lib/i386-linux-gnu/libevent-2.0.so.5(event_base_loop+0x73d)[0xb73df36d]
/usr/sbin/tor(do_main_loop+0x24d)[0xb750183d]
/usr/sbin/tor(tor_main+0x14e5)[0xb75046b5]
/usr/sbin/tor(main+0x35)[0xb74fd955]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xf3)[0xb6fdea63]
/usr/sbin/tor(+0x289a4)[0xb74fd9a4]
```Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15228Identify candidates for FallbackDir, and ship with a list of them2020-06-27T14:01:34ZNick MathewsonIdentify candidates for FallbackDir, and ship with a list of themBack long ago, we added a feature to allow torrc to list a bunch of FallbackDir entries. These tell a client where to look for consensus directory documents, so that the clients don't just load the authorities down.
It would be good if...Back long ago, we added a feature to allow torrc to list a bunch of FallbackDir entries. These tell a client where to look for consensus directory documents, so that the clients don't just load the authorities down.
It would be good if we shipped with such a list.
One idea has been to identify directories that have:
* a stable IP:Port over a long time,
* reasonably good uptime (as a fraction)
* good bandwidth
* a contact address.
Then, contact the admins of these directory caches and ask them for permission to put them on a list.
(See also legacy/trac#8374)Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15230Identify controller features desirable for testing support2020-06-27T14:01:34ZNick MathewsonIdentify controller features desirable for testing supportTor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15233Form a plan for killing off 0.2.2 and 0.2.32020-06-27T14:01:34ZNick MathewsonForm a plan for killing off 0.2.2 and 0.2.3legacy/trac#9476 is looking tricky; we should make a plan for what to do if it turns out maxmially tricky, and a plan for what to do when we're finally done with 0.2.3 as well.legacy/trac#9476 is looking tricky; we should make a plan for what to do if it turns out maxmially tricky, and a plan for what to do when we're finally done with 0.2.3 as well.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15234specification for module-level isolation in Tor2020-06-27T14:01:34ZNick Mathewsonspecification for module-level isolation in TorI've got to write up a document explaining how we'd like to get module-level isolation working in the Tor program.I've got to write up a document explaining how we'd like to get module-level isolation working in the Tor program.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15235Identify the state of IPv6 support in Tor2020-06-27T14:01:33ZNick MathewsonIdentify the state of IPv6 support in TorWhat works for IPv6 today? What doesn't? What's hard to configure?
* Can clients use ipv6 to connect to Tor?
* Can clients resolve Ipv6 addresses with Tor?
* Does automapping to ipv6 addresses work?
* Can we exit to ipv6?
* Can bridge...What works for IPv6 today? What doesn't? What's hard to configure?
* Can clients use ipv6 to connect to Tor?
* Can clients resolve Ipv6 addresses with Tor?
* Does automapping to ipv6 addresses work?
* Can we exit to ipv6?
* Can bridges be IPv6-only? (no, I don't think so)
* Can relays be IPv6 only? (no)
And many more.
We should ideally not only hand-check tehse issues, but write tests for some of them.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15236Identify functions most in need of testing, and hardest to test2020-06-27T14:01:33ZNick MathewsonIdentify functions most in need of testing, and hardest to testIn addition to our opportunistic write-tests-as-you-go approach, we should also direct our testing efforts on the functions that most *need* to be tested. This includes (possibly)
* Big functions
* Volatile functions (ones that hav...In addition to our opportunistic write-tests-as-you-go approach, we should also direct our testing efforts on the functions that most *need* to be tested. This includes (possibly)
* Big functions
* Volatile functions (ones that have changed many times)
* Functions that have had lots of bugs in them in the past
* Functions nobody understands
* Functions with high complexity
* Functions with high complexity-to-line ratio
* Functions with high code-to-comments ratio
We should also look at what's _hardest_ to test, including possibly
* Anything that hits the OS directly
* Anything that's windows only.
* Anything that calls many other functions
* Anything that calls many other modules
* Anything that indirectly calls most of the rest of Tor.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15240Tor starts PTs before creating the extended_orport_auth_cookie file they need2020-06-27T14:01:33ZJens KubiezielTor starts PTs before creating the extended_orport_auth_cookie file they needI'm using 0.2.5.10-1~d70.wheezy+1 from Debian and obfs4proxy 0.0.4-1 to set up a some bridges. My torrc looks like:
```
Address 192.0.2.23
OutboundBindAddress 192.0.2.23
OutboundBindAddress 2001:db8::94de
ORPort 56527
ExtORPort 55009
ORL...I'm using 0.2.5.10-1~d70.wheezy+1 from Debian and obfs4proxy 0.0.4-1 to set up a some bridges. My torrc looks like:
```
Address 192.0.2.23
OutboundBindAddress 192.0.2.23
OutboundBindAddress 2001:db8::94de
ORPort 56527
ExtORPort 55009
ORListenAddress 192.0.2.23:56527
ORListenAddress [2001:db8::94de]:56527
DataDirectory /var/lib/tor
PidFile /var/run/tor/tor.pid
Log notice file /var/log/tor/notices.log
ServerTransportPlugin scramblesuit exec /usr/bin/obfsproxy managed
ServerTransportPlugin obfs3,obfs4 exec /usr/bin/obfs4proxy -enableLogging -logLevel=INFO
ServerTransportListenAddr obfs3 192.0.2.23:33027
ServerTransportListenAddr obfs3 [2001:db8::94de]:33027
ServerTransportListenAddr obfs4 192.0.2.23:47131
ServerTransportListenAddr obfs4 [2001:db8::94de]:47131
ServerTransportListenAddr scramblesuit 192.0.2.23:16428
ServerTransportListenAddr scramblesuit [2001:db8::94de]:16428
ContactInfo me@example.org
User debian-tor
RunAsDaemon 1
NumCPUs 1
PublishServerDescriptor 1
SocksPort 0
BridgeRelay 1
Exitpolicy reject *:*
Exitpolicy reject6 *:*
BridgeRecordUsageByCountry 1
ConnDirectionStatistics 1
EntryStatistics 1
ExtraInfoStatistics 1
DynamicDHGroups 1
HardwareAccel 1
```
When I enter the bridge line in TBB 4.5a4, I can't get a connection. Looking at the obfs4proxy.log, I see the message:
> 2015/03/11 22:19:25 [ERROR]: obfs4([scrubbed]:58915) - failed to connect to ORPort: mismatch in server hash
When I comment out the `ExtORPort` line and restart Tor, I can connect to the bridge. If I set `ExtORPort auto` I can't get a connection. Later I'll provide a more detailed log.Tor: 0.2.6.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/15243Allow multiple Tor instances to share directory info, guards, and who knows w...2020-06-27T14:01:33ZNick MathewsonAllow multiple Tor instances to share directory info, guards, and who knows what else?Frequently people want applications to run in a one-tor-per-app model. Sometimes, people want systems to run in a one-tor-per-user model. The main problem here is that some information (like choice of guards) should be consistent acros...Frequently people want applications to run in a one-tor-per-app model. Sometimes, people want systems to run in a one-tor-per-user model. The main problem here is that some information (like choice of guards) should be consistent across all Tors, and some effort (like fetching directory information) is needlessly duplicated across all Tors.
We should look for designs that fix this.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15244Add helper functin that validates a .onion address2020-06-27T14:01:33ZDavid Gouletdgoulet@torproject.orgAdd helper functin that validates a .onion addressMake a function that validates an HS address and can return either a reason as a string or an error code indicating the error type (maybe use errno values for that?).
```
int is_valid_rendservice_addr(const char *addr, char **reason);
```Make a function that validates an HS address and can return either a reason as a string or an error code indicating the error type (maybe use errno values for that?).
```
int is_valid_rendservice_addr(const char *addr, char **reason);
```Tor: 0.2.7.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org