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

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

Cthulhu (2 matches)

Ticket Summary Component Milestone Type Created
#13421 GoodBadISP's Revamp Community/Relays 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 Community/Relays 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).

Hello71 (1 match)

Ticket Summary Component Milestone Type Created
#22233 Reconsider behavior on .z URLs with Accept-Encoding header Core Tor/Tor Tor: unspecified defect May 11, 2017

In proposal 278, I said:

  If a directory server receives a request to a document with the ".z"
  suffix, where the client does not include an "Accept-Encoding" header,
  the server should respond with the zlib compressed version of the
  document for backwards compatibility with client that does not support
  this proposal.

But on #22206 it became apparent that we've got a problem there: there are already tools (built e.g. on wget) that ask for the .z URL but which send "Accept-Encodings: Identity."

And onn #22206, Yawning says:

an error (or a double compressed payload) should be returned when the .z request contains an Accept-Encoding header that specifies anything other than identity/deflate.

We'd like the end result here to be something where new Tor clients can interoperate with older directory caches without breaking anything, and getting the new compression type if they support it. And we certainly don't want anybody doing two layers of compression: that's a waste of cycles. But we should see if there's a way where we can be more standards compliant without breaking anything we care about.

Jaruga (3 matches)

Ticket Summary Component Milestone Type Created
#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.

#20537 Tor Browser User Manual needs meta section Community/Tor Browser Manual defect Nov 2, 2016

The Tor Browser User Manual on https://tb-manual.torproject.org/windows/en-US/ needs a section covering

a) where to find the source, b) how it is licensed, and c) where and how to report bugs.


#24872 remove outdated tor relay security recommendations and update these wiki pages Community/Relays 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.

Jkee299 (1 match)

Ticket Summary Component Milestone Type Created
#28541 Exit HTTPS Everywhere project Nov 20, 2018


MB (1 match)

Ticket Summary Component Milestone Type Created
#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

arma (5 matches)

Ticket Summary Component Milestone Type Created
#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 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

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

#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) {

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

atagar (1 match)

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

with tor- 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
  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
  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
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 3480, in _handle_event
  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:

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

    while True:

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__':

boklm (2 matches)

Ticket Summary Component Milestone Type Created
#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.

cohosh (1 match)

Ticket Summary Component Milestone Type Created
#25483 Windows reproducible build of snowflake Circumvention/Snowflake project Mar 13, 2018

Breaking this out from https://trac.torproject.org/projects/tor/ticket/19001#comment:36, where dcf wrote,

I pushed some preliminary code for getting started with a windows reproducible build.


It doesn't work yet; after ./mkbundle-windows.sh versions.alpha, it eventually fails with:

+ /home/ubuntu/build/webrtc/src/out_bootstrap/gn gen out/Release '--args= target_os="win" target_cpu="x86" is_debug=false treat_warnings_as_errors=false is_component_build=false is_clang=true use_sysroot=false clang_use_chrome_plugins=false clang_base_path="/home/ubuntu/build/clang" rtc_include_opus=false rtc_include_ilbc=false rtc_include_internal_audio_device=false rtc_include_tests=true'
ERROR at //build/config/BUILDCONFIG.gn:239:3: Assertion failed.
  assert(target_os == host_os, "Win cross-compiles only work on win hosts.")
Win cross-compiles only work on win hosts.

But at this point one can ssh into the build VM and start debugging the build failures.

Some further notes from what we've discovered so far.

cypherpunks (1 match)

Ticket Summary Component Milestone Type Created
#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.

dgoulet (1 match)

Ticket Summary Component Milestone Type Created
#15516 Consider rate-limiting INTRODUCE2 cells when under load Core Tor/Tor Tor: unspecified enhancement Mar 30, 2015

In #15463, we're seeing an effective denial of service against a HS with a flood of introductions. The service falls apart trying to build rendezvous circuits, resulting in 100% CPU usage, many failed circuits, and impact on the guard.

We should consider dropping INTRODUCE2 cells when the HS is under too much load to build rendezvous circuits successfully. It's much better if the HS response in this situation is predictable, instead of hammering at the guard until something falls down.

One option is to add a HSMaxConnectionRate(?) option defining the number of INTRODUCE2 we would accept per 10(?) minutes, maybe with some bursting behavior. It's unclear what a useful default value would be.

We could try to use a heuristic based on when rend circuits start failing, but it's not obvious to me how that would work.

feynman (1 match)

Ticket Summary Component Milestone Type Created
#9022 Create an XMPP pluggable transport Circumvention/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.

hiro (5 matches)

Ticket Summary Component Milestone Type Created
#22530 Redirection loop with disabled js on every page of blog.torproject.org 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

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

#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 :


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

#23809 Add instructions for running a relay on a Raspberry Pi Community/Tor Support 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.

#28065 Tor web docs Internal Services/Services Admin Team defect Oct 16, 2018

During the meeting in CDMX some of us chatted about the possibility to build and maintain a sort of Tor web docs (like the mozilla web docs [1]).

The idea is to collect all the techniques we use to make websites tor-browser and privacy friendly in a single place. We could also include the reasoning behind doing certain things in pure css vs js. Or why we decide to do things in a certain way.

Some topic that I have been thinking about are:

  • Why tor browser is slightly different from Firefox (or another browser)
  • Why does my app work differently in tor browser?
  • How can I make my app compatible for people that do not use JS?
  • Code examples for css and js
  • Server side website programming, what to keep in mind...

While all these topics are documented in various articles around the interwebs, I kinda think we (tor community) should own something like this, since it would also help to push forward the idea that the web as we know it needs to change.

Up to now I have always thought this sort of content belonged to the styleguide. Recently I have been thinking that while the individual implementation details of what use in our websites can be included in the styleguide, the reasoning behind those and the general implementations should be put somewhere else.

Also I do not think these topics belong directly to the dev portal, as I tend to think that should be about developing on tor rather than considering how the web works a bit differently when using tor browser. Unless we would rather do a specific section regarding all this in the web portal.

Further things to consider:

  • Kevin (on cc) is working on a Tor friendliness scanner tool for websites.
  • We see often threads like this [2] on our mailing lists. This one is about how to avoid privacy leaks for onion services, but we might identify more similar best practice tips being discussed.

[1] https://developer.mozilla.org/en-US/ [2] https://lists.torproject.org/pipermail/tor-onions/2018-August/000295.html

irl (5 matches)

Ticket Summary Component Milestone Type Created
#28271 Check OnionPerf instances from Nagios Metrics/Onionperf task Oct 31, 2018

There are a few things that we can check, some are easier than others.

  • Is the host up and the webserver running? (this is easy with built-in checks)
  • Is the tgen server running on the Internet? (this is easy with built-in checks)
  • Is the analyze task running? (needs a plugin)
  • Is the tgen server running on an Onion service? (needs a plugin)

For monitoring the Onion service, I'm looking at reusable plugins, so there are two tests. One checks to see how old the descriptor is and a second test actually tries connecting to the service. The first of these tests is affected by #28269 (but not blocked) and both are blocked by onionperf#42.

As a workaround for monitoring the Onion service, which really is the bit that is breaking, we can instead monitor the analysis of timeouts from Tor Metrics' CSV files.

#28322 Deploy better notification system for operational issues Metrics project Nov 5, 2018

We have been using Nagios to monitor Onionoo for a few years now, and we recently extended (#28242) or added new Nagios checks (#28271).

We should consider adding even more checks. One year ago we discussed what checks that could be, and it seems like this list could still serve as starting point for adding new checks now.

#29315 Write down guidelines for adding new stats Metrics/Website enhancement Feb 3, 2019

We're going to add a few new stats to Tor Metrics in the next months: BridgeDB, PrivCount, sbws, and maybe more, in no specific order.

Let's write down some initial guidelines what we expect and what others can expect. And let's refine these initial guidelines as we add some actual stats. Once we're happy with them we should put them on Tor Metrics.

Assigning this ticket to myself for now, as I'm going to post a first draft soon. Cc'ing a few folks who we'll be working together with on adding new data.

#30749 research website anchors go to wrong place Webpages/Research defect Jun 4, 2019

https://research.torproject.org/safetyboard/#guidelines has the section header clobbered by the purple bar at the top of the page. maybe there's a way to have the anchor work better?

irl responds: "there seems to be something in the styleguide for this that wasn't there when i first put this together .anchor-spacer is the css class "

#30791 Expose onionperf data directories via webserver for op-nl, op-hk and op-us Metrics/Onionperf task Jun 6, 2019

juga (1 match)

Ticket Summary Component Milestone Type Created
#28045 Start supporting python 3.7 Core Tor/sbws sbws: 1.2.x-final defect Oct 15, 2018

lunar (1 match)

Ticket Summary Component Milestone Type Created
#11355 Provide obfsproxy nightlies in our debian repositories Archived/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.


mikeperry (1 match)

Ticket Summary Component Milestone Type Created
#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
#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.

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


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


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

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

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

#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 '' 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.

#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 (29 matches)

Ticket Summary Component Milestone Type Created
#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]

#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

#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 and tor crashes within seconds of starting, before any clients can connect I think.

Jul 14 13:13:07.000 [notice] Tor (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
Jul 14 13:13:07.187 [notice] Opening Socks listener on
Jul 14 13:13:07.187 [notice] Opening Socks listener on
Jul 14 13:13:07.187 [notice] Opening Control listener on
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)
$ uname -r

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.

#16598 fsync ed25519 master key files before closing them. Core Tor/Tor Tor: unspecified defect Jul 15, 2015

Weasel says this is a good idea, and IMO it can't hurt.

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

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

#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


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.

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

#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 !

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

#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

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

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

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

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

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

#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:

Running tests for consensus
Feb 16 02:17:26.012 [warn] tor_timegm: Bug: Out-of-range argument to tor_timegm (on Tor d633c4757c1392fb)
Feb 16 02:17:30.133 [warn] sr_parse_commit: Bug: SR: Commit algorithm "sha6-256" is not recognized. (on Tor 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 d633c4757c1392fb)
Feb 16 02:17:40.758 [warn] commit_decode: Bug: SR: Commit from authority B0F141F4B8CCBCC328572C71E5590BBA19775594 can't be decoded. (on Tor d633c4757c1392fb)
Running tests for descriptor
Feb 16 02:18:08.780 [warn] tor_timegm: Bug: Out-of-range argument to tor_timegm (on Tor d633c4757c1392fb)
Running tests for extrainfo
Feb 16 02:18:18.548 [warn] tor_timegm: Bug: Out-of-range argument to tor_timegm (on Tor d633c4757c1392fb)

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

#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

#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= sampled_on=2017-05-04T10:39:09 sampled_by= 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?

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


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.

#25386 Link Rust Tests to C Dependencies in Tor (allow integration testing from Rust to C) Core Tor/Tor Tor: unspecified 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.

#27245 Don't store (micro)descriptor text on the heap so much. Core Tor/Tor Tor: unspecified defect Aug 21, 2018

We could use less RAM for our (micro)descriptor text if we kept the .new file mmapped, so that we didn't need to use the heap to hold them.

#28248 Add comments around rust compilation flags Core Tor/Tor Tor: unspecified enhancement Oct 30, 2018

In particular, we should make sure that all the new and changed items in https://github.com/torproject/tor/pull/381 have explanatory comments.

#28481 Tor's startup time is getting slower on Android Core Tor/Tor Tor: unspecified defect Nov 16, 2018

When upgrading Briar's Tor binaries from to, we noticed a difference in Tor's startup time on older Android phones.

Measuring the startup time of several recent Tor versions revealed an interesting pattern. The time that elapses between starting the Tor process and the creation of the authentication cookie file hasn't changed across versions, but the time between the creation of the cookie file and the response to the AUTHENTICATE command has changed substantially. (Briar sends the AUTHENTICATE command as soon as the cookie file's created.)

I measured five runs of each version on a Motorola Moto G 4G running Android 5.1. Here are the min and max times in seconds for each version:

Tor version Min Max

The min and max have both increased substantially since 0.2.9, and the distribution has widened. This is having a noticeable impact on how long it takes for Briar to connect to contacts when the app's started.

I'll repeat these experiments on Linux x64 to see whether this is Android-specific.

#29898 How can we automatically add #else and #endif comments? Core Tor/Tor Tor: 0.4.2.x-final defect Mar 26, 2019

In 0.3.5? we ran a script to automatically add comments to #else and #endif blocks. These comments help us work out how these macros are nested.

But since then, we've added new #else and #endif without the comments.

Should we run the script again in 0.4.1? Should we run it before we branch off each new maint branch? Should we automatically run it before we commit or merge?

I hope nickm has some good feedback on this idea.

pde (5 matches)

Ticket Summary Component Milestone Type Created
#3777 Should not generate mixed-content warnings if rewriting all http to https HTTPS Everywhere/EFF-HTTPS Everywhere defect Aug 21, 2011

As far as I can tell, Firefox produces mixed-content warnings on an https page that references resources (images, scripts, etc) via http, even if HTTPS Everywhere can rewrite all of those http URLs to use https. (HTTPS Everywhere does rewrite resource requests, right?)

Ideally, if HTTPS Everywhere successfully rewrites every http request from a page to an https request, the page should not generate a mixed content warning. (Though I'd still like to see some indication that the page was only secure due to HTTPS Everywhere, so I know to report the insecure resources to the site owner.)

#4278 MSDN navigation breakage (due to Origin: header omission?) HTTPS Everywhere/EFF-HTTPS Everywhere defect Oct 20, 2011

Reported here: https://bugzilla.mozilla.org/show_bug.cgi?id=694611

Test case:

Clicking on the fold-out tabs on the left of this page produces no results:


#6276 Hiding the context menu button breaks the Tools->HTTPS Everywhere menu HTTPS Everywhere/EFF-HTTPS Everywhere defect Jul 2, 2012

When you drag the httpse icon from the urlbar to 'menu_bar.view.toolbars.customize' window you lose the 'menu_bar.tools.https_everywhere' drop down menu content for httpse, though the menu item itself is still there. At that point, the only way to configure httpse is via 'about:addons'. Or of course to restore the icon to the urlbar.

Seems to me the drop down menu content should remain regardless of where the icon is, or is not.

FF 10.0.3 ESR HTTPS-E v2.1

#6592 HTTPS Everywhere Causes WordPress.com Zemanta Media Gallery To Not Work HTTPS Everywhere/EFF-HTTPS Everywhere defect Aug 11, 2012


Every version of HTTPS Everywhere that I have tested has caused a problem with at least one of the common websites that I visit, so I finally am reporting one of these problems.

When using WordPress.com with Zemanta enable, the Media Gallery/Recommended Images show up, but the hover feature that allow you to preview images does not work and clicking images to add them to your post does not work when HTTPS Everywhere is installed.

Here is an example of what Zemanta looks like on WordPress.com:


I am using HTTPS Everywhere in the latest Firefox and have had this problem in other versions of Firefox, and with various versions of HTTPS Everywhere.

I think this problem happens even if HTTPS Everywhere is disabled, but once uninstalled the problem stops, but I could be wrong.

Thank you, -John Jr :)

#7454 Active rules list doesn't indicate effects of securecookie if no URL rewrite took place HTTPS Everywhere/EFF-HTTPS Everywhere defect Nov 12, 2012

We just had a bug reported about a securecookie rule that applied to all of MIT (including pages that don't support HTTPS at all!) and was breaking logins.

However, the ruleset in question didn't appear in the active rules menu, because no rewrite rule was triggered on the page in question -- only a securecookie. This made the problem take slightly longer to debug and made it harder for affected users to work around. The existing logic for deciding which rules are "active" on the current pages seems to be triggered solely by rewrite rules.

Since securecookie rules affect page rendering and can even break it, rulesets containing them should also show up in the active rules menu when they were applied to a resource on the current page.

phoul (1 match)

Ticket Summary Component Milestone Type Created
#10966 Define a process on how new support assistants can be accepted in the team Community/Tor Support task Feb 20, 2014

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

rl1987 (3 matches)

Ticket Summary Component Milestone Type Created
#27143 Look for parts of code that relies on non-trunnel code for binary wire format handling Core Tor/Tor Tor: unspecified task Aug 14, 2018

Open a new ticket for each, so that it could be reworked one at a time.

We really should do this for Tor cell handling.

#27324 Rework AUTHENTICATE cell parsing and remaining generation with trunnel Core Tor/Tor Tor: unspecified enhancement Aug 26, 2018

In channetls.c we have channel_tls_process_authenticate_cell() that uses memcpy et. al. to parse AUTHENTICATE cell. This should be done with machine generated code from trunnel. We also should rely more on trunnel when generating AUTHENTICATE cells. Generation of Type 1 authentication payload is mostly implemented with trunnel already.

#28982 Refactor GETINFO dir/ so that new tor/ URLs automatically become GETINFOs Core Tor/Tor Tor: unspecified enhancement Jan 4, 2019

The control-spec lists some tor/ URLs as GETINFO dir/ keys: https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n807 (The reference to section 4.4 in dir-spec is also wrong, it should be Appendix B.)

But some newer URLs are missing, for example, consensus-microdesc: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n3862

We could refactor the GETINFO dir/ code to redirect all requests to the tor/ URL.

rransom (1 match)

Ticket Summary Component Milestone Type Created
#3459 Expose information about dir conns to controllers Core Tor/Tor Tor: unspecified enhancement Jun 24, 2011

Currently, we do not expose any information about non-tunneled directory connections to controllers. Should we?

saint (1 match)

Ticket Summary Component Milestone Type Created
#9360 increase font size in trac Internal Services/Service - trac defect Jul 31, 2013

Whenever I visit trac I find the fonts hard to read. The file https://trac.torproject.org/tor.css has the following lines inside:

body, th, td {
 font: normal 13px Verdana,Arial,'Bitstream Vera Sans',Helvetica,sans-serif;

So the font-size is set to 13px. I would propose to change it to 1.0em. This sets the font-size to the value the users has set for normal texts. So it should reflect the users choice.

Maybe can also change the font sizes of the headings. The current setting in tor.css is:

h1 { font-size: 19px; margin: .15em 1em 0.5em 0 }
h2 { font-size: 16px }
h3 { font-size: 14px }

In relative terms the settings should be like:

h1 { font-size: 1.5em; margin: .15em 1em 0.5em 0 }
h2 { font-size: 1.2em }
h3 { font-size: 1.1em }

sysrqb (1 match)

Ticket Summary Component Milestone Type Created
#27539 Create plan for releasing on F-Droid Applications/Tor Browser enhancement Sep 7, 2018

Can we create a build script and add the app now? What are the blockers? How difficult will this become after we begin building using tor-browser-build?

The Guardian Project have their own F-Droid repository, do we need our own? If we do, can ours be included in the f-droid app by default (but disabled), too?

wulder (1 match)

Ticket Summary Component Milestone Type Created
#21087 Separate truncated descriptor(s) from next complete descriptor Metrics/CollecTor defect Dec 26, 2016

Hi Karsten, a user reached out to me because Stem's validator warns about a CollecTor tarball. In particular it's surprised by @source annotations in the server descriptors.

Here's the *server-descriptors-2016-09/2/2/228e3ecf654e1b7b4f01a0027e599e7ba14b216c* descriptor from the tarball for an example...

@type server-descriptor 1.0 
router sauronkingofmortor 9001 0 9030
-----BEGIN ED25519 CERT-----
-----END ED25519 CERT-----
master-key-ed25519 7PV1B+84IhXfpoz1sBS1Kb5mvKr3bQoXIKeCulgw51M
platform Tor on Linux
protocols Link 1 2 Circuit 1
published 2016-09-15 09:23:41
fingerprint 2D8A FA91 2E2B 8623 BB2C DACD 1933 2209 D524 D1A3
uptime 860586
bandwidth 12288000 12288000 7792456
extra-info-digest 2017D54A2C28B100CE173351E0799E15153B703B                                          D2vKVNwaxArp6bf11NWPRNoYGQ0lBgIwziSXNkL9TCw
ntor-onion-key-crosscert 0
-----BEGIN ED25519 CERT-----
-----END ED25519 CERT-----
contact luciole <luciolesauronkingofmortor@yopmail.com>
ntor-onion-key lhvzaL7Ze85GFMWMQscMgIt9IOx6srmOiXqD85kOekI=
reject *:@uploaded-at 2016-09-15 09:24:06
@source ""
router torbeornottorbe 9001 0 0
platform Tor on Linux
protocols Link 1 2 Circuit 1
published 2016-09-15 09:24:06
fingerprint C6EE 9826 7F82 962C C2FC 1E9E 2AE5 F317 B2D2 D6F0
uptime 762082
bandwidth 1024000 2048000 106721
extra-info-digest 08D7C6A9FF860F6A5D12FB43BD2051ACC06BCE52
family $5A8B78AB293475D6D55F1CBFA5D2A1CEEB09545B $EAE900D1DB28D56F4535C06F1BAEB92B9E3BFEE6
contact A36F 07B9 285A C895 3E42 69F3 0CCC 0AF6 2FEC DB6E Random Person <nae AT blueyonder dot co   dot uk>
ntor-onion-key 90dT83YmTzH/uojnATf+KOtwJssKGURO/qdu3SR0XgE=
reject *:*

Seems this is two descriptors concatenated together with a @source in the middle? Any hints on where these come from?


yawning (1 match)

Ticket Summary Component Milestone Type Created
#15593 Bring sanity to the tor side of the PT shutdown process. Circumvention/Pluggable transport Tor: unspecified enhancement Apr 5, 2015

This is the final phase of my great PT shutdown process cleanup as a follow up to #15545.

Now that there's a portable mechanism to signal termination to PTs (close the stdin), we should change the PT shutdown process to allow graceful termination to look like this:

  1. Close stdin (and on U*IX, send a SIGTERM, PT behavior here is equivalent).
  2. Wait for a grace period (~1 sec?)
  3. If the child still is not dead, send a SIGKILL/TerminateProcess(). (Failsafe)

This fixes #9330 in that, PTs that wish to trap a graceful shutdown on Windows have a way to do so, despite the final stage of the process killing the PT in the most violent way possible as a failsafe (realistically, PTs should exit shortly after step 1).

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