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

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.

-quit

​TGen 1.0.0 comes with a "change in the format of some of the configuration options that breaks compatibility with the previous version 0.0.1."

I tried to update OnionPerf to write out TGen files that TGen 1.0.0 understands. Here's the diff:

diff --git a/onionperf/model.py b/onionperf/model.py
index 3c057c5..90c824e 100644
--- a/onionperf/model.py
+++ b/onionperf/model.py
@@ -77,9 +77,9 @@ class TorperfModel(GeneratableTGenModel):
         if self.socksproxy is not None:
             g.node["start"]["socksproxy"] = self.socksproxy
         g.add_node("pause", time="5 minutes")
-        g.add_node("transfer50k", type="get", protocol="tcp", size="50 KiB", timeout="295 seconds", stallout="300 seconds")
-        g.add_node("transfer1m", type="get", protocol="tcp", size="1 MiB", timeout="1795 seconds", stallout="1800 seconds")
-        g.add_node("transfer5m", type="get", protocol="tcp", size="5 MiB", timeout="3595 seconds", stallout="3600 seconds")
+        g.add_node("stream50k", recvsize="50 KiB", timeout="295 seconds", stallout="300 seconds")
+        g.add_node("stream1m", recvsize="1 MiB", timeout="1795 seconds", stallout="1800 seconds")
+        g.add_node("stream5m", recvsize="5 MiB", timeout="3595 seconds", stallout="3600 seconds")
 
         g.add_edge("start", "pause")
 
@@ -88,9 +88,9 @@ class TorperfModel(GeneratableTGenModel):
         g.add_edge("pause", "pause")
 
         # these are chosen with weighted probability, change edge 'weight' attributes to adjust probability
-        g.add_edge("pause", "transfer50k", weight="12.0")
-        g.add_edge("pause", "transfer1m", weight="2.0")
-        g.add_edge("pause", "transfer5m", weight="1.0")
+        g.add_edge("pause", "stream50k", weight="12.0")
+        g.add_edge("pause", "stream1m", weight="2.0")
+        g.add_edge("pause", "stream5m", weight="1.0")
 
         return g
 
@@ -109,10 +109,10 @@ class OneshotModel(GeneratableTGenModel):
         g.add_node("start", serverport=self.tgen_port, peers=server_str, loglevel="info", heartbeat="1 minute")
         if self.socksproxy is not None:
             g.node["start"]["socksproxy"] = self.socksproxy
-        g.add_node("transfer5m", type="get", protocol="tcp", size="5 MiB", timeout="15 seconds", stallout="10 seconds")
+        g.add_node("stream5m", recvsize="5 MiB", timeout="15 seconds", stallout="10 seconds")
 
-        g.add_edge("start", "transfer5m")
-        g.add_edge("transfer5m", "start")
+        g.add_edge("start", "stream5m")
+        g.add_edge("stream5m", "start")
 
         return g
 

I'll let an OnionPerf instance run for a day to see at the output, also to see if we need to make adjustments to OnionPerf's analyze mode due to slightly changed log messages.

Until then, do these changes above look reasonable? Or did I miss something? Thanks!

We currently use a custom-made YAML database for assigning roles to servers and other metadata. I started using Hiera for some hosts and it seems to be working well.

Hiera is officially supported in Puppet and shipped by default in Puppet 5 and later. It's the standard way of specifying metadata and class parameters for hosts. I suspect it covers most of our needs in terms of metadata and should cover most if not all of what we're currently doing with the YAML stuff in Puppet.

We should therefore switch to using Hiera instead of our homegrown solution.

This involves converting:

• if has_role('foo') { include foo } into classes: [ 'foo' ] in hiera (DONE!)
• hardcoded macros in the ferm module's me.conf.erb into exported resources (DONE, except for HOST_TPO)
• templates looping over allnodeinfo into exported resources
• the $roles array into Hiera (DONE!)
• the $localinfo into Hiera (assuming all the data is there) (DONE!)
• the $nodeinfo and $allnodeinfo arrays into Hiera (assuming we can switch from LDAP for host inventory)
• basically any other stuff of the kind, including those files:

  ./modules/torproject_org/misc/hoster.yaml
  ./modules/torproject_org/misc/local.yaml <- DONE!
  ./modules/ipsec/misc/config.yaml
  ./modules/roles/misc/static-components.yaml
  ./modules/roles/files/spec/spec-redirects.yaml
  

Ideally, all YAML data should end up in the hiera/ directory somehow. This is the first step in making our repository public (#29387) but also using Hiera as a more elaborate inventory system (#30273).

The idea of switching from LDAP to Hiera for host inventory will definitely need to be evaluated more thoroughly before going ahead with that part of the conversion, but YAML stuff in Puppet should definitely be converted.

The general goal of this is both to allow for a better inventory system but also make it easier for people to get onboarded with Puppet. By using community standards like Hiera, we make it easier for new people to get familiar with the puppet infrastructures and do things meaningfully.

Update: get_roles(), has_role(), yamlinfo() and local.yaml are *all* gone! The main chunks remaining are now nodeinfo(), allnodeinfo(), $nodeinfo and hoster.yaml. A plan has been laid out for that replacement below. Obviously, the ipsec, static components and redirects YAML files could use a transition into Hiera as well, but those are lower priority.

The entire language list is not accessible on mobile.

​https://twitter.com/glotzbach/status/1111165746623799296

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

When an OR connection ​acting as a server changes to state OR_CONN_STATE_OR_HANDSHAKING_V3, it does so by setting conn->base_.state directly and not using connection_or_change_state(), so afaict this state change is never passed to pubsub or to the channel object.

On the other hand, when changing to that same state ​when acting as a client, it does use connection_or_change_state() as expected.

This seems to me to be a bug, but maybe there was a good reason for doing it this way. Also it seems no one has complained about it since the code was added, so having it changed doesn't seem to be important. But documenting here anyways since someone may want to take a look at it at some point.

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

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

Assumptions made about what the TPA machine would look like turned out to be wrong, and those assumptions are included in the exit-scanner-sys role. In order to get the new system running as quickly as possible, the -sys role was left broken. This should be fixed before moving on as otherwise we are unable to easily create test/dev hosts easily in the future.

Mirroring the format of ​https://help.torproject.org/metrics/ops/onionoo-ops/ unless anarcat has requests for things to include here.

The sections on deployment and disaster recovery can already be written.

The sections on monitoring will have to wait for monitoring to exist.

The specifications for measuring this are as follows:

• OP should measure one guard or set of guards at a time. It could use NumEntryGuards in the torrc file to support more than 1 guard
• A new guard/set of guards must be chosen after a day of measurement
• All CBT data must be erased when choosing a new set of guards, after day of measurements (at UTC midnight). This could mean erasing or replacing the state file for CBT.

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

How can I help you do this?

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

Thanks!

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.

I get these on moria1 pretty often. It's been ongoing for a long time I think -- since whenever we attempted to fix that last bug with ri / ei synchronization.

Here's a potentially useful info-level log:

May 13 18:50:37.600 [info] connection_dir_client_reached_eof(): Received extra server info (size 5307) from server '131.188.40.189:80'
May 13 18:50:37.600 [info] router_load_extrainfo_from_string(): 3 elements to add
May 13 18:50:37.600 [warn] extrainfo_insert(): Bug: No entry found in extrainfo map. [1 similar message(s) suppressed in last 1800 seconds] (on Tor 0.2.7.1-alpha-dev 95a9920461dd3322)
May 13 18:50:37.623 [info] connection_dir_client_reached_eof(): Received 0/9 extra-info documents requested from 131.188.40.189:80

I don't know if this last line is related or not.

Actually, I get one of the Bug: messages every hour on moria1, a little bit after the 50 minute mark. Sounds like I'm hearing votes from other authorities, and they make me think of an extrainfo I don't have, so I try to get it, and then bug.

None of the instructions mention updating Cargo.lock, which is required. The script updateRustDependencies.sh doesn't update that file, either.

Guardian Project has maintained a wrapper build system for building tor for Android since the beginning. Since many more people are now building tor for Android, I'm working to upstream as much of that as possible. The goal is that the requirements for building on Android can be fulfilled by tor's own configure.ac.

The first change is to remove the unnecessary ./configure --enable-android option.

• Android NDK compilers define __ANDROID__ so that can be used for Android-only code without adding anything in configure.ac, (following the standard pattern like __APPLE__, __linux__, __FreeBSD__, _WIN32, etc.
• android/log.h and __android_log_write() are always present if building for Android, so this would be like testing for printf() on UNIX.

Then move the Android config into configure.ac reusing the ./configure --enable-android flag. A working sketch for that is here: https://trac.torproject.org/projects/tor/ticket/28766#comment:6

The last piece is including a Java JNI wrapper in tor, enabled by ./configure --enable-jni. This lets us run tor as an Android Service, which is the Android equivalent of a UNIX daemon (UNIX daemons are not really supported on Android and using them is quite problematic). This JNI API should be generic enough to be useable in Java in general, though that's not a priority for us.

I'll add patches for merging once we agree on these details. I have this all working already on my machine.

For example if you visit ​https://src-ref.docs.torproject.org/tor/dataflow.html, the "structure hierarchy for connection types" image is missing (the img tag has a 404). There are possibly other missing images as well, but I can't find the markdown files to check (there were the original versions, then they were moved to the tor git repo and edited iirc, but now they're gone).

There's also another image missing on the same page, but has no <img> tag (compare the top of the ​https://people.torproject.org/~nickm/tor-auto/internal/02-dataflow.html and ​https://src-ref.docs.torproject.org/tor/dataflow.html pages). But it may have been removed on purpose.

The "outbuf_flushlen" field in connection_t seems to not actually do anything that's distinct from buf_datalen(conn->outbuf)... except possibly, to get out of sync with it under rare conditions? (eg #32472).

Flushlen once existed to implement rate limiting: it was introduced in 117cbeeaaf30cdb before we even had round robining. Later there was some logic involved with f5ebf4c712d693c to try to flush full TLS records. And controller connections used ab838bddb89f to force early flushing there... but right now, we don't flush according to the same logic that we used to flush, and I think outbuf_flushlen is now obsolete.

I think there's a case to be made for removing this field in 0.4.3, but I'd like to be cautious.

Adding arma to cc in case he can remember what outbuf_flushlen is for.

Follow up to #31841.

We should set a time limit for each individual unit test, and fail it if it takes too long.

We might also want to timelimit checks as well.

We can set a time limit on entire shell commands using the "timelimit" command. But we will need to write test code to do it per-unit test.

The following inline header functions depend on some members of or_options_t, which is a dependency we don't need:

• options_validate_dirauth_mode()
• options_validate_server_transport()
• options_validate_relay_mode()

And the dependency only exists when the relay or dirauth modules are disabled.

Instead, we could put these functions in stub C files, which are only compiled when relay/dirauth mode is disabled.

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:

​http://msdn.microsoft.com/en-ca/subscriptions/downloads/default.aspx

Hello,

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:

​http://en.support.files.wordpress.com/2010/08/zemanta_before.png

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

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.

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.

Brotli seems to outperform zstd in compression, and claims performance comparable to deflate. We should investigate using it for directory requests.

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

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?

I am currently running nightly builds at ​http://f4amtbsowhix7rrf.onion/. I think someone else from Tor Browser team should setup a new nightly build machine.

To do that the ansible scripts in directory tools/ansible can be used: ​https://gitweb.torproject.org/builders/tor-browser-build.git/tree/tools/ansible

You will need to:

• if the host does not have a public IP address, you can install tor and setup an onion service on the http port (this part is not done in ansible)
• add a new host in the inventory file
• configure this host in your ~/.ssh/config file if necessary (if the hostname added to the inventory file is not a real hostname), and make sure that you can connect to the host with ssh root@$hostname
• copy the file boklm-tbb-nightly-build.yml to an other name
• copy the directory group_vars/boklm-tbb-nightly to another group name, and update the configuration in tbb-nightly-build.yml
• configure email on the host. This can be done in ansible with the file dma.yml. The email password (if needed) is stored encrypted in dma-auth.yml in the directory vaulted_vars (see ​https://docs.ansible.com/ansible/latest/cli/ansible-vault.html), and the password to decrypt the vault is passed with the --vault-password-file argument in the Makefile (maybe it's also possible to store dma-auth.yml outside tor-browser-build.git without using vault). Alternatively you can configure email on the host without using ansible, by removing the mta role from the *-tbb-nightly-build.yml file.
• in the Makefile add a new *-tbb-nightly-build rule
• run "make *-tbb-nightly-build"
• if you enabled nightly_build_sign_build in tbb-nightly-build.yml, connect to the host and become the tbb-nightly user and generate a new gpg key (the key is not created automatically by ansible)

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