{5} Accepted, Active Tickets by Owner (Full Description) (117 matches)

Following a discussion on the mailing list [1] the GoodBadISP page could do with some updating and proper arranging.

Some of the categories I have in mind to make available in the table format are as follows: Country, Company Name, ASN, Bridges Allowed, Relays Allowed, Exits Allowed, Last Updated, Correspondence.

Would "Bridges Allowed" be a redundant measure since they won't be in the public sphere?

Moritz @ Torservers already has done a fair deal of work, some is outdated or could use an update though but it's a good place to start our focus and give inspiration where needed. [2] [3] [4]

[1] ​https://lists.torproject.org/pipermail/tor-relays/2014-October/005493.html

[2] ​https://www.torservers.net/wiki/hoster/experience

[3] ​https://www.torservers.net/wiki/hoster/inquiry

[4] ​https://www.torservers.net/wiki/hoster/index

Note: Those wishing to assist on this project please feel free to CC yourself in and keep an eye on the child tickets. I can be found under the pseudonym "TheCthulhu" on IRC or contacted at thecthulhu <at> riseup <dot> net if you wish to ask me directly what to work on next. If this is the first time you've assisted using Trac or the Tor Wiki, don't hesitate to ask for help.

In the most recent release of the Tor Browser Bundle, the help documentation bundled with Vidalia (accessed by selecting Help) is out of date. A search of GeoIP will confirm this, as the documentation still lists the GeoIP lookup server at geoip.vidalia-project.net, which has not been maintained since 2010.

I'm interesting in the token full URL only when I create a new token so I give it to the user. The rest of the time, I don't really care to see the full thing, only the hash, maybe. That could reduce the table width.

So this change needs also a change to the token creation action to display a big fat URL that I can easily get into the clipboard.

When sending tor a HUP before it has read its config, it will die, without killing its PTs. Starting tor again will then result in more PT crashes, as the ports will already be used by previous instances.

10149 ?        Sl     0:00 /usr/bin/obfs4proxy managed
10581 ?        Sl     0:01 /usr/bin/tor -f /etc/tor/torrc-node1
10582 ?        S      0:00  \_ /usr/bin/python /usr/bin/obfsproxy managed
10583 ?        Z      0:00  \_ [obfs4proxy] <defunct>
10584 ?        S      0:00  \_ /usr/bin/python /usr/bin/fteproxy --managed --mode server

If DisableNetwork is set to 1 via SETCONF during bootstrapping, Tor sometimes generates spurious errors such as "Network is unreachable". Kathy and I saw this while testing a fix for #11879. We realize this may be difficult to fix due to the internal architecture / concurrency inside Tor.

See #15713 for steps to reproduce (but note that an error does not occur every time). In the log that is attached to #15713 you can see an example:

Apr 17 10:28:10.000 [warn] Problem bootstrapping. Stuck at 25%: Loading networkstatus consensus. (Network is unreachable; NOROUTE; count 1; recommendation warn; host 847B1F850344D7876491A54892F904934E4EB85D at 86.59.21.38:443)

(the error happens right away if it happens at all – no delay).

This problem may cause some Tor Browser users to be a little confused; all they need to do is click "Open Settings" while Tor Browser was starting up and they will sometimes see an error alert.

Nick and I both thought that at least in the past, Tor clients would stop using a relay as their guard, if it loses the Guard flag.

But it looks like the code doesn't do that -- once a relay is your guard, you'll use it in the guard position regardless of whether it has the Guard flag at this moment or not.

This is actually a tricky design decision. In favor of avoiding guards that don't have the guard flag:

• If they get really slow, we can instruct clients to abandon them.
• If a relay gets the guard flag for only a short period of time, it will have only a small number of (dedicated) users using it for the next months.

In favor of using non-Guard guards anyway:

• An attacker can't push you away from your guard by hurting its performance in the eyes of the directory authorities.
• You won't rotate guards as many times.

That "can't push you away" one looks big. What other aspects should we be considering here?

with tor-0.2.6.9 and stem-1.4.1 I run (rarely) into this :

cat ioerror.stderr.old
Exception in thread Event Notifier:
Traceback (most recent call last):
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 1758, in get_network_status
    desc_content = self.get_info(query, get_bytes = True)
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 414, in wrapped
    raise exc
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 409, in wrapped
    return func(self, *args, **kwargs)
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 1113, in get_info
    raise exc
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 1066, in get_info
    stem.response.convert('GETINFO', response)
  File "/usr/lib64/python3.3/site-packages/stem/response/__init__.py", line 135, in convert
    message._parse_message(**kwargs)
  File "/usr/lib64/python3.3/site-packages/stem/response/getinfo.py", line 38, in _parse_message
    raise stem.InvalidArguments('552', 'GETINFO request contained unrecognized keywords: %s\n' % ', '.join(unrecognized_keywords), unrecognized_keywords)
stem.InvalidArguments: GETINFO request contained unrecognized keywords: ns/id/2BCDF9F0BCEFC2A44F7850F92362BA85AA226E1F


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib64/python3.3/threading.py", line 901, in _bootstrap_inner
    self.run()
  File "/usr/lib64/python3.3/threading.py", line 858, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 882, in _event_loop
    self._handle_event(event_message)
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 3480, in _handle_event
    listener(event_message)
  File "./err.py", line 47, in orconn_event
    relay = controller.get_network_status(fingerprint)
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 414, in wrapped
    raise exc
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 409, in wrapped
    return func(self, *args, **kwargs)
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 1761, in get_network_status
    raise stem.DescriptorUnavailable("Tor was unable to provide the descriptor for '%s'" % relay)
stem.DescriptorUnavailable: Tor was unable to provide the descriptor for '2BCDF9F0BCEFC2A44F7850F92362BA85AA226E1F'

while running this script :

$ cat err.py
#!/usr/bin/python3 -u

#   Toralf Foerster
#   Hamburg
#   Germany

# collect data wrt to https://trac.torproject.org/projects/tor/ticket/13603
#

import time
import functools

from stem import ORStatus, ORClosureReason
from stem.control import EventType, Controller


def main():
  class Cnt(object):
    def __init__(self, done=0, closed=0, ioerror=0):
      self.done = done
      self.closed = closed
      self.ioerror = ioerror

  c = Cnt()

  with Controller.from_port(port=9051) as controller:
    controller.authenticate()

    orconn_listener = functools.partial(orconn_event, controller, c)
    controller.add_event_listener(orconn_listener, EventType.ORCONN)

    while True:
      time.sleep(1)

def orconn_event(controller, c, event):
  if event.status == ORStatus.CLOSED:
    c.closed += 1

    if event.reason == ORClosureReason.DONE:
      c.done += 1

    if event.reason == ORClosureReason.IOERROR:
      c.ioerror += 1

      fingerprint = event.endpoint_fingerprint
      print (" %i %i %i %i %s %40s" % (c.closed, c.done, c.ioerror, event.arrived_at, time.ctime(event.arrived_at), fingerprint), end='')
      relay = controller.get_network_status(fingerprint)
      if relay:
        print (" %15s %5i %s %s" % (relay.address, relay.or_port, controller.get_info("ip-to-country/%s" % relay.address, 'unknown'), relay.nickname), end='')
      print ('', flush=True)

if __name__ == '__main__':
  main()

Bug #11236 is caused by translated search engine strings. We should make sure those strings are not translated.

OSX default curl binary is not being torified when using torify or torsocks. Using: curl --proxy socks5h://curl:curl@127.0.0.1:9050/ works fine, however, running torify/torsocks curl <url> does not work.

Example:

$ torify curl ifconfig.co/all.json # returns original IP $ curl --proxy socks5h://curl:curl@127.0.0.1:9050/ ifconfig.co/all.json # returns the expected output $ torify curl https://check.torproject.org/ | grep -i congratulations # returns nothing

Torify does work on the Homebrew's curl version with the torify command, but it does not work when running a torify --shell (nor does the default OSX's curl):

$ torify --shell
/usr/local/bin/torsocks: New torified shell coming right up...
$ /usr/local/opt/curl/bin/curl ifconfig.co/all.json # returns my real IP
$ /usr/bin/curl ifconfig.co/all.json # returns my real IP
$ wget ifconfig.co/all.json # returns my real IP too (using homebrew's wget version 1.17.1)

OSX default curl:

$ curl --version
curl 7.43.0 (x86_64-apple-darwin15.0) libcurl/7.43.0 SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz UnixSockets

Homebrew's curl version:

$ /usr/local/opt/curl/bin/curl --version
curl 7.46.0 (x86_64-apple-darwin15.0.0) libcurl/7.46.0 SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: IPv6 Largefile NTLM NTLM_WB SSL libz UnixSockets

Apple makes this difficult to debug and find out why, due it's Security Integrity Protection (executables signed with restricted entitlements), so I copied OSX's default curl binary to /tmp, ran [1] then I was able to run btruss on the default curl, however I wasn't able run torify with btruss , since [1] didn't work, btruss output didn't have anything interesting as far as I know.

Attachments: with-torify.txt for the output of sudo torify dtruss ./curl ifconfig.co/all.json and no-torify.txt for sudo dtruss ./curl ifconfig.co/all.json

I am willing to help debug this if needed, but I would like some help to make this easier, since disabling OSX's System Integrity Protection is not a good idea, and apparently code-signing didn't work with me.

[1] codesign -f -s `whoami` curl

OSX version: 10.11.2 (15C50) Torsocks version: Torsocks 2.1.0 Tor version: 0.2.7.6

This ticket is part of proposal 224 and is for the implementation of the descriptor cache on the HSDir side.

the Linux 'capabilities' library for allowing non-root users to perform tasks which normally require elevated privileges.

at present the torsocks wrappers have checked for setuid and setgid flags on the binaries it executes and failed closed, throwing an error if this occurs, however there is currently no check to see if the binaries have capabilities applied.

in the case where they do, the LD_PRELOAD set by torsocks is stripped and the program will execute with no warning and without the torsocks wrapper.

as an example of this, the current 'ping' command on my Linux is setcap:

$ getcap which ping /usr/bin/ping = cap_net_raw+ep $ torsocks ping -c 1 torproject.org PING torproject.org (82.195.75.101) 56(84) bytes of data. 64 bytes from 82.195.75.101: icmp_seq=1 ttl=50 time=38.1 ms

​https://projects.archlinux.org/svntogit/packages.git/tree/trunk/iputils.install?h=packages/iputils

When using torsocks 2.1.0 built from tarball, torsocks attempts to resolve the local machine's hostname using tor.

To reproduce: clone a git repository using torsocks

Result: clone is successful, but produces an error in torsocks after an attempt to resolve the machine's hostname:42 using tor.

ERROR torsocks[pid]: Unable to resolve. Status reply: 4 (in socks5_recv_resolve_reply() at socks5.c:666)

ERROR torsocks[29369]: [socks5] Resolve destination buffer too small (in socks5_recv_resolve_reply() at socks5.c:690) ERROR: Unable to download webpage: <urlopen error [Errno -4] Non-recoverable failure in name resolution> (caused by URLError(gaierror(-4, 'Non-recoverable failure in name resolution'),))

The error changes over time. But it is mostly in this range. With a fresh restart the problem goes away, but it is back after some time blocking all requests.

Stopping any TBB5 running and starting TBB4.5.3 makes everything go smooth again.

Besides TBB, nothing changes in the configuration.

I am running OSX 10.11 and since the update I just noticed that torsocks is failing to torify connections.

Here are the details of my system:

$ torsocks --version
Torsocks 2.1.0

$ uname -a
Darwin XXX 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64

$ sw_vers -productVersion
10.11.1

Doing a cursory search into what may be the causes for this problem it seems like a security "feature" introduced in OSX 10.11 is to blame for this behaviour called System Integrity Protection [1]. Looking around there are other people complaining about the fact that DYLD_INSERT_LIBRARIES doesn't work in OSX 10.11 [2]. This stackoverflow article does a nice summary of what can be done and can't be done due to SIP: ​http://apple.stackexchange.com/questions/193368/what-is-the-rootless-feature-in-el-capitan-really.

I am not sure what can be done to overcome this limitation in the latest version of OSX, but I think that at least torsocks should implement a check for the OSX version and if it's greater than 10.10 it fails closed (without doing the non-torified request).

[1] ​https://developer.apple.com/library/mac/documentation/Security/Conceptual/System_Integrity_Protection_Guide/Introduction/Introduction.html

[2] ​https://groups.google.com/a/chromium.org/forum/#!topic/crashpad-dev/MafauT4BHSY

It's still unclear to me if that library is still distributed or/and maintained but some application still use it either compiled in or shared. I can't find that library in a recent Debian system.

So it turns out that in irssi is doing DNS resolution in an other process and passing the result back to the first process which will make the connection.

This means that the two process have two distinct onion pools so the process doing the DNS resolution will store the onion address with the reserved cookie but the other process, when connecting using that cookie, will be unable to find the onion address in its pool.

One solution I have in mind is to create that onion pool in a shared memory (SHM) and hijack the clone/fork symbol so when we detect a new process we can set the onion pool reference in it thus sharing the pool across processes that have a common parent.

I have a PoC that works but maybe there could be an IPC approach instead.

  time_t cutoff = now - REND_CACHE_MAX_AGE - REND_CACHE_MAX_SKEW;

That's currently 3 days.

Yet

config.c:  V(RendPostPeriod,              INTERVAL, "1 hour"),

So we expect our current one to get overwritten once an hour, yet if the hidden service goes away (stops publishing) we continue to serve its old (presumably no longer working) descriptor for 71 more hours.

One downside to this poor tuning is that we waste the time of clients who try to access the hidden service -- if we instead tell them there is no descriptor, they could go to another hsdir or give up more promptly.

One upside is that if we say we don't have one, clients *will* go visit five other hsdirs before giving up, which could result in a lot of thrashing. Whereas providing an old one will keep the client distracted for a while. But that's not really a good reason.

Another downside is that it's easier to stuff our cache full of things, i.e. use hsdirs for arbitrary storage of blobs for three days.

Multiple issues need FD passing through a Unix socket to work: #8585, #16183

It's maybe possible to support this safely. My intuition is that we might be able to get it work by passing some cookies in the ancillary data so we can recognize the sendmsg() with the recvmsg(). Maybe!?...

From #16943: Replying to dgoulet:

Replying to teor:

A hard-coded SHARED_RANDOM_N_ROUNDS is going to make it really hard to test hidden services quickly using chutney. (We'll always be testing them using the default initial shared random value.) Can we make this configurable in test networks?

#define SHARED_RANDOM_N_ROUNDS 12

The part I do not like about changing this value for testing network is that we do NOT get the real behavior of the protocol... I'm not against for a testing value but I would do that after merge in a separate ticket.

Took out the hidden services related functions to their own file out of routerparse.c/.h into rendparse.c/.h. Put the common functions/definitions in parsecommon.c/.h.

We need a Tor web interface for the DreamPlug, as discussed at the Tor dev meeting in Waterloo, Canada earlier this week.

wheezy (debian testing) probably be released in the next few months, so it seems reasonable to develop torouter for that target to ensure stability over the next few years. Also, several DreamPlug-specific changes were upstreamed into the mainline kernel and are present in wheezy.

AFAIK the required code changes would be updating the freedom-maker folder in torouter.git to a more recent version (either directly from b'dale or from nickdaly's version on github), redo source.list entries (backports not necessary?), and test that all required packages exist and function as expected under wheezy.

One road-blocker is that the more recent kernel seems to require an updated version of the u-boot bootloader on the DreamPlug, and the upgrade process requires the

The WiFi chipset still requires some third-party firmware and kernel module compilation (uap8xxx.ko == libertas_uap) with the 3.2 kernel.

Thoughts?

A check to determince the package dependencies requirements. Do I miss anything?

I visited ​http://atlas.torproject.org/ and noticed that "learn more" links me to ​http://atlas.torproject.org/?#about - as a first time user, I would have expected that to take me to learn more about the network, not the software.

Perhaps there is a nice page with some interesting summary graphs that might be a better landing page?

There could be a link "how do I search for my bridge", or similar, that explains how to find their bridge's fingerprint and run it through SHA-1 before searching for it in Globe.

Following on from #19359, I suspect that similar problems are present in the website.

W3C have a link checker utility that could be run from a Jenkins job.

​http://search.cpan.org/dist/W3C-LinkChecker/

I have a local Jenkins instance to experiment with this. If it proves to be effective/useful we can consider moving this to jenkins.tpo.

Sebastian noted in IRC that some failures may be temporary and each failure would require individual investigation. In any documentation we should note that we should never automate fixes, even where there are permanent redirects in place (a redirect may occur simply because the content doesn't exist anymore and it just takes you to a home page for instance).

BridgeDB needs Nagios checks that the Email Distributor is working. The best way to do this would be to send an email to bridges@… which say "get help".

Make room for performance tests somewhere in src/ and write a separate Ant task to run them. (see parent #13616)

The Release Process description should be based on existing documentation:

​metrics-lib's CONTRIB.md

and after completion be referenced by metrics-lib's README

Karsten asked me to open a ticket for this, so I do.

Torprojects instance says: "flags":[] cthulhu's instance says: "flags":[""]

When I load this URL, the first time I get meaningful output:

But if I hit Ctrl+R to refresh, I get this garbled (maybe compressed?) output instead:

If I refresh again, it goes back to the readable version, and if I refresh yet again, it switches back to the garbled version. I can keep switching back and forth.

The same happens if I click the refresh icon in the address bar. I tried it in Tor Browser 6.0a4 and Chromium 49.0, and it happens in both.

The garbled version additionally causes this to be printed to the console:

The character encoding of the plain text document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the file needs to be declared in the transfer protocol or file needs to use a byte order mark as an encoding signature.

With another type of document, namely ​https://onionoo.torproject.org/details?lookup=88F745840F47CE0C6A4FE61D827950B06F9E4534, the text remains readable while repeatedly refreshing, but the "character encoding" message appears in the console in alternating refreshes.

It would be nice to have a graph similar to [1] but replacing the number of relays with overall traffic share.

example (numbers completely made up): 0.2.4 is handling 15% of the traffic 0.2.3 is handling 40% of the traffic ...

[1] ​https://metrics.torproject.org/network.html#versions

Users keep sending messages with “get bridges” to the help desk instead of sending them to BridgeDB. It's painful.

It would be best to automatically detect such emails and bounce them to BridgeDB without human intervention.

“Scrip” will need to be written in RT. Interesting bits of the documentation: ​http://requesttracker.wikia.com/wiki/WriteCustomAction ​http://requesttracker.wikia.com/wiki/ReplyBasedUponContent ​http://requesttracker.wikia.com/wiki/SendEmailAction

The switch from having a single person handling all support request to a team was made through recruiting support assistants as a contracting position. It would be good to define a process on how new people can get accepted in the team. It's mostly a question of trust and probably we need to define a vouching process and a set of people that need to ack the decision.

People are asking for obfsproxy nightlies (#10954). It would be brilliant if people could add our debian repo, and get the latest obfsproxy master through it.

How can I help you do this?

No hurry on this one. I mainly made this ticket because #10954 was not very specific.

Thanks!

Setting my phone to disable data access and/or enable airplane mode seems to cause the transproxy iptables rules created by OrBot to get silently flushed. After re-enabling, all apps access everything without tor, until I go into the orbot config screen to cause it to reapply them.

OrBot should listen for these network disable/loss/disconnect events if possible, and reinstate the iptables rules after this happens.

Someone should also test if switching from cell data to+from wifi also triggers this iptables reset. I have not tested that yet.

This is about the bug discussed with 'n8fr8' on #guardianproject at freenode. So, the relay functionality you said was broken and needs to be fixed for 'orbot' on smartphones. I checked with the orbot version '0.2.3.10-alpha-orbot-1.0.7-FINAL' and you have checked with the 'dev branch of the code' as you said (i suppose that means you have checked with latest version of code by compiling and running the latest updated version from git; i will do it too and let you know again). But none seemed to work. In fact, you said you were getting a more significant crash, when you enabled relaying on smartphone for dev branch of code. You also thought if the problem is: whether the Relay conflict is with transproxying/root or with Tor client connection in general. But, i'm not sure if it later seemed not to be the problem. Then, you told me to change the torrc file on my android phone, as you said that orbot is not setting the relay values properly which might be the reason for orbot not working as a relay on smartphone. So, I will do that and let you know about it. I will also keep checking '​https://guardianproject.info/builds/Orbot/' to see if any new dev/debug release is posted. Thankyou so very much for all your help, Mr.Nathan.

There's some kind of problem with permissions in Orbot. I'm not sure if this happens only to me, but when I try to start Tor, it cannot access cache/control_auth_cookie. I can chmod it every time, but it is a bit annoying.

Depending on how hard it will be to make Tor handle VoIP applications people already want to use (#5699), we should explore how much mileage we can get out of making our own or modifying existing VoIP applications to work better on Tor. One example here is Roger's "push to talk" not-actually-realtime-but-close VoIP wishlist item that Nathan is working on.

This has been an annoyance in our protocol for entirely too long. Once we have a solid proposal (#5640) for this, we should implement it posthaste.

Right now, Tor does nearly all of its work in one main thread. We have a basic "CPUWorker" implementation that we use for doing server-side onionskin crypto in a separate thread, but thanks to improvements long ago, server-side onionskin crypto on longer dominates. If we could split the work of relay AES-CTR crypto and SSL crypto across multiple threads, that would be pretty helpful in letting high-performance servers saturate their connections. (Blutmagie has wanted this for some while.)

Child Tickets:

I'm running tor on Gentoo Hardened. The bug exists in 0.2.6.7 and 0.2.7.1-alpha. tor crashes within seconds of starting, before any clients can connect I think.

Jul 14 13:13:07.000 [notice] Tor 0.2.7.1-alpha (git-df76da0f3bfd6897) opening log file.
Jul 14 13:13:07.182 [notice] Tor v0.2.7.1-alpha (git-df76da0f3bfd6897) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.1p and Zlib 1.2.8.
Jul 14 13:13:07.182 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jul 14 13:13:07.182 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Jul 14 13:13:07.182 [notice] Read configuration file "/etc/tor/torrc".
Jul 14 13:13:07.187 [notice] Opening Socks listener on 127.0.0.1:9050
Jul 14 13:13:07.187 [notice] Opening Socks listener on 127.0.0.1:9056
Jul 14 13:13:07.187 [notice] Opening Socks listener on 127.0.0.1:9055
Jul 14 13:13:07.187 [notice] Opening Control listener on 127.0.0.1:9015
Jul 14 13:13:07.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Jul 14 13:13:07.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Jul 14 13:13:07.000 [notice] Bootstrapped 0%: Starting

============================================================ T= 1436875987
(Sandbox) Caught a bad syscall attempt (syscall socket)
/usr/bin/tor(+0x142148)[0x4bb7bc8148]
/lib64/libc.so.6(socket+0x7)[0x3adc706ea07]
/lib64/libc.so.6(socket+0x7)[0x3adc706ea07]
/lib64/libc.so.6(+0xf16a0)[0x3adc70686a0]
/lib64/libc.so.6(__vsyslog_chk+0x3ef)[0x3adc7068aff]
/lib64/libc.so.6(__syslog_chk+0x89)[0x3adc7068df9]
/usr/bin/tor(+0x135bb0)[0x4bb7bbbbb0]
/usr/bin/tor(tor_log+0xd0)[0x4bb7bbc680]
/usr/bin/tor(control_event_bootstrap+0x1e4)[0x4bb7b7ba74]
/usr/bin/tor(do_main_loop+0x84)[0x4bb7abe234]
/usr/bin/tor(tor_main+0x16c5)[0x4bb7ac1225]
/lib64/libc.so.6(__libc_start_main+0x114)[0x3adc6f97134]
/usr/bin/tor(+0x34519)[0x4bb7aba519]

$ uname -r
3.18.9-hardened

This bug has been reported downstream: ​https://bugs.gentoo.org/show_bug.cgi?id=550302. It occurs with the following torrc:

#
# Minimal torrc so tor will work out of the box
#
User tor
PIDFile /var/run/tor/tor.pid
Log notice syslog
Log notice file /var/log/tor/log
DataDirectory /var/lib/tor/data
SandBox 1

SocksPort 9050
SocksPort 9056 IsolateDestAddr IsolateDestPort
SocksPort 9055

ControlPort 9015
CookieAuthentication 1

By commenting out "Sandbox 1" or unsetting it, tor will obviously run without crashing.

Tor relies on double checked locking for various threading initializations. Double checked locking is not guaranteed to work.

For Posix: 4.11, Memory Synchronization: ​http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html

Applications shall ensure that access to any memory location by more than one thread of control (threads or processes) is restricted such that no thread of control can read or modify a memory location while another thread of control may be modifying it.

Race conditions: compat_pthreads.c:threads_initialized

log.c:log_mutex_initialized

Mutex static initialization is supported by pthreads via PTHREAD_MUTEX_INITIALIZER.

Unless we track the size of the largest cycles in our code, big cycles may return

In my branch "split_routerlist.c", I have the start of some work on dividing routerlist.c into more sensible pieces. I've chopped out routerset_t, killed a couple of functions, and moved most of the node manipulation pieces into nodelist.c

I'd still like to chop out more: the trusted_dir_server_t logic and the node-selection logic don't belong there any more. Nor does the authority certificate code. Nor does the hidden service directory stuff, nor does the hexdigest stuff.

In the longer term, I want routerlist.c to basically just not get invoked when you're not touching routerinfos.

By Nov 2016, we have a deliverable to get our route selection much more right than today, and to have it very tested. We should get this done significantly earlier.

While looking at bug #4371, here's what my client said:

Nov 01 04:30:45.000 [warn] Certificate not yet valid: is your system clock set incorrectly?
Nov 01 04:30:45.000 [warn] (certificate lifetime runs from Nov  1 12:15:08 2011 GMT through Oct 31 12:15:08 2012 GMT. Your time is Nov 01 08:30:45 2011 GMT.)
Nov 01 04:30:45.000 [notice] We stalled too much while trying to write 512 bytes to address "120.50.40.184".  If this happens a lot, either something is wrong with your network connection, or something is wrong with theirs. (fd 14, type OR, state 7, marked at command.c:995).

Looks like we had already written our netinfo cell to the outbuf, but hadn't flushed it. Since I'm a client and this was an OR connection, it gets to be severity notice. Fun.

For the client side, I think this bug might be resolved by the proposed fix to #4361.

But my directory authority experiences something similar: Nov 01 06:04:10.000 [info] conn_close_if_marked(): Conn (addr "120.50.40.184", fd 1609, type OR, state 7) marked, but wants to flush 916 bytes. (Marked at command.c:995) Nov 01 06:04:10.000 [info] conn_close_if_marked(): We stalled too much while trying to write 916 bytes to address "120.50.40.184". If this happens a lot, either something is wrong with your network connection, or something is wrong with theirs. (fd 1609, type OR, state 7, marked at command.c:995). I wonder what's sitting in its outbuf.

As discussed on #14784 we call self-published descriptors quite a few things...

• 'GETINFO desc/*' and Stem call the main self-published descriptors server descriptors. Metrics also uses a "server-descriptor 1.0" annotation for them.
• The dir-spec calls them router descriptors... usually. It opts for 'server descriptor' in section 6.2.
• CollecTor calls them relay descriptors.

Having three different names is confusing for new contributors and... well, us too. We should standardize on a name.

This primarily straddles Tor's spec, Stem, and CollecTor. Personally I'd like for us to standardize on server descriptors because it's codified in the Metrics annotation and classes Stem vends.

Karsten, Nick: any objections? If not then I'm happy to provide a spec patch and file a CollecTor ticket for this.

Error message coming up for all commands. Below a couple I get

Traceback (most recent call last):

File "mixminion.py", line 25, in ? File "mixminion\Main.pyc", line 333, in main File "mixminion\ClientMain.pyc", line 1208, in runClient File "mixminion\ClientMain.pyc", line 960, in init File "mixminion\ClientDirectory.pyc", line 116, in init File "mixminion\ClientDirectory.pyc", line 369, in load File "mixminion\Common.pyc", line 604, in readPickled

AttributeError: 'module' object has no attribute 'CachingDescriptorSource'

Traceback (most recent call last):

File "mixminion.py", line 25, in ? File "mixminion\Main.pyc", line 333, in main File "mixminion\Main.pyc", line 279, in commandShell File "mixminion\Main.pyc", line 333, in main File "mixminion\ClientMain.pyc", line 1872, in cleanQueue File "mixminion\ClientUtils.pyc", line 730, in getHandlesByAge File "mixminion\ClientUtils.pyc", line 867, in loadMetadata File "mixminion\Filestore.pyc", line 397, in loadAllMetadata File "mixminion\Filestore.pyc", line 420, in getMetadata

EOFError

Google Translate for whole webpages is broken again. (HTTPS-Everywhere 1.0.3, FF 8) Instead of the translation, you get multiple copies of the Google translate header underneath each other.