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

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

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

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

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

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

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

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

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

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

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

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.

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

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

SETCONF DisableNetwork=0

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

SETCONF DisableNetwork=1

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

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.

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

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.

When a relay is configured as a bridge, a user reports this can lead to direct connections being made to the relay/bridge, even when a pluggable transport is configured. We have been unable to confirm this.

​​https://lists.torproject.org/pipermail/tor-dev/2016-November/011618.html

We should check directory_initiate_command_rend (the linked connection case), and connection_or_connect to make sure it is not possible for a connection to go directly to a configured bridge when a transport is set up.

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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.

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:

0. 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)
1. The service always puts IPv4 and IPv6 in its descriptor link specifiers (if they are available in directory documents)
2. 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
3. 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).

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

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.

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

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

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

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

We got a report on HackerOne by sumitthehacker:

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

the bug exists at :

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

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

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.

The Networkinformation API is enabled by default in the mobile version of Firefox. This is governed by a preference, dom.netinfo.enabled. This API (​https://developer.mozilla.org/en-US/docs/Web/API/NetworkInformation) provides a variety of information, e.g. the connection type a device is using to communicate with the network or the maximum downlink speed. We should avoid fingerprinting risks associated with this API. For a discussion among Mozilla engineers see: ​https://groups.google.com/forum/#!topic/mozilla.dev.platform/lCZmhCDGHPY

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

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)

Discovered OOM problem for large descriptor files in #20335, see comment 12 there for how to reproduce.

see Analysis Part 2 for background information.

• verify current stats
• avoid ambiguous log statements
• maybe, separate stats for download and import
• ...

For all issues fixed during system test of the sync-release (#18910):

• verify that there are tests checking the fixed functionality (where it makes sense)
• add tests to catch similar issues with junit test instead of system testing (where feasible)

At least for comments 82, 95, 98 in #18910.

It would be really useful to know how long it still takes to read a bunch of descriptors, as this can range from minutes to hours or even days. In some cases this information would help to decide whether to continue or abort and try something different.

How about we start reading descriptors by walking files in the given directories, summing up their bytes, and using that total sum to periodically write a log message with progress and estimated time left?

Once per minute on debug level would be sufficient. And it's okay if it's not super precise and gets confused by compression or other factors. Just a rough number that gets more precise over time.

This is the parent issue for defining

• contributor's guidelines
• coding style guidelines
• release process description
• (more?)

for java projects.

This issue serves for discussing "meta" questions like finding a central location and defining the structure.

The central place could be another git repository metrics-team-meta (or some better title), which could hold all documents like coding style guides for the various languages used by the Metrics-Team, guides and documents covering more than one Metrics-Team project, and other docs like the ​road-map.)

There are currently three different version 3 network status document types, identified by the following @type annotations:

1. @type network-status-vote-3 1.0: these are votes exchanged by directory authorities;
2. @type network-status-consensus-3 1.0: these are (unflavored) consensuses based on votes and published by directory authorities;
3. @type network-status-microdesc-consensus-3 1.0: these are the same consensuses as before but using a specific flavor, in this case one that references microdescriptors rather than server descriptors.

So, while we're using a separate interface for the first type (RelayNetworkStatusVote), we're using the same interface (RelayNetworkStatusConsensus) for the second and third type. This only works, because the only differences between unflavored and microdesc-flavored consensuses can be found in the network status entries, and we're using the generic NetworkStatusEntry for those. But as soon as there will be new keywords in either unflavored or microdesc-flavored consensuses, we'll have to add support for them to RelayNetworkStatusConsensus, even though the other flavor doesn't support them.

We might consider adding another interface RelayNetworkStatusMicrodescConsensus for microdesc-flavored consensus, which would probably just extend RelayNetworkStatusConsensus for now (or copy over everything from it? uhhh). But if microdesc-flavored consensuses ever derive from unflavored consensus in header or footer, we'll be able to model those changes correctly.

Related to this suggestion, we might consider making NetworkStatusEntry less generic by using a separate Entry interface like we just did for ExitList. Following that model, RelayNetworkStatusVote.Entry would keep its getMicrodescriptorDigests() method, RelayNetworkStatusConsensus.Entry would drop that method, and RelayNetworkStatusMicrodescConsensus.Entry would get a getMicrodescriptorDigest() (singular) method.

I don't think these changes are super urgent, but I wanted to write them down before resolving #17000 where they first came up.

works: ​https://onionoo.torproject.org/details?contact=Neel%20Chauhan

does not work: ​https://atlas.torproject.org/#search/contact:Neel%20Chauhan

Currently you can search for things like give me all exits in FI running 0.3.1

​https://atlas.torproject.org/#search/country:fi%20flag:exit%20version:0.3.1

you can not: give me all relays by operator with contact foo that do not have the guard flag

split from https://trac.torproject.org/projects/tor/ticket/23829?replyto=3#comment:3

The flag parameter currently does not accept a comma-separated list of flags. We could extend it towards doing so.

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:

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

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

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.

PowerTOP shows Tor waking up 10 times per second even when it’s doing nothing. This is bad for power usage on a laptop because it prevents the CPU from entering its deepest sleep states. It looks like the reason is the default TokenBucketRefillInterval of 100 msec (#3630). Perhaps this logic can be refactored so that refill_timer is only activated when there are buckets to be refilled.

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

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

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

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

But now they're in their own git repository.

I think maybe they technically have no copyright license now?

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

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 !

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

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

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

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

$ uname -r
3.18.9-hardened

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

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

SocksPort 9050
SocksPort 9056 IsolateDestAddr IsolateDestPort
SocksPort 9055

ControlPort 9015
CookieAuthentication 1

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

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

Split from #18319

At some point, we should require relays that once had an ed25519 key associated with their RSA key to always have that key, rather than allowing them to drop back to a version that didn't support ed25519.

(This means they need to use a new RSA key to downgrade to an older version of tor without ed25519, which is consistent with the pinning in #18319.)

This means either: 1a. waiting until 0.2.5 is no longer recommended, or 1b. look at historical metrics data to see how often relays run a recent version for a while, then drop back to an older one. If the answer is "almost never" then we can just turn it on now.

To implement this change, replace #undef DISABLE_DISABLING_ED25519 with #define DISABLE_DISABLING_ED25519.

In the past, I could do

src/or/tor entrynodes moria1

and voila, I would begin using my Tor with moria1 as my entry node.

In the new world order, post prop#271 I assume, I instead get this complaint:

May 08 20:27:42.394 [warn] Your configuration excludes 100% of all possible guards. That's likely to make you stand out from the rest of the world.
May 08 20:27:42.394 [notice] Starting with guard context "restricted"
May 08 20:27:42.405 [notice] Bootstrapped 80%: Connecting to the Tor network
May 08 20:27:43.425 [warn] Failed to find node for hop 0 of our path. Discarding this circuit.

and then I never bootstrap.

This is clearly a regression. Is it intentional, and I should go read guard-spec.txt for why, or is it accidental?

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?

There are some open discussion issues in prop280. We should wrap them up so we can get an implementation merged.

These are a set of patches written by Access Labs. They claim that these patches reduce memory usage on small low memory devices.

The patches are in several different areas:

• using anonymous mmap() for storing large chunks of data (instead of tempfiles)
• persisting the keys into /etc/tor/keys, rather than putting them in /var (tmpfs on OpenWRT)
• using fixed values for should_rebuild_md_cache() && router_should_rebuild_store()
• reducing the age of microdesc (changing the compile time defines)
• using gzipped files for storing cache

I am including the files here as one ticket item rather than 5, but it might make sense to break them up into separate issues.

The source for these changes is the TorWRT package from Access Labs: ​https://accesslabs.org/wiki/TorWRT

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]