{5} Accepted, Active Tickets by Owner (Full Description) (115 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.

​https://tb-manual.torproject.org/en-US/security-slider.html

The screenshot shows Low, Medium, High - but the slider is now Safe, Safer, Safest.

​https://tb-manual.torproject.org/en-US/transports.html

Should probably happen until snowflake reaches Tor Browser stable builds across all platforms.

With enabled HTTPS Everywhere, ​http://www.o2online.de/microsite/o2-netz/live-check/ does not load additional JavaScript from a non-SSL CDN

While working on #21654 I noticed that we have some different code paths that depends upon whether we're running on Windows or not where it would be trivial to turn them into a single code path.

I do not have access to a Windows machine right now, so it would be useful if someone could help test the patch(es).

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.

Currently in master we have the following stanza in our .gitlab-ci.yml (from #22891):

update:                                                                                                                                                                                                                           
  script:                                                                                                                                                                                                                         
    - "apt-get install -y --fix-missing git openssh-client"                                                                                                                                                                       
                                                                                                                                                                                                                                  
    # Run ssh-agent (inside the build environment)                                                                                                                                                                                
    - eval $(ssh-agent -s)                                                                                                                                                                                                        
                                                                                                                                                                                                                                  
    # Add the SSH key stored in SSH_PRIVATE_KEY variable to the agent store                                                                                                                                                       
    - ssh-add <("$DEPLOY_KEY")                                                                                                                                                                                                
                                                                                                                                                                                                                                  
    # For Docker builds disable host key checking. Be aware that by adding that                                                                                                                                                   
    # you are suspectible to man-in-the-middle attacks.                                                                                                                                                                           
    # WARNING: Use this only with the Docker executor, if you use it with shell                                                                                                                                                   
    # you will overwrite your user's SSH config.                                                                                                                                                                                  
    - mkdir -p ~/.ssh                                                                                                                                                                                                             
    - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'                                                                                                                                  
    # In order to properly check the server's host key, assuming you created the                                                                                                                                                  
    # SSH_SERVER_HOSTKEYS variable previously, uncomment the following two lines                                                                                                                                                  
    # instead.                                                                                                                                                                                                                    
    - mkdir -p ~/.ssh                                                                                                                                                                                                             
    - '[[ -f /.dockerenv ]] && echo "$SSH_SERVER_HOSTKEYS" > ~/.ssh/known_hosts'                                                                                                                                                  
    - echo "merging from torgit"                                                                                                                                                                                                  
    - git config --global user.email "labadmin@oniongit.eu"                                                                                                                                                                       
    - git config --global user.name "gitadmin"                                                                                                                                                                                    
    - "mkdir tor"                                                                                                                                                                                                                 
    - "cd tor"                                                                                                                                                                                                                    
    - git clone --bare https://git.torproject.org/tor.git                                                                                                                                                                         
    - git push --mirror git@oniongit.eu:network/tor.git                                                                                                                                                                           

Why are we doing this? Can we put a cronjob on the oniongit.eu server instead? It's pretty weird and frankly unexpected that my personal fork of tor at ​https://gitlab.com/isis/tor is cloning the official tor repo and then trying to mirror it to oniongit.eu. It also has a bunch of other problems:

• The ssh-add line ​is broken, causing CI to fail because it sits there forever waiting for a passphrase.

I was originally going to patch the ssh-add line to instead be [[ -n "${DEPLOY_KEY}" -a -r "$DEPLOY_KEY" ]] && ssh-add "$DEPLOY_KEY" <<<"" but if I fix that, then all the rest of this script would run, so I'm rather glad it's failing on a more innocuous command.

• Even if the ssh-add line weren't broken, this whole thing fails unless it's being run from a fork on oniongit.eu.
• Why is it disabling SSH hostkey checking?!
• Why is it making the ~/.ssh directory twice?
• Why is it assuming that environment variables are set? e.g. $FOO versus ${FOO} or better test -n ${FOO}
• Why is it unconditionally setting (global!) git config options? (I assume to disable the warning that git spits out when you don't have $GIT_{AUTHOR,COMMITTER}_{NAME,EMAIL} set, but why would a CI config set them globally instead of just setting the correct environment variables?)
• Why are the mirror URLs hardcoded?
• Why is the git username and email hardcoded?
• Why is any of this even running when I push to ​https://gitlab.com/isis/tor?
• Why is any of this even running when I push anywhere?
• Why is it unconditionally starting an ssh-agent?
• Why is using the existence of a (​deprecated!) /.dockerenv file to determine if we're in a docker container?
• Why is it assuming we're in the correct docker container, when lots of things, especially lots of CI systems, use docker?

I'm sorry if this is all necessary and I'm just not understanding the setup, but it's all just extremely unexpected behaviour from what is supposed to be a CI config file. Further, it's not even doing the same testing as our .travis.yml, but I'll make another ticket for that issue.

The relay guide should be ready once Ubuntu 18.04 is released (2018-04-26), this depends on #25888

• wait for #25888 to get committed
• confirm current instructions work on Ubuntu 18.04

As an example, KIST controls how much and when channel data is pushed on the network which means this wants to write event used by the Vanilla scheduler as "queued cell but no space on the outbuf" is not something that is coherent with KIST.

A channel is scheduled in when it has cells in the queue, then they are flushed one by one by the KIST scheduler until the kernel says "no more space". Then, that channel is put back in the channel pending list and will get handled at the next tick of KIST.

So, we really don't need KIST to be notified of this event from connection_flushed_some() which is used by Vanilla to try to flush more cells in the outbuf because the outbuf has room for it.

Where it is useful is the second callsite of that even in channel_tls_handle_state_change_on_orconn() which notifies the scheduler that it might be in need of flushing some stuff. In the case of a brand new channel just opening, its state is "IDLE" and that even will then put it in "waiting for cells" after.

That being said, what needs to happened:

1. Make the notification event a per-scheduler thing because KIST and Vanilla have different semantic for those events really. We should of course avoid as much as we can of code duplication and thus some "generic event handler" do make sense if they share the same semantic.

2. Add a "channel state is open" notification event instead of "wants to write" which is really only true in very specific cases in channel_tls_handle_state_change_on_orconn(). That way, the scheduler can take a decision on the status of the channel instead of blind guessing it is waiting for cells.

3. Nullify the "wants to write" event for KIST considering (2) so it stops possibly scheduling channels that do not need at all to be scheduled.

Aug 14 05:59:04.639 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 05:59:09.631 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 06:04:08.637 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 06:04:10.634 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 06:04:30.680 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.

All of these streams had been attached to the same rendezvous circuit.

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.

In rotate_all_descriptors() there is the following XXX that needs to be resolved:

  /* XXX We rotate all our service descriptors at once. In the future it might
   *     be wise, to rotate service descriptors independently to hide that all
   *     those descriptors are on the same tor instance */

KIST scheduler does call a write to kernel contrary to the vanilla scheduler. This is done through channel_write_to_kernel() which calls connection_handle_write().

That last function will ultimately call connection_or_flushed_some() which triggers a scheduler_channel_wants_writes() because of this condition:

  datalen = connection_get_outbuf_len(TO_CONN(conn));
  if (datalen < OR_CONN_LOWWATER) {
    scheduler_channel_wants_writes(TLS_CHAN_TO_BASE(conn->chan));

That is OK if datalen > 0 but useless if datalen == 0. For KIST, it makes the channel go back in pending state and scheduled because it wants to write. But then if the outbuf or the cmux queue is empty, we end up scheduling a channel that actually does NOT need to write at all.

Could be the fix here is probably simple as:

  if (datalen > 0 && datalen < OR_CONN_LOWWATER) {

I suspect with KIST, the datalen will always be 0 because KIST in theory controls exactly what goes in the outbuf and what can be written to the kernel so when it triggers a connection write(), the entire outbuf should be drained (in theory). So the effect of this is that every write to the kernel from KIST triggers a useless "wants to write" event rescheduling the channel. Note that this only happens if the channel is in SCHED_CHAN_WAITING_TO_WRITE state.

We pass a NULL extend_info to service_intro_point_new() in the unit tests, and expect a non-NULL return value.

But buggy code could also pass NULL here, and we should return NULL if that happens.

One way to fix this is to split the function into two, and only call the first half in the unit tests.

My prop224 service stopped working. I did some digging and I noticed that it's only uploading one of its two descriptors, so it's only uploading next or current but not both. This has reachability consequences.

Here are some logs (grepping for run_upload_descriptor_event()):

Nov 16 15:06:51.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
Nov 16 15:51:04.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 16 17:00:25.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 16 17:06:02.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
Nov 16 18:22:23.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 16 19:05:22.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
Nov 16 19:05:22.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 16 20:13:08.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
Nov 16 20:20:11.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 16 21:18:50.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 16 21:30:21.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
Nov 16 22:49:34.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
Nov 17 00:23:30.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
Nov 17 01:08:16.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 5/3 introduction points.
Nov 17 01:50:14.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 17 03:37:20.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 17 04:40:29.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 17 05:30:14.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 17 06:41:39.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 17 08:11:41.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 17 09:18:45.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 17 10:40:24.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 17 12:22:55.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 17 13:30:14.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 17 14:39:14.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 17 14:40:15.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 17 16:13:06.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 17 18:01:49.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 17 19:46:57.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
Nov 17 20:01:08.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 17 20:16:59.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 17 20:52:18.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 17 21:28:40.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
Nov 17 21:37:22.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 17 22:31:59.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
Nov 17 23:00:11.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 18 00:17:02.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
Nov 18 00:22:14.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 18 01:12:15.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
Nov 18 01:12:15.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 18 02:44:15.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
Nov 18 02:44:16.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service next descriptor for service onion with 3/3 introduction points.
Nov 18 04:09:30.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
Nov 18 06:01:37.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
Nov 18 07:03:35.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
Nov 18 08:53:53.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
Nov 18 10:50:47.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
Nov 18 11:50:15.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
Nov 18 13:33:04.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.
Nov 18 14:54:15.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service onion with 3/3 introduction points.

Seems to be a pretty rare edge case, but putting it on 0.3.2 in any case. We can defer if needed.

We probably need some more diagnostic logs in should_service_upload_descriptor() to understand more about this issue.

Right now Java programs run with torsocks have their network calls dropped, or sometimes crash. Torsocks should force Java programs to use Tor. This could be done by setting the proxy settings in the JVM with -DsockProxyHost=127.0.0.1 -DsocksProxyPort=8080. To ensure proxy obedience for DNS calls, torsocks might implement a DNS provider that uses SOCKS for resolution, add that to the classpath, and use it to override the DNS provider the JVM uses at runtime.

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.

We still have code for dealing with version 0, 1, and 2 of the HS intro protocol.

From rend-spec.txt:

As of Tor 0.2.0.7-alpha and 0.1.2.18, clients switched to using the v2 intro format.

From the release notes:

Bugfix on 0.2.1.6-alpha, when the v3 intro-point protocol (the first one which sent a timestamp field in the INTRODUCE2 cell) was introduced;

Anything that generates INTRODUCE cells with these versions are long dead, so the code for handling this protocol version should be removed.

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!?...

Once #23577 is merged, we can make single onion services parse IPv6 addresses in introduce link specifiers. Then they can choose the address they want to use to connect to the rend point using their firewall settings.

connection_ap_attach_pending: Bug: 0x613000b8d680 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.2.9.1-alpha f6c7e131a1ceb178) Yeah, why?

We should look into XMPP pluggable transports. There are many public XMPP services that see widespread use even from censored countries.

For several years everyone was able to post on ​https://blog.torproject.org without enabling JavaScript and other dangerous things.

Observed behaviour: can not post unless slider set to medium or low Expected behaviour: high security supported Steps to reproduce: try to post at ​https://blog.torproject.org with security slider on high

We got a report on HackerOne by sumitthehacker:

i want to report a text injection and a misconfiguration of the 404 page

the bug exists at :

https://www.torproject.org/test/%2f../It%20has%20been%20changed%20by%20a%20new%20one%20https://www.Attacker.com%20so%20go%20to%20the%20new%20one%20since%20this%20one

as you can see attacker text is included
"It has been changed by a new one https://www.attacker.com so go to the new one since this one was not found on this server."

I know this is basically just Debian instructions, but framing this differently could really help for those that don't already know that Raspbian is essentially just Debian underneath.

This could be deferred until after the big website changes.

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".

tor-spec says:

   Link padding can be created by sending PADDING or VPADDING cells
   along the connection; relay cells of type "DROP" can be used for
   long-range padding.  The contents of a PADDING, VPADDING, or DROP
   cell SHOULD be chosen randomly, and MUST be ignored.

​https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1534

But padding cells sent by channelpadding_send_padding_cell_for_callback() and keepalive cells sent by run_connection_housekeeping() have a payload of all zero bytes.

I don't know if this is a security issue or not. It is probably ok, unless Tor has compression enabled on its TLS connections. If compression is enabled, all the padding data size calculations will be wrong.

As part of prop249, we need to handle large create cells when they arrive fragmented across multiple extend cells (and similarly for created cells fragmented across multiple extended cells).

Important notes:

• The proposal says that there must be no intervening cells on the same circuit. We should enforce this and test it.
• We should probably use a buf_t object to record these handshakes as they are being assembled.
• We should count these handshakes against the memory usage of a circuit and age of the oldest queued data, so that they will participate correctly in the OOM system.

As soon as we know what graphs we should make for #23761, we'll have to 1) specify the data format of the CSV file we need to produce for that.

And for Sponsor 13 we'll need to 2) specify the aggregation process, which will enable others to reproduce our results.

I'll start with 1) as soon as we have green light from #23761, but I'd appreciate help with 2).

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.

Mar 21 00:11:06 hostnaem Tor[1907]: Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (6)
Mar 21 00:11:06 hostnaem Tor[1907]: set_options(): Bug: Acting on config options left us in a broken state. Dying.

This just happened on my 0.2.7.0-alpha-dev build. resolv.conf contains only a "search" parameter, but no nameservers.

Our existing OOS code kills low-priority OR connections. But really, we need to look at all connections that an adversary might be able to create (especially dir and exit connections), or else an adversary will be able to open a bunch of those, and force us to kill as many OR connections as they want.

This problem is the reason that DisableOOSCheck is now on-by-default.

It would be handy if the following roles were split up:

1) The list of IP:Orport:Identity to which every relay should upload every descriptor. 2) The list of IP:Orport:Identity from which caches should expect to find canonical consensuses and descriptors. 3) The list of IP:Orport:Identity from which non-caches should expect to bootstrap consensuses and descriptors. (See 'fallbackdir') 4) The list of keys that must sign a vote or a consensus. 5) The list of IP:Orport:Identity that authorities use when sending and receiving votes.

Splitting roles up in this way would better prepare us for an implementation of prop#257 down the road.

Once upon a time, the tor spec files and proposals were in the Tor tarball, so they clearly were covered under Tor's copyright license (3-clause BSD).

But now they're in their own git repository.

I think maybe they technically have no copyright license now?

We should pick one (I vote cc-by) and try to apply it. This plan could become tricky for proposals, because there are a lot of authors on proposals by now.

Parent ticket for transitioning current and future client versions off the tor network with a minimal amount of pain.

From my prop271 branch:

 * XXXX prop271 this function is used in four ways: picking out guards for
 *   the old (pre-prop271) guard algorithm; picking out guards for circuits;
 *   picking out guards for testing circuits on non-bridgees;
 *   picking out entries when entry guards are disabled.  These options
 *   should be disentangled.

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.

We're creating a vote that is invalid, but try to make a consensus anyway like nothing's wrong. Then we fail doing that as described above.

The following bug warnings should probably be protocol warnings, or be caught earlier:

./src/test/fuzz_static_testcases.sh
Running tests for consensus
Feb 16 02:17:26.012 [warn] tor_timegm: Bug: Out-of-range argument to tor_timegm (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
Feb 16 02:17:30.133 [warn] sr_parse_commit: Bug: SR: Commit algorithm "sha6-256" is not recognized. (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
Feb 16 02:17:34.625 [warn] commit_decode: Bug: SR: Commit from authority 20EE989200EF98A75102B461DF62F01B2932C0D6 decoded length doesn't match the expected length (36 vs 40). (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
Feb 16 02:17:40.758 [warn] commit_decode: Bug: SR: Commit from authority B0F141F4B8CCBCC328572C71E5590BBA19775594 can't be decoded. (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
Running tests for descriptor
Feb 16 02:18:08.780 [warn] tor_timegm: Bug: Out-of-range argument to tor_timegm (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
Running tests for extrainfo
Feb 16 02:18:18.548 [warn] tor_timegm: Bug: Out-of-range argument to tor_timegm (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
...

I'm not sure whether we need this in 030, but it would be nice to fix them eventually.

I have a bridge in my recent Tor (post prop#271), and my state file now says:

Guard in=bridges rsa_id=C7BE8154678E7537CCAC60B097D51A8A7EF8BCDF bridge_addr=94.242.249.2:94 sampled_on=2017-05-04T10:39:09 sampled_by=0.3.1.0-alpha-dev unlisted_since=2017-05-11T05:47:41 listed=0 confirmed_on=2017-05-02T01:15:03 confirmed_idx=0 pb_use_attempts=1.000000 pb_use_successes=1.000000 pb_circ_attempts=11.000000 pb_circ_successes=11.000000 pb_successful_circuits_closed=11.000000

The unlisted_since and listed=0 are not surprising, since bridges will never be listed, right? Does that make my Tor do anything I shouldn't want it to do, like throw out the bridge line sooner than I'd want? I think no, because hey if it's in torrc it'll go back in, but maybe throwing out the path bias info early was not what we expect?

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.

Outright hostname lookup failures for previously configured hidden services prevent other options being set while DNS is down.

For example, I configure a hidden service redirecting to google.com while DNS is working. DNS subsequently stops working, e.g. nameserver becomes completely unreachable. If I then attempt to set a config option using the controller, it will not get set as long as tor cannot resolve the hidden service name.

Rejection of hidden service configurations (and hence any subsequent or unrelated config change) made while tor is running needs to be more tolerant of lookup failures.

The following attempts to validate the hidden service config currently in use (and previously validated when DNS was working). If the validation fails, it must be because DNS is down, so the existing config is retained. If the user was attempting to add a new hidden service config, then it doesn't get added.

Index: src/or/config.c
===================================================================
--- src/or/config.c     (revision 10545)
+++ src/or/config.c     (working copy)
@@ -963,10 +963,15 @@
     }
   }

-  if (running_tor && rend_config_services(options, 0)<0) {
-    log_warn(LD_BUG,
-       "Previously validated hidden services line could not be added!");
-    return -1;
+  if (running_tor && rend_config_services(options, 1)<0) {
+    log_warn(LD_CONFIG,
+       "Previously validated hidden services line no longer valid! Retaining existing hidden services config if there is one.");
+  }else{
+    if (rend_config_services(options, 0)<0){
+        log_warn(LD_BUG,
+           "Previously validated hidden services line could not be added!");
+        return -1;
+    }
   }

   if (running_tor) {
@@ -2920,9 +2925,10 @@
     }
   }

+/*
   if (rend_config_services(options, 1) < 0)
     REJECT("Failed to configure rendezvous options. See logs for details.");
-
+*/
   if (parse_virtual_addr_network(options->VirtualAddrNetwork, 1, NULL)<0)
     return -1;

[Automatically added by flyspray2trac: Operating System: All]