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

List tickets accepted, group by ticket owner. This report demonstrates the use of full-row display.

Results (1 - 100 of 115)

1 2

Cthulhu (2 matches)

Ticket Summary Component Milestone Type Created
Description
#13421 GoodBadISP's Revamp Internal Services/Wiki project Oct 15, 2014

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.


#13473 Sort Existing GoodBadISP page into tables Internal Services/Wiki task Oct 19, 2014

The existing GoodBadISP tables need sorting into the new format. All opinions, feedback and communications to that ISP must go in the correct section on ISPCorrespondence page to keep the primary page clean and to the point since it will grow substantially over time.

The new format should be available soon after this ticket is posted as it will be done for the US hosts (good experiences).


JacobHenner (1 match)

Ticket Summary Component Milestone Type Created
Description
#8177 Vidalia Help Documentation Out of Date Archived/Vidalia defect Feb 6, 2013

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.


Jaruga (5 matches)

Ticket Summary Component Milestone Type Created
Description
#24872 remove outdated tor relay security recommendations and update these wiki pages Community/Tor Support defect Jan 11, 2018

While working on #24497 I wanted to link to existing security related recommendations and found:

https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity https://trac.torproject.org/projects/tor/wiki/doc/OperationalSecurity

IMHO these are severely outdated and give bad advises.

I'm proposing to remove some outdated content and if no one disagrees I'll proceed soon. I'll send email to tor-dev about this.


#25865 Security Slider USer Manual Page is out of date Community/Tor Browser Manual defect Apr 20, 2018

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

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


#13703 Adding doc/HARDENING Community Tor: unspecified enhancement Nov 7, 2014

The two text files currently in the doc directory are doc/HACKING and doc/TUNING. The latter is the only one that deals with relay operation, and its subject is oddly specific: increasing the maximum number of file descriptors. If we're going to put critical documentation in the codebase, I think it would also be worthwhile to have a basic hardening guide. It could include suggestions like:

  • allowing only public key non-root SSH login
  • using a firewall
  • keeping your system up-to-date
  • not running any other programs (especially networked ones)
  • considering hardened or security-focused OS choices

Nick suggested that most of the actual information be contained in referenced links, which I agree with. There's no good reason to duplicate effort when there are, for example, so many good SSH hardening guides.

Let me know what you think, or if you have any contributions. If this is generally considered a good idea, I can start writing a draft.


#23345 Update transports.html in tb-manual.tp.o to include the snowflake PT Community/Tor Browser Manual enhancement Aug 28, 2017

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

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


#24320 Add an instruction to how to translate tbb-manual in your language Community/Tor Browser Manual task Nov 17, 2017

Add an instruction to how to translate tbb-manual in your language and how to submit it.


MB (1 match)

Ticket Summary Component Milestone Type Created
Description
#9328 o2online.de Live Check not working with enabled SSL strictness HTTPS Everywhere/EFF-HTTPS Everywhere defect Jul 25, 2013

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


ahf (2 matches)

Ticket Summary Component Milestone Type Created
Description
#11660 Make tor_spawn_background and related interfaces work the same on windows and *nix Core Tor/Tor Tor: unspecified defect Apr 30, 2014

Have a look at the tor_spawn_background unit tests. That's sure a lot of #ifdefs! It would be nice if our portability code actually let us write code to be portable across platforms: we should fix tor_spawn_background and tor_read_all_handle to act the same across platforms.


#21678 Unify Windows and Unix API for tor_read_all_handle() in util.c Core Tor/Tor Tor: unspecified enhancement Mar 8, 2017

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


arma (5 matches)

Ticket Summary Component Milestone Type Created
Description
#15713 toggling DisableNetwork during bootstrap causes delay Core Tor/Tor Tor: unspecified defect Apr 17, 2015

While testing a fix for #11879, Kathy and I noticed that if the bootstrap process is interrupted by setting DisableNetwork=1 via the control port, Tor waits about a minute after DisableNetwork is set back to 0 before continuing network activity. We observed this problem on a Mac OS 10.8.5 system. Possibly related tickets: #9229, #11069.

Once release candidates for Tor Browser 4.5 are available, this should be reproducible by following these steps:

  1. Start Tor Browser and click "Connect".
  2. Click "Open Settings" in the connection progress window to interrupt the bootstrap process.
  3. Click "Connect" again. Notice that there is a delay before the bootstrap makes more progress.

We are also able to reproduce it using Tor 0.2.6.6 and a manual (telnet) control port connection. Follow these steps (control port authentication is up to you):

  1. Remove all cached Tor data and start Tor like this:

./tor --defaults-torrc torrc-defaults -f torrc DisableNetwork 1

  1. Make a control port connection and issue this command:

SETCONF DisableNetwork=0

  1. Wait for bootstrapping to reach 25-50% and then do:

SETCONF DisableNetwork=1

  1. Re-enable network access:

SETCONF DisableNetwork=0 Notice that there is a delay before the bootstrap makes more progress.

We used the torrc-defaults file that ships with Tor Browser 4.5a5:

# If non-zero, try to write to disk less frequently than we would otherwise.
AvoidDiskWrites 1
# Where to send logging messages.  Format is minSeverity[-maxSeverity]
# (stderr|stdout|syslog|file FILENAME).
Log notice stdout
# Bind to this address to listen to connections from SOCKS-speaking
# applications.
SocksPort 9150
ControlPort 9151
CookieAuthentication 1
## fteproxy configuration
ClientTransportPlugin fte exec PluggableTransports/fteproxy.bin --managed

## obfs4proxy configuration
ClientTransportPlugin obfs2,obfs3,obfs4,scramblesuit exec PluggableTransports/obfs4proxy

## flash proxy configuration
#
# Change the second number here (9000) to the number of a port that can
# receive connections from the Internet (the port for which you
# configured port forwarding).
ClientTransportPlugin flashproxy exec PluggableTransports/flashproxy-client --register :0 :9000

## meek configuration
ClientTransportPlugin meek exec PluggableTransports/meek-client-torbrowser -- PluggableTransports/meek-client

Our torrc is also from Tor Browser and it just contains a few paths:

DataDirectory /Users/.../tb-11879.app/TorBrowser/Data/Tor
GeoIPFile /Users/.../tb-11879.app/TorBrowser/Data/Tor/geoip
GeoIPv6File /Users/.../tb-11879.app/TorBrowser/Data/Tor/geoip6

I will attach some log output.


#15715 spurious "Network is unreachable" error after setting DisableNetwork=1 Core Tor/Tor Tor: unspecified defect Apr 17, 2015

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.


#19162 Make it even harder to become HSDir Core Tor/Tor Tor: unspecified defect May 23, 2016

In #8243 we started requiring Stable flag for becoming HSDirs, but this is still not hard enough for motivated adversaries. Hence we need to make it even harder for a relay to become HSDir, so that only relays that have been around for long get the flag. After prop224 gets deployed, there will be less incentive for adversaries to become HSDirs since they won't be able to harvest onion addresses.

Until then, our current plan is to increase the bandwidth and uptime required to become an HSDir to something almost unreasonable. For example requiring an uptime of over 6 months, or maybe requiring that the relay is in the top 1/4th of uptimes on the network.


#17773 Should clients avoid using guards that lost the Guard flag? Core Tor/Tor Tor: unspecified enhancement Dec 8, 2015

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?


#18213 The parameter WarnUnsafeSocks does not work as specified in the documentation, no warning is logged in the log file Core Tor/Tor Tor: unspecified defect Feb 2, 2016

The parameter WarnUnsafeSocks does not work as specified in the documentation, no warning is logged in the log file when a connection is done to an ip address.

If WarnUnsafeSocks 1 (default) is set there is no warning in the log file. If you look at the code for log_unsafe_socks_warning, the only case where an error is logged is when safe_socks is true. safe_socks is true only when SafeSocks parameter is set, but not when WarnUnsafeSocks is set.

The code should be

if (safe_socks || options->WarnUnsafeSocks) {

instead of

if (safe_socks) {

atagar (1 match)

Ticket Summary Component Milestone Type Created
Description
#16348 Suppress exception chaining when PEP 3134 is merged Core Tor/Stem defect Jun 10, 2015

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()

boklm (2 matches)

Ticket Summary Component Milestone Type Created
Description
#11508 Test that about:tor page is properly loaded Applications/Quality Assurance and Testing enhancement Apr 14, 2014

During the last beta release we realized that some translators translate "about:tor" which breaks it. We should write a test that checks this crucial page is working in built bundles.


#11509 Make sure search engine strings are not translated Applications/Quality Assurance and Testing enhancement Apr 14, 2014

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


catalyst (2 matches)

Ticket Summary Component Milestone Type Created
Description
#22619 SessionGroup = Reading config failed Core Tor/Tor Tor: unspecified defect Jun 15, 2017

If i specify SessionGroup as described in manual. tor stops with error.

torrc:

SocksPort 9051 SessionGroup=1

Jun 15 16:46:24.700 [warn] Invalid SocksPort option '"SessionGroup=INT"'

Jun 15 16:46:24.700 [warn] Failed to parse/validate config: Invalid SocksPort/SocksListenAddress configuration

Jun 15 16:46:24.701 [err] Reading config failed--see warnings above.

second try

SocksPort 9051 SessionGroup=INT

Results into:

Jun 15 16:46:35.677 [warn] Invalid SocksPort option '"SessionGroup=1"'

Jun 15 16:46:35.678 [warn] Failed to parse/validate config: Invalid SocksPort/SocksListenAddress configuration

Jun 15 16:46:35.677 [warn] Invalid SocksPort option '"SessionGroup=1"'

Jun 15 16:46:35.678 [warn] Failed to parse/validate config: Invalid SocksPort/SocksListenAddress configuration

Jun 15 16:46:35.678 [err] Reading config failed--see warnings above.


#23756 tor's .gitlab-ci.yml is doing mirroring? why? Core Tor/Tor Tor: unspecified defect Oct 4, 2017

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:

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.


cypherpunks (2 matches)

Ticket Summary Component Milestone Type Created
Description
#21518 Pluggable transports for zero-rated services Applications/Orbot project Feb 20, 2017

Tor increases data usage, and most of the demographics that need Tor the most have very limited data, so please make PTs available for zero-rated services.

For example FreedomPop zero-rates WhatsApp (https://9to5mac.com/2016/08/17/freedompop-whatsapp-sim-free-iphone/) in 30 countries on a free ($0/month) plan.

A WhatsApp plugable transport would therefor allow users in poverty-stricken, massively oppressed countries to have unlimited free access to information through Tor.

I'm not sure if the component should be Orbot or Tor; the WhatsApp example is for mobile but there is also zero-rating for house internet, or someone might want to use a WhatsApp PT on a desktop/laptop/notebook with conventional Tor, tethered to a smartphone for the zero-rated protocol.


#25889 add support for Ubuntu 18.04 Community/Relays enhancement Apr 22, 2018

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

dgoulet (27 matches)

Ticket Summary Component Milestone Type Created
Description
#22893 prop224: Make intro point per-service and not per-descriptor Core Tor/Tor Tor: unspecified enhancement Jul 12, 2017

With the service branch in #20657, the current code design has intro points (IPs) per-descriptor meaning intro point objects are indexed inside a descriptor object.

We want to change that to a per-service design for which there is a set of intro points picked by the service which are then assigned to descriptor(s).

The reason to do such a thing is so we expose less IPs overtime thus minimizing the service exposure. Currently, because IPS are per-descriptor, once the descriptor rotates we also rotate IPs which bounds IPs' lifetime to the descriptor lifetime but this is not always true (and should not).

With a per-service design, IPs can live on between descriptors because they rotate at a different rate than the IPs and thus honoring its lifetime.


#23744 sched: Notification events have different meaning for each scheduler Core Tor/Tor Tor: unspecified defect Oct 2, 2017

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

#25616 Non-fatal assertion in hs_desc_encode_descriptor similar to #24972 Core Tor/Tor Tor: 0.3.5.x-final defect Mar 24, 2018

Tor 0.3.2.2.10 on NetBSD.

Mar 24 08:40:25.000 [warn] tor_bug_occurred_(): Bug: src/or/hs_descriptor.c:2360: hs_desc_encode_descriptor: Non-fatal assertion !(ret < 0) failed. (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: Non-fatal assertion !(ret < 0) failed in hs_desc_encode_descriptor at src/or/hs_descriptor.c:2360. Stack trace: (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc9551fe <log_backtrace+0x2e> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc969750 <tor_bug_occurred_+0xbd> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc93f8f0 <hs_desc_encode_descriptor+0x7d> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc9474ec <hs_service_run_scheduled_events+0x1924> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69d b819) Mar 24 08:40:25.000 [warn] Bug: 0xbc846e5e <have_completed_a_circuit+0x39> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc861ac4 <pt_free_all+0xee> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0x74c7f0e22834 <event_base_init_common_timeout+0xade> at /usr/pkg/lib/libevent-2.1.so.6 (on Tor 0.3.2 .10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0x74c7f0e22dc4 <event_base_init_common_timeout+0x106e> at /usr/pkg/lib/libevent-2.1.so.6 (on Tor 0.3. 2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0x74c7f0e23548 <event_base_loop+0x2da> at /usr/pkg/lib/libevent-2.1.so.6 (on Tor 0.3.2.10 31cc63deb69 db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc848dea <do_main_loop+0x239> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc84c4f3 <tor_main+0x1bf5> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc9b3cda <main+0x9> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819)

Mar 24 08:40:25.000 [warn] tor_bug_occurred_(): Bug: src/or/hs_service.c:2245: upload_descriptor_to_hsdir: Non-fatal assertion !(hs_desc_ encode_descriptor(desc->desc, &desc->signing_kp, &encoded_desc) < 0) failed. (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: Non-fatal assertion !(hs_desc_encode_descriptor(desc->desc, &desc->signing_kp, &encoded_desc) < 0) failed

in upload_descriptor_to_hsdir at src/or/hs_service.c:2245. Stack trace: (on Tor 0.3.2.10 31cc63deb69db819)

Mar 24 08:40:25.000 [warn] Bug: 0xbc9551fe <log_backtrace+0x2e> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc969750 <tor_bug_occurred_+0xbd> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc94773a <hs_service_run_scheduled_events+0x1b72> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69d b819) Mar 24 08:40:25.000 [warn] Bug: 0xbc846e5e <have_completed_a_circuit+0x39> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc861ac4 <pt_free_all+0xee> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0x74c7f0e22834 <event_base_init_common_timeout+0xade> at /usr/pkg/lib/libevent-2.1.so.6 (on Tor 0.3.2 .10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0x74c7f0e22dc4 <event_base_init_common_timeout+0x106e> at /usr/pkg/lib/libevent-2.1.so.6 (on Tor 0.3. 2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0x74c7f0e23548 <event_base_loop+0x2da> at /usr/pkg/lib/libevent-2.1.so.6 (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc848dea <do_main_loop+0x239> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc84c4f3 <tor_main+0x1bf5> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc9b3cda <main+0x9> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Invalid signature for service descriptor signing key: expired

Mar 24 08:40:25.000 [warn] tor_bug_occurred_(): Bug: src/or/hs_descriptor.c:2360: hs_desc_encode_descriptor: Non-fatal assertion !(ret < 0) failed. (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: Non-fatal assertion !(ret < 0) failed in hs_desc_encode_descriptor at src/or/hs_descriptor.c:2360. Stack trace: (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc9551fe <log_backtrace+0x2e> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc969750 <tor_bug_occurred_+0xbd> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc93f8f0 <hs_desc_encode_descriptor+0x7d> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc9474ec <hs_service_run_scheduled_events+0x1924> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc846e5e <have_completed_a_circuit+0x39> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc861ac4 <pt_free_all+0xee> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0x74c7f0e22834 <event_base_init_common_timeout+0xade> at /usr/pkg/lib/libevent-2.1.so.6 (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0x74c7f0e22dc4 <event_base_init_common_timeout+0x106e> at /usr/pkg/lib/libevent-2.1.so.6 (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0x74c7f0e23548 <event_base_loop+0x2da> at /usr/pkg/lib/libevent-2.1.so.6 (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc848dea <do_main_loop+0x239> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc84c4f3 <tor_main+0x1bf5> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819) Mar 24 08:40:25.000 [warn] Bug: 0xbc9b3cda <main+0x9> at /usr/pkg/bin/tor (on Tor 0.3.2.10 31cc63deb69db819)


#3733 Tor should abandon rendezvous circuits that cause a client request to time out Core Tor/Tor Tor: unspecified defect Aug 14, 2011
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.


#14322 torsocks fails to wrap setcap binaries Core Tor/Torsocks defect Jan 22, 2015

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

the install script which does setcap
setuid here:

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


#16934 youtube-dl (recent), torsocks 2.1.0 and TBB5+ failure Core Tor/Torsocks defect Aug 31, 2015

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.


#21084 sometimes we call circuit has_opened() more than 2 times on client side Core Tor/Tor Tor: unspecified defect Dec 26, 2016

We have a branch bug15618_030-testing at https://gitweb.torproject.org/user/dgoulet/tor.git that logs a warning when we call more than 2 times circuit has_opened() on a circuit. The patch was made to confirm the theory on #15618 related to a warning we see on relays. While until now I never saw the warning on relay side, I see it quite often on client side.

Based on the log messages, I think this is related to introduction point circuits and not rendezvous circuits as we thought. Basically it happens when we open a 4 hop circuit with last hop X, and immediately we extend that circuit to a 5 hop one with last hop Y, where Y is (I think) the introduction point. I got the warning 2 times in a row and the similarity between them is that they are 5 hop circuits with the last two hops 4 and 5 the same, but different hops 2 and 3.

Dec 25 13:15:15.000 [info] internal circ (length 5, last hop $D7316BF7FD633DD7474B18C33E1D5FDEB04D26A7): $A7C411B809D0AA98C4264917BB701ABF17B2181E(open) $B5212DB685A2A0FCFBAE425738E478D12361710D(open) $123F403DA94A74F959B7FE0E5B27FA57EFA12925(open) $1F4105C688E835A56AF3D66C787677B57240FFA2(open) $D7316BF7FD633DD7474B18C33E1D5FDEB04D26A7(open)
Dec 25 13:15:15.000 [info] entry_guards_note_guard_success(): Recorded success for primary confirmed guard sakujakira ($A7C411B809D0AA98C4264917BB701ABF17B2181E)
Dec 25 13:15:15.000 [info] circuit_send_next_onion_skin(): circuit built!
Dec 25 13:15:15.000 [warn] BLAM. Circuit has_opened() called 3 times.
Dec 25 13:15:15.000 [info] rend_client_introcirc_has_opened(): introcirc is open
Dec 25 13:15:15.000 [info] connection_ap_handshake_attach_circuit(): pending-join circ 3419634369 already here, with intro ack. Stalling. (stream 26 sec old)
Dec 25 13:15:15.000 [info] connection_ap_handshake_attach_circuit(): ready rend circ 2404371907 already here (no intro-ack yet on intro 2259155742). (stream 26 sec old)
Dec 25 13:15:15.000 [info] connection_ap_handshake_attach_circuit(): found open intro circ 2259155742 (rend 2404371907); sending introduction. (stream 26 sec old)
Dec 25 13:15:15.000 [info] rend_client_send_introduction(): Sending an INTRODUCE1 cell
Dec 25 13:15:15.000 [info] pathbias_count_use_attempt(): Used circuit 53293 is already in path state use succeeded. Circuit is a Hidden service client: Pending rendezvous point currently open.
Dec 25 13:15:16.000 [info] internal circ (length 5, last hop $D7316BF7FD633DD7474B18C33E1D5FDEB04D26A7): $A7C411B809D0AA98C4264917BB701ABF17B2181E(open) $5C01D5518D1F5A071C6F07D1F4630F577AB5B60A(open) $DA9DA02A7B0565DF5F3E961CA911E750072DCBBD(open) $1F4105C688E835A56AF3D66C787677B57240FFA2(open) $D7316BF7FD633DD7474B18C33E1D5FDEB04D26A7(open)
Dec 25 13:15:16.000 [info] entry_guards_note_guard_success(): Recorded success for primary confirmed guard sakujakira ($A7C411B809D0AA98C4264917BB701ABF17B2181E)
Dec 25 13:15:16.000 [info] circuit_send_next_onion_skin(): circuit built!
Dec 25 13:15:16.000 [warn] BLAM. Circuit has_opened() called 3 times.
Dec 25 13:15:16.000 [info] rend_client_introcirc_has_opened(): introcirc is open
Dec 25 13:15:16.000 [info] connection_ap_handshake_attach_circuit(): pending-join circ 3419634369 already here, with intro ack. Stalling. (stream 26 sec old)
Dec 25 13:15:16.000 [info] connection_ap_handshake_attach_circuit(): Intro circ 2259155742 present and awaiting ack (rend 2404371907). Stalling. (stream 26 sec old)
Dec 25 13:15:16.000 [info] connection_ap_handshake_attach_circuit(): Intro circ 3200472182 present and awaiting ack (rend 4286776399). Stalling. (stream 26 sec old)
Dec 25 13:15:16.000 [info] connection_ap_handshake_attach_circuit(): ready rend circ 2334828448 already here (no intro-ack yet on intro 4002828471). (stream 27 sec old)
Dec 25 13:15:16.000 [info] connection_ap_handshake_attach_circuit(): found open intro circ 4002828471 (rend 2334828448); sending introduction. (stream 27 sec old)
Dec 25 13:15:16.000 [info] rend_client_send_introduction(): Sending an INTRODUCE1 cell
Dec 25 13:15:16.000 [info] pathbias_count_use_attempt(): Used circuit 53301 is already in path state use succeeded. Circuit is a Hidden service client: Pending rendezvous point currently open.

#23108 prop224: Don't rotate all service descriptors at once Core Tor/Tor Tor: unspecified defect Aug 4, 2017

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 */

#23507 Add single onion unreachable address algorithm to prop224 Core Tor/Tor Tor: unspecified defect Sep 13, 2017

Here is how we make IPv6 (and other unreachable addresses) work with single-hop client and service connections to intro and rend points. It works for v2 single onion services. We talked about it for v3, but it never made it into the prop224 spec.

Here are the steps:

  1. The service chooses and connects to the intro point (possibly using a 3-hop path if it is a single onion service and can't reach it directly)
  2. The service always puts IPv4 and IPv6 in its descriptor link specifiers (if they are available in directory documents)
  3. If the link specifier has a reachable address, and the service is not a single onion service, a Tor2web client (currently v2 only) can use it to make a direct connection to the intro point
  4. Otherwise, the client connects over a 3-hop path via one of its reachable entry nodes

The process for client rendezvous is similar, but if the client knows that the service is a single onion service, it *must* connect to the rend point using a 3-hop path. (Again, this only matters for Tor2web, which is v2 only).


#23711 sched: KIST writes to kernel and get a "wants to write" notification right after Core Tor/Tor Tor: unspecified defect Sep 29, 2017

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.


#23712 sched: DESTROY cell on a circuit bypasses the scheduler Core Tor/Tor Tor: unspecified defect Sep 29, 2017

If you look at circuitmux_append_destroy_cell(), it is the one appending a DESTROY cell to the cmux queue and then calls channel_flush_from_first_active_circuit() if no writes are pending that is if the outbuf is empty (also looks at the out queue but that is always empty #23709).

In the case the flush is triggered, the cell is immediately put in the outbuf and written to kernel by libevent which completely bypasses the scheduler. Maybe it is what we want that is go as fast as we can in destroying a circuit? Don't know but it has this effect on the scheduler where the channel is scheduled with a "wants_to_write" event from the connection subsystem and ultimately the channel gets scheduled with nothing in the queue because it is already on the outbuf. For KIST, this is not ideal because KIST should control the flow of data to the kernel.

It seems there are two places we queue cells into a cmux queue: circuitmux_append_destroy_cell() and append_cell_to_circuit_queue(). The latter triggers a "has waiting cells" for the scheduler which is what we want but the former just bypasses it.

I think it should simply trigger that notify to the scheduler instead of flushing it by itself.


#24008 service_intro_point_new() should return NULL when passed a NULL extend_info Core Tor/Tor Tor: unspecified defect Oct 26, 2017

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.


#24181 Put IPv6 and unrecognised link specifiers in onion service EXTEND cells Core Tor/Tor Tor: unspecified defect Nov 8, 2017

Prop224 says:

The hidden service SHOULD NOT reject any LSTYPE fields which it
doesn't recognize; instead, it should use them verbatim in its EXTEND
request to the rendezvous point.

https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n1689

We should either remove this from the spec, or we should:

  • add a similar sentence for client descriptor lspecs
  • put unrecognised lspecs in descriptors in client intro EXTEND requests
  • put unrecognised lspecs in INTRODUCE cells in service rend EXTEND requests

#24346 prop224: Service stops uploading one of its two descriptors Core Tor/Tor Tor: unspecified defect Nov 18, 2017

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.


#25461 main event-loop spins consuming 100% of a CPU core at times Core Tor/Tor Tor: 0.3.5.x-final defect Mar 11, 2018

Lately have observed my exit hitting 100% cpu on the main even-loop thread, sometimes continuously, sometimes cyclically. Captured full-debug of recent cyclical event where CPU started at 30% and rose to 100%, for about one cycle. Chopped the 1G log into eight slices and took a simple function call-count histogram. What's notable is not an increase of calls during saturation, but a reduction of several that seem to relate to connection close events (conn_close_if_marked, flush_chunk). Left column is for the first slice where CPU was 30%, right column is for fourth slice where cpu was 100%. Functions with less than 1000 calls not included below, but complete histograms attached. Wrote about this on tor-relays:

https://lists.torproject.org/pipermail/tor-relays/2018-March/014730.html

This might be an attack of some kind, or perhaps a misbehavior related to the KIST scheduler.

append_cell_to_circuit_queue 6787                 append_cell_to_circuit_queue 7280
channel_flush_from_first_active_circuit 6781      channel_flush_from_first_active_circuit 7190
channel_process_cell 11904                        channel_process_cell 11813
channel_write_packed_cell 120301                  channel_write_packed_cell 126330
channel_write_to_kernel 8588                      channel_write_to_kernel 10048
circuit_consider_stop_edge_reading 146965         circuit_consider_stop_edge_reading 152665
circuit_get_by_circid_channel_impl 14128          circuit_get_by_circid_channel_impl 13468
circuit_receive_relay_cell 11483                  circuit_receive_relay_cell 11341
circuit_resume_edge_reading 1203                  circuit_resume_edge_reading 1231
conn_close_if_marked 39033                        conn_close_if_marked 779
conn_read_callback 14743                          conn_read_callback 15645
conn_write_callback 4531                          conn_write_callback 4447
connection_add_impl 1023                          connection_add_impl 739
connection_bucket_refill_helper 14787             connection_bucket_refill_helper 15842
connection_buf_read_from_socket 16196             connection_buf_read_from_socket 17152
connection_connect 1016                           connection_connect 732
connection_connect_sockaddr 1016                  connection_connect_sockaddr 732
connection_edge_package_raw_inbuf 237303          connection_edge_package_raw_inbuf 255347
connection_edge_process_relay_cell 22219          connection_edge_process_relay_cell 22332
connection_exit_begin_conn 3165                   connection_exit_begin_conn 2315
connection_exit_connect 1050                      connection_exit_connect 772
connection_handle_write_impl 9240                 connection_handle_write_impl 10539
connection_or_process_cells_from_inbuf 20042      connection_or_process_cells_from_inbuf 20448
flush_chunk 38192                                 flush_chunk 12
flush_chunk_tls 22283                             flush_chunk_tls 24061
free_outbuf_info_by_ent 8588                      free_outbuf_info_by_ent 10047
outbuf_table_add 8588                             outbuf_table_add 10014
read_to_chunk 6856                                read_to_chunk 7254
relay_lookup_conn 8459                            relay_lookup_conn 8525
relay_send_command_from_edge_ 119963              relay_send_command_from_edge_ 128738
rep_hist_note_exit_bytes 13913                    rep_hist_note_exit_bytes 14534
scheduler_set_channel_state 126896                scheduler_set_channel_state 133353
update_socket_info 6719                           update_socket_info 7160
update_socket_written 120297                      update_socket_written 126327

#11579 Torsocks should support Java Core Tor/Torsocks enhancement Apr 21, 2014

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.


#11724 Check recvmmsg() FD passing on Unix socket for TCP socket Core Tor/Torsocks enhancement May 4, 2014

recvmsg() is supported as of now. A full exit should be done here because Torsocks can't handle this inet socket with Tor.


#11727 Support shared onion pool for DNS resolution in separate process Core Tor/Torsocks enhancement May 4, 2014

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.


#13184 Add an option to whitelist networks Core Tor/Torsocks enhancement Sep 17, 2014

This warning is possible for anything socket trying to connect to a localhost address.

WARNING torsocks[12360]: [connect] Connection to a local address are denied since it might be a TCP DNS query to a local DNS server. Rejecting it for safety reasons. (in tsocks_connect() at connect.c:177)

We should implement a whitelist mechanism so the user can tell which local network is allowed such as localhost.


#15621 Kill the pre-version 3 intro protocol code with fire. Core Tor/Tor Tor: unspecified enhancement Apr 7, 2015

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.


#17945 Stop single hop client connecting to (Rendezvous) Single Onion Services Core Tor/Tor Tor: unspecified enhancement Dec 29, 2015

Tor2Web clients make a one-hop connection to the rendezvous point. Rendezvous Single Onion Services also make a one-hop connection to the rendezvous point. (Single Onion Services expect a client to make an extend request to the Single Onion Service at the end of a 3-hop path.)

This uses Tor as a one-hop proxy (in this case, to a single onion service), which we try to avoid, because it enables certain attacks.

For Rendezvous Single Onion Services, I don't know how to prevent this happening. (Should the rendezvous point intervene? Should we add something to the RSOS descriptor?)

For Single Onion Services, we can modify the Tor2Web client code so it doesn't make the SOS extend request, but falls back to rendezvous mode.


#19407 Support FD passing on Unix socket Core Tor/Torsocks enhancement Jun 13, 2016

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


#23579 sched: Add accessors for channel_pending list Core Tor/Tor Tor: unspecified enhancement Sep 19, 2017

Let's make this list private and have accessors.


#24193 Make v3 single onion services parse and use IPv6 introduce link specifiers Core Tor/Tor Tor: unspecified enhancement Nov 9, 2017

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.


#24451 Put IPv6 link specifiers in client EXTEND cells Core Tor/Tor Tor: unspecified enhancement Nov 28, 2017

Clients should put IPv6 link specifiers in the EXTEND cells to relays they choose from directory documents.

We need to do this in the same releases as #24181, to avoid adding an v3 onion service distinguisher.


#19926 BUG warning in connection_ap_attach_pending: waiting for rendezvous desc :* Core Tor/Tor Tor: unspecified defect Aug 17, 2016

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?


#19793 Torsocks - only torify .onion domains Core Tor/Torsocks enhancement Jul 31, 2016

What torsocks does: Routes all traffic through Tor.

What it should do: It shoud have an option to route .onion domains through Tor, while normal traffic is not routed through Tor.

Advantages This would allow Mail/XMPP servers to connect to .onion domains, without any configuration hassle.

Original discussion http://tor-talk.torproject.narkive.com/j7MtPG5T/torsocks-usewithtor-only-for-onion


feynman (1 match)

Ticket Summary Component Milestone Type Created
Description
#9022 Create an XMPP pluggable transport Obfuscation/Pluggable transport task Jun 5, 2013

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


hellais (1 match)

Ticket Summary Component Milestone Type Created
Description
#12823 Design and implement new deck format Archived/Ooni enhancement Aug 7, 2014

The current test deck format has some limitations.

These are namely:

1) There is no way of making an input be part of the test deck itself

2) The format is too verbose and contains redundant information (all of the ooniprobe command line options need to be explicitly specified)

For this reason I think we should have a new format that makes it possible to include inputs as part of the test deck. The test deck should therefore be a compressed container (tar and gzip seem to be good candidates as they are well supported in python).

It should then be possible to reference input files that are part of the test deck itself.


hiro (5 matches)

Ticket Summary Component Milestone Type Created
Description
#22530 Tor Browser 7.0 can't post on https://blog.torproject.org unless security slider is lowered Webpages/Blog defect Jun 8, 2017

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


#22637 Find a more maintainable approach for the signing-keys page Webpages/Website website redesign defect Jun 16, 2017

Right now we have this page: https://www.torproject.org/docs/signing-keys which is supposed to provide an official set of keys that have signed various Tor packages in the past.

We pointed to it from https://www.torproject.org/docs/verifying-signatures among other places.

But people keep generating new subkeys, so the text on that page goes out of date after a month or so.

We should come up with a better way to distribute these keys, in a way that provides good enough authenticity while being easy to automate.

Maybe that's a script that gets run every so often to generate the page automatically? Maybe that's creating a gpg keyring with the right keys on it, and getting rid of the webpage?

We can think of this as part of the grand website redo, but also we can think of it as a bitesized improvement that needs to be made and can be independent of the grand website redo.


#23574 Don't allow text injection in our 404 page Internal Services/Tor Sysadmin Team defect Sep 19, 2017

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

#22842 Create a knowledge base that's more in-depth than FAQs Webpages/Website WebsiteV3 task Jul 6, 2017

It would be useful for visitors to our web pages to have access to content that:

  • goes into more depth than a FAQ entry
  • is more formal than a blog post
  • is less comprehensive than a reference manual section
  • is more stable than a wiki page

These pages would form sort of a knowledge base or resource section.


#23809 Add instructions for running a relay on a Raspberry Pi Webpages/Website website redesign task Oct 10, 2017

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.


irl (1 match)

Ticket Summary Component Milestone Type Created
Description
#18342 Provide more accurate reverse DNS results Metrics/Onionoo defect Feb 18, 2016

What DNS server does onionoo use for reverse DNS lookups to generate the host_name entries?

https://onionoo.torproject.org/details?search=SGGS

example, of onionoo's reverse lookup results for SG.GS relays, all IPs:

+----------+--------------+
| nickname | host_name    |
+----------+--------------+
| SGGSUK4  | 124.6.36.196 |
| SGGSHK0  | 124.6.32.230 |
| SGGSUK6  | 124.6.36.198 |
| SGGSUK0  | 124.6.36.230 |
| SGGSUK3  | 124.6.36.195 |
| SGGSUK7  | 124.6.36.199 |
| SGGSUK1  | 124.6.36.193 |
| SGGSUK8  | 124.6.36.200 |
| SGGSUK5  | 124.6.36.197 |
| SGGSUK2  | 124.6.36.194 |
| SGGSLAX0 | 124.6.40.230 |
| SGGSNYC0 | 124.6.44.230 |
| SGGSUK9  | 124.6.36.201 |
+----------+--------------+

compare that with http://torstatus.blutmagie.de/index.php


isis (6 matches)

Ticket Summary Component Milestone Type Created
Description
#12802 BridgeDB needs Nagios checks for the Email Distributor Obfuscation/BridgeDB enhancement Aug 6, 2014

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


#16564 Add a line to bridge descriptors specifying they're bridges? Core Tor/Tor Tor: unspecified enhancement Jul 12, 2015

Right now if my bridge descriptor gets uploaded to the directory authorities, poof I'm now a public relay, even if I didn't mean to be.

That's not the end of the world, since I am technically offering to be a relay already, and the only difference is that I didn't opt to publish my descriptor myself.

But still it seems like we should make the choice explicit inside the descriptor.


#22948 Padding, Keepalive and Drop cells should have random payloads Core Tor/Tor Tor: unspecified defect Jul 16, 2017

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.


#22776 Implement the remaining cryptographic protocols for Hyphae Obfuscation/BridgeDB enhancement Jun 30, 2017

We'll need:

1) Back-Maxwell Rangeproofs (requires Borromean Ring Signatures) 2) A ZKP compiler 3) Testvectors for Ristretto (a.k.a. Decaf for curve25519)


#25651 Handle incoming extend2/extended2 fragmented requests/replies. (prop249) Core Tor/Tor Tor: 0.3.5.x-final enhancement Mar 27, 2018

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.

#25654 Create a testing-only handshake for shaking the bugs out of wide create cells (prop249) Core Tor/Tor Tor: 0.3.5.x-final enhancement Mar 27, 2018

We need a handshake that doesn't fit in a single CREATE cell so that we can make sure that prop249 is implemented properly.

My current recommendation is "nnttoorr", which is the same as ntor, but every byte is repeated twice. ;)


karsten (2 matches)

Ticket Summary Component Milestone Type Created
Description
#24217 Specify data format and aggregation process of statistics offered by metrics.tp.o Metrics/Statistics enhancement Nov 10, 2017

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


#25459 Compare total consensus weights across bandwidth authorities Metrics/Analysis enhancement Mar 10, 2018

We were talking today about how to compare bandwidth authorities, and make sure that different implementations are producing similar figures.

One easy way to compare bandwidth authority implementations is to compare their total bandwidth weights.

For example, this is the total bandwidth weight in the consensus:

$ cat Library/Application\ Support/TorBrowser-Data/Tor/cached-microdesc-consensus | grep "^w" | cut -d= -f2 | grep -v Unmeasured | paste -s -d + - | bc
43763163

Do you think we can do a graph of total bandwidth weight for votes? Should this go somewhere on metrics? Or should it be a once-off thing that Tom (or someone else) does?


lunar (1 match)

Ticket Summary Component Milestone Type Created
Description
#11355 Provide obfsproxy nightlies in our debian repositories Obfuscation/Obfsproxy task Mar 28, 2014

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!


mikeperry (1 match)

Ticket Summary Component Milestone Type Created
Description
#2161 Allow subscription to external rule feeds HTTPS Everywhere/EFF-HTTPS Everywhere enhancement Nov 6, 2010

The ultimate direction we want to go is towards an adblock plus model, where people can subscribe to rule feeds that are relevant to them, maintained by third parties. This involves both altering our XML schema to include a 'rulefeed' envelope tag, and adding a bit of UI to add and manage subscription urls.

It also depends upon a few enhancements being completed first. These are in the child ticket list below:


n8fr8 (6 matches)

Ticket Summary Component Milestone Type Created
Description
#2424 Android purges firewall rules after network disable/airplane mode. Applications/Orbot defect Jan 22, 2011

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.


#3595 Connections with IPv4-mapped IPv6 addresses bypass transproxy Applications/Orbot defect Jul 14, 2011

A user (DEplan on #guardianproject) reported that Gibberbot was using his real IP despite Orbot's transproxy being turned on; further research led to the conclusion that recent releases of Android seem to use IPv4-mapped IPv6 adresses for a large portion of connections. For examples, please see http://pastebin.com/Z4KDDq40. These connections completely bypass transproxy.

I am not yet sure about the circumstances under which Android employs these addresses.

The problems in finding a solution are that Android usually does not include ip6tables (though Orbot could simply package that) and kernels do usually not include IPv6 netfilter modules. The latter is a major issue, since Orbot can't package modules for every single kernel a user might be running.

As a side note, IPv6 does not support NAT (which is what transproxying is based on).

I'll try to figure out what triggers this behaviour of Android and find possible solutions (using sysctl to disable IPv6 does not solve it).


#5393 orbot relay bug - orbot is not setting the relay values into torrc properly causing orbot to not work when set as relay Applications/Orbot defect Mar 15, 2012

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.


#2761 Orbot Service not shutting down Applications/Orbot defect Mar 15, 2011

Behaviour: When closing tor network with big Button and exiting Orbot after tor is "deactivated", privoxy is still running and the Orbot service is not stopped.

Actions:

  • Killing Privoxy from shell stops the privoxy process (OK)
  • Killing Orbot process simply restarts the process (BAD)

Env:

  • Running Orbot v1.0.4.1
  • Android Froyo 2.2.1 speedmod kernel
  • Samsung Galaxy

#3775 Permission error on Orbot Applications/Orbot defect Aug 21, 2011

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.


#5469 Orbot: can't specify node restrictions Applications/Orbot defect Mar 24, 2012

I'm using Orbot (v0.2.3.10-alpha-1.0.7-FINAL, on Android ICS v4.0.1) and I can't seem to get the exit node I request. In the Exit and Entrance Node fields I have "{us}" entered, yet sometimes I get IP's outside the US. Yesterday I got a UK ip.

Also, at random (usually after 30 minutes or so) I seem to lose connection to the Tor network without Orbot notifying me. I'm using Pandora from Canada.


nickm (26 matches)

Ticket Summary Component Milestone Type Created
Description
#15421 Relay crash when reloading and resolv.conf is empty Core Tor/Tor Tor: 0.3.5.x-final defect Mar 21, 2015
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.


#17278 Fix malleable relay crypto Core Tor/Tor Tor: unspecified defect Oct 7, 2015

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


#19984 Use a better set of comparison/evaluation functions for deciding which connections to kill when OOS Core Tor/Tor Tor: unspecified defect Aug 25, 2016

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.


#25386 Link Rust Tests to C Dependencies in Tor (allow integration testing from Rust to C) Core Tor/Tor Tor: 0.3.4.x-final defect Feb 28, 2018

currently, it is not possible to call C Tor, directly or indirectly, from rust tests. one of the following must be done:

  1. provide rust stubs for all C functions that may be needed for tests (impractical)
  1. test rust functions from C (so we will have C tests calling Rust functions calling C functions)
  1. link C functions into rust doctests (preferred)
  1. never call C-using rust functions in tests (leads to poor test coverage, very bad)

my branch https://cgit.alxu.ca/tor.git/commit/?h=fix-rust-tests implements option 3 poorly. this is a bad solution firstly because it is very ugly, and secondly because it does not properly pass the system linking arguments, e.g. -L/opt/ssl. thirdly, it may hide problems in or cause to be compiled incorrectly dependency crates.

this ticket blocks a number of rust improvements, since of course we would like to actually test the improvements, and doctests are the best way to do it in rust.


#18346 Separate the various roles that directory authorities play, from a configuration POV Core Tor/Tor Tor: unspecified enhancement Feb 19, 2016

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.


#18637 Have OOM handler look at all memory consumption, not just some Core Tor/Tor Tor: unspecified enhancement Mar 25, 2016

Just because our OOM handler doesn't know how to free every kind of memory we allocate, doesn't mean we shouldn't teach it to consider our total allocation when deciding that we're low on memory.

For platforms where malloc() can return NULL, we could have it look at that too.


#18788 Make the copyright license clear for torspec and proposals Core Tor/Tor Tor: unspecified enhancement Apr 11, 2016

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.


#18636 Write sub-proposals for each part of prop257: Refactoring authorities. Implement as appropriate. Core Tor/Tor Tor: unspecified project Mar 25, 2016

Proposal 257 outlines a pretty large amount of stuff to do, but each part of it probably needs its own proposal. Let's get cracking on that !


#15940 Make a standard transition plan for killing off a client version Core Tor/Tor Tor: unspecified task May 6, 2015

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


#15941 Form a plan for killing off client versions which assume they'll live forever Core Tor/Tor Tor: unspecified task May 6, 2015

From at least 0.2.4 to 0.2.6, tor client versions assume that they will keep on using the network forever. They have no "request to stop" code or other mechanisms that prevent them becoming a drain on the network.

It would help to plan their transition out at some point, so we can work out what to do to make version obsolescence in future.

See #15233 for killing off 0.2.2 and 0.2.3


#20835 Refactor choose_good_entry_server so it is (almost) never used Core Tor/Tor Tor: unspecified task Nov 29, 2016

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.

#21509 Fuzz v3 hidden services Core Tor/Tor Tor: unspecified task Feb 19, 2017

If we want the fuzzer to effectively fuzz v3 hidden services, we need to:

  • fuzz GET requests: #21476
  • fuzz POST requests: #21478
  • add v3 GET and POST requests to the fuzzing corpus
  • add tokens from v3 GET and POST requests as new fuzzing token lists
  • disable the encrypted connection check when fuzzing (we should do this for v2 services as well)
  • create a v3 descriptor fuzzer
  • add v3 descriptor examples to the fuzzing corpus
  • add tokens from v3 descriptors as a new fuzzing token list

#16579 (Sandbox) Caught a bad syscall attempt (syscall socket) Core Tor/Tor Tor: unspecified defect Jul 14, 2015

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.


#18308 Use a better pattern for "create mutex if not already initialized" Core Tor/Tor Tor: unspecified defect Feb 12, 2016

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.


#18321 Exclude our own vote from the consensus if we think our own vote is invalid Core Tor/Tor Tor: unspecified defect Feb 16, 2016

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.


#19329 Integrate callgraph complexity measures into our regular process Core Tor/Tor Tor: unspecified defect Jun 7, 2016

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


#21474 Fix make test-fuzz-corpora warnings Core Tor/Tor Tor: unspecified defect Feb 15, 2017

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.


#22264 Remove old cached_dir_t code Core Tor/Tor Tor: unspecified defect May 15, 2017

I'm pretty sure that with the completion of prop 278, we no longer use the old cached_dir_t code for anything at all. Let's rip it out!


#22351 Should bridge lines in the state file use unlisted_since? Core Tor/Tor Tor: unspecified defect May 23, 2017

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?


#26395 tor_bug_occurred_(): Bug: ../src/or/consdiffmgr.c:261: cdm_diff_ht_check_and_note_pending: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed. Core Tor/Tor Tor: 0.3.5.x-final defect Jun 18, 2018

Logged by my relay : B143D439B72D239A419F8DCE07B8A8EB1B486FA7

Here is the full entry

Jun 17 17:00:54.000 [warn] tor_bug_occurred_(): Bug: ../src/or/consdiffmgr.c:261: cdm_diff_ht_check_and_note_pending: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed. (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed in cdm_diff_ht_check_and_note_pending at ../src/or/consdiffmgr.c:261. Stack trace: (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug:     /usr/bin/tor(log_backtrace+0x42) [0x7ff791259802] (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug:     /usr/bin/tor(tor_bug_occurred_+0xca) [0x7ff7912744aa] (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug:     /usr/bin/tor(consdiffmgr_rescan+0xc9d) [0x7ff7911f070d] (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug:     /usr/bin/tor(+0x5739f) [0x7ff79112639f] (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug:     /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x414) [0x7ff7907dd254] (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug:     /usr/bin/tor(do_main_loop+0x255) [0x7ff791127585] (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug:     /usr/bin/tor(tor_main+0x1e75) [0x7ff79112aff5] (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug:     /usr/bin/tor(main+0x19) [0x7ff791122d49] (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug:     /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7ff78f7f2ead] (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug:     /usr/bin/tor(+0x53d99) [0x7ff791122d99] (on Tor 0.3.2.10 )

#17295 Route-selection and guard-selection logic completely replaced Core Tor/Tor Tor: unspecified enhancement Oct 7, 2015

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.


#20719 prop271 -- make parameters configurable Core Tor/Tor Tor: unspecified enhancement Nov 18, 2016

#20931 [prop271] Generate GUARD controller events Core Tor/Tor Tor: unspecified enhancement Dec 8, 2016

#22962 Clarify the security severity of issues that make denial of service easier Core Tor/Tor Tor: unspecified task Jul 18, 2017

https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/SecurityPolicy

In #22948, we discovered that the relay integrity digest was easier to guess than it should be. This makes the following classes of attacks easier:

  • sending bandwidth and guessing the integrity digest, and
  • modifying cells and manipulating the integrity digest.

#449 dns failures prevent legitimate options being set Core Tor/Tor Tor: unspecified defect Jun 9, 2007

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]


#21454 tor_version_compare and version spec comparison order are inconsistent Core Tor/Tor Tor: unspecified defect Feb 14, 2017

Similar to #21449, when we compare versions, we compare the status before the patchlevel, and then compare status tag and SCM information.

But the spec says:

1. The Old Way
...
We compare the elements in order (major, minor, micro, status, patchlevel, cvs)
...
2. The New Way
...
MAJOR, MINOR, MICRO, and PATCHLEVEL are numbers
...
All versions should be distinguishable purely by those four numbers.

The STATUS_TAG is purely informational
...
If we *do* encounter two versions that differ only by status tag, we compare them lexically
...

This doesn't matter much at the moment because we don't use patchlevels.

But we should fix this issue, probably by modifying the spec.

Reported by arma.


1 2
Note: See TracReports for help on using and creating reports.