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

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

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.

Cheers,

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.

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

The entire language list is not accessible on mobile.

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

There is a glitch on torproject.org making "Browse" only partly visible on my mobile phone.

If DisableNetwork is set to 1 via SETCONF during bootstrapping, Tor sometimes generates spurious errors such as "Network is unreachable". Kathy and I saw this while testing a fix for #11879. We realize this may be difficult to fix due to the internal architecture / concurrency inside Tor.

See #15713 for steps to reproduce (but note that an error does not occur every time). In the log that is attached to #15713 you can see an example:

Apr 17 10:28:10.000 [warn] Problem bootstrapping. Stuck at 25%: Loading networkstatus consensus. (Network is unreachable; NOROUTE; count 1; recommendation warn; host 847B1F850344D7876491A54892F904934E4EB85D at 86.59.21.38:443)

(the error happens right away if it happens at all – no delay).

This problem may cause some Tor Browser users to be a little confused; all they need to do is click "Open Settings" while Tor Browser was starting up and they will sometimes see an error alert.

Nick and I both thought that at least in the past, Tor clients would stop using a relay as their guard, if it loses the Guard flag.

But it looks like the code doesn't do that -- once a relay is your guard, you'll use it in the guard position regardless of whether it has the Guard flag at this moment or not.

This is actually a tricky design decision. In favor of avoiding guards that don't have the guard flag:

• If they get really slow, we can instruct clients to abandon them.
• If a relay gets the guard flag for only a short period of time, it will have only a small number of (dedicated) users using it for the next months.

In favor of using non-Guard guards anyway:

• An attacker can't push you away from your guard by hurting its performance in the eyes of the directory authorities.
• You won't rotate guards as many times.

That "can't push you away" one looks big. What other aspects should we be considering here?

with tor-0.2.6.9 and stem-1.4.1 I run (rarely) into this :

cat ioerror.stderr.old
Exception in thread Event Notifier:
Traceback (most recent call last):
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 1758, in get_network_status
    desc_content = self.get_info(query, get_bytes = True)
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 414, in wrapped
    raise exc
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 409, in wrapped
    return func(self, *args, **kwargs)
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 1113, in get_info
    raise exc
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 1066, in get_info
    stem.response.convert('GETINFO', response)
  File "/usr/lib64/python3.3/site-packages/stem/response/__init__.py", line 135, in convert
    message._parse_message(**kwargs)
  File "/usr/lib64/python3.3/site-packages/stem/response/getinfo.py", line 38, in _parse_message
    raise stem.InvalidArguments('552', 'GETINFO request contained unrecognized keywords: %s\n' % ', '.join(unrecognized_keywords), unrecognized_keywords)
stem.InvalidArguments: GETINFO request contained unrecognized keywords: ns/id/2BCDF9F0BCEFC2A44F7850F92362BA85AA226E1F


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib64/python3.3/threading.py", line 901, in _bootstrap_inner
    self.run()
  File "/usr/lib64/python3.3/threading.py", line 858, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 882, in _event_loop
    self._handle_event(event_message)
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 3480, in _handle_event
    listener(event_message)
  File "./err.py", line 47, in orconn_event
    relay = controller.get_network_status(fingerprint)
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 414, in wrapped
    raise exc
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 409, in wrapped
    return func(self, *args, **kwargs)
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 1761, in get_network_status
    raise stem.DescriptorUnavailable("Tor was unable to provide the descriptor for '%s'" % relay)
stem.DescriptorUnavailable: Tor was unable to provide the descriptor for '2BCDF9F0BCEFC2A44F7850F92362BA85AA226E1F'

while running this script :

$ cat err.py
#!/usr/bin/python3 -u

#   Toralf Foerster
#   Hamburg
#   Germany

# collect data wrt to https://trac.torproject.org/projects/tor/ticket/13603
#

import time
import functools

from stem import ORStatus, ORClosureReason
from stem.control import EventType, Controller


def main():
  class Cnt(object):
    def __init__(self, done=0, closed=0, ioerror=0):
      self.done = done
      self.closed = closed
      self.ioerror = ioerror

  c = Cnt()

  with Controller.from_port(port=9051) as controller:
    controller.authenticate()

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

    while True:
      time.sleep(1)

def orconn_event(controller, c, event):
  if event.status == ORStatus.CLOSED:
    c.closed += 1

    if event.reason == ORClosureReason.DONE:
      c.done += 1

    if event.reason == ORClosureReason.IOERROR:
      c.ioerror += 1

      fingerprint = event.endpoint_fingerprint
      print (" %i %i %i %i %s %40s" % (c.closed, c.done, c.ioerror, event.arrived_at, time.ctime(event.arrived_at), fingerprint), end='')
      relay = controller.get_network_status(fingerprint)
      if relay:
        print (" %15s %5i %s %s" % (relay.address, relay.or_port, controller.get_info("ip-to-country/%s" % relay.address, 'unknown'), relay.nickname), end='')
      print ('', flush=True)

if __name__ == '__main__':
  main()

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

We'll be working during sponsor31 to make sure that we are moving towards a nice modular architecture. We should document what we're actually trying to achieve, and what our target architecture is, so that we can tell people "do it like X, not necessarily like Tor does it now."

The official deliverable here is "Architectural documentation for how Tor modules work with one another, covering both the actuality and the refactored architecture". The "actuality" is under #29214.

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.

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

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

Installing an obfs4 bridge on Debian currently requires installing tor, obfs4proxy, and then figuring out how to configure it. We could create a meta package, say tor-bridge, that simplifies this process. This package would:

• Ship with a script that automatically determines a free and random OR and obfs4 port.
• Help us retire a transport by replacing, say, obfs4 with obfs5.
• Ship with a tool that helps operators get their bridge line.
• Write its torrc to a different file than the tor package, to be compliant with Debian policy.
• After installation, ask the operator about their nickname, contact info, and if they want a vanilla or obfs4 bridge.
• Maybe ship with ​nyx so operators have a sense of how their bridge is doing.

I hear that infinity0 already thought about this problem a lot in the context of tor-bridge-helper.

atagar suggested to extend file objects in CollecTor's index.json to include descriptor types, publication times, and file digests.

As of now, file objects in the index.json file have the following fields:

• "path": Relative path of the file.
• "size": Size of the file in bytes.
• "last_modified": Timestamp when the file was last modified using pattern "YYYY-MM-DD HH:MM" in the UTC timezone.

The new fields could be defined as follows, though this is very much subject to discussion on this ticket:

• "types": List of descriptor types as found in @type annotations of contained descriptors (optional).
• "first_published": Earliest published timestamp (or similar) of contained descriptors (optional).
• "last_published": Latest published timestamp (or similar) of contained descriptors (optional).
• "sha256": SHA-256 digest of the file, encoded as base64 (optional).

All these new fields seem reasonable things to add, and I don't see why we wouldn't want to add them. The index will get bigger, but that sounds acceptable. The coding effort is non-zero, which is something we'll have to admit. But all in all, I don't see a blocker for doing this.

Implementation note: All these new fields have in common that they're not just file attributes that we can easily obtain from Java's File class. We'll have to open and read files in order to obtain these fields, and that's very time-consuming. I could see how we do this in a background thread (or thread pool) started by CollecTor's CreateIndexJson.java with a state file of some sort to avoid reprocessing files that haven't changed. And while this thread (pool) hasn't completed processing a file, the index would simply omit these new fields (not files!), which is why fields are defined as optional above.

What else did I miss? atagar, please fill in any thoughts that I left out.

Once we agree on the spec here, this could be a fine little project for a volunteer.

Setting my phone to disable data access and/or enable airplane mode seems to cause the transproxy iptables rules created by OrBot to get silently flushed. After re-enabling, all apps access everything without tor, until I go into the orbot config screen to cause it to reapply them.

OrBot should listen for these network disable/loss/disconnect events if possible, and reinstate the iptables rules after this happens.

Someone should also test if switching from cell data to+from wifi also triggers this iptables reset. I have not tested that yet.

This is about the bug discussed with 'n8fr8' on #guardianproject at freenode. So, the relay functionality you said was broken and needs to be fixed for 'orbot' on smartphones. I checked with the orbot version '0.2.3.10-alpha-orbot-1.0.7-FINAL' and you have checked with the 'dev branch of the code' as you said (i suppose that means you have checked with latest version of code by compiling and running the latest updated version from git; i will do it too and let you know again). But none seemed to work. In fact, you said you were getting a more significant crash, when you enabled relaying on smartphone for dev branch of code. You also thought if the problem is: whether the Relay conflict is with transproxying/root or with Tor client connection in general. But, i'm not sure if it later seemed not to be the problem. Then, you told me to change the torrc file on my android phone, as you said that orbot is not setting the relay values properly which might be the reason for orbot not working as a relay on smartphone. So, I will do that and let you know about it. I will also keep checking '​https://guardianproject.info/builds/Orbot/' to see if any new dev/debug release is posted. Thankyou so very much for all your help, Mr.Nathan.

There's some kind of problem with permissions in Orbot. I'm not sure if this happens only to me, but when I try to start Tor, it cannot access cache/control_auth_cookie. I can chmod it every time, but it is a bit annoying.

In #30687, we created a single-counter token bucket token_bucket_ctr.

token_bucket_rw_adjust() calls rate_per_sec_to_rate_per_step(rate), but token_bucket_ctr_adjust() does not.

I suggest we fix this bug by moving rate_per_sec_to_rate_per_step(rate) into token_bucket_cfg_init(). And we should add some documentation that explains the difference between rate and burst.

Gaba, this is sponsor 31-must, because it is a bug fix on sponsor 31 code that has already been merged.

The official deliverable here is "Architectural documentation for how Tor modules work with one another, covering both the actuality and the refactored architecture". The "refactored architecture" is under #29215.

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

With #29226 we want to automate our C formatting. But to do so, we will need to come to agreement about our style, and for that, we should start the discussion well in advance.

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.

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.

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 }

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 137.74.116.214 9001 0 9030
identity-ed25519
-----BEGIN ED25519 CERT-----
AQQABkAYAXe8xhBhoRVgI2ZswouGG50gLzYsWudXIp96bCAloSStAQAgBADs9XUH
7zgiFd+mjPWwFLUpvma8qvdtChcgp4K6WDDnU6ub3BDNZ7nGTDvYPHVmq4URzobG
uAsjOIPlf1vkU3YJdpBe0KGHy5JeuJ10TDQwlK1F761pSApIdH1ocIg4oAE=
-----END ED25519 CERT-----
master-key-ed25519 7PV1B+84IhXfpoz1sBS1Kb5mvKr3bQoXIKeCulgw51M
platform Tor 0.2.8.7 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
onion-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAMNJzNJiDwd8y7ge4aXjkUCBKDncNhC91i5SQkxTHX4ZR/05+/liwR5O
TPgoIG0FDQSEUMYDPY92XsRmgPXkpHBSga0ojrhwnYutXAPMRuT4Dm24kpJctdbG
kwW6aovjNcoeJE3iB5ahUCv/TDnuiijioRSfjTPQsW68gHo1rOxJAgMBAAE=
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAJhvAVj6wurlz3khW1Z/2x8sAnyr9lBdiHMp8UEAhYw+7ct1fdmuZXbA
I9aZbb7GEgR9UBW67qYd0aN1XHbDwb4OvAW+TOzcCjBmqiSLl5WACl0wIjuif7++
xNVcRw04kmmbBf7IyjmmuCc6ihjGeG02aREitZGBSkyZwt8SAz0fAgMBAAE=
-----END RSA PUBLIC KEY-----
onion-key-crosscert
-----BEGIN CROSSCERT-----
ct5RfDtMM5h5G6T6pFkRANCsJGcjwpPK+b47yWoQSdH7C0Y4yjWX5Z48l511fPK6
1v4IINEnuiCMkDp4HGpSW87aHatUaWP6MVo6pwQB2uqi8SpjPdlf6pJfSYNsvaZh
00P6ENAXzDnFFvcNla0WI7o6rIE2tuP3qd7bxazACUU=
-----END CROSSCERT-----
ntor-onion-key-crosscert 0
-----BEGIN ED25519 CERT-----
AQoABj/6Aez1dQfvOCIV36aM9bAUtSm+Zryq920KFyCngrpYMOdTANd0d0EMe6BU
CZrDB67jdOEX8P0T1MY1razuVMyvAjS1MPsM/F7uvCvgf1Su4NJFodWWPGLXWnHZ
RFSpVcHmmg8=
-----END ED25519 CERT-----
hidden-service-dir
contact luciole <luciolesauronkingofmortor@yopmail.com>
ntor-onion-key lhvzaL7Ze85GFMWMQscMgIt9IOx6srmOiXqD85kOekI=
reject *:@uploaded-at 2016-09-15 09:24:06
@source "82.1.128.70"
router torbeornottorbe 82.1.128.70 9001 0 0
platform Tor 0.2.4.27 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
onion-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAMb/ajivr7C1z7cnVSz4dPe+T0cOvB6ickNb8vjquDM8eZh7mLecSACT
H1D5DO97aJ0L1Bw5oOLzU77zx/2e/UUnHftiyZ8sNLmAE7smgEdUvhqNZSY+VSgN
E1Qyc6CdBpJWdSRp1+/AbYq0XWXMTrkb7YvRyR0iuYDn03s82DU/AgMBAAE=
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAK5CqRjTHbA+AHxLqSCWoEOpiVUNqpdiEUVTvdmu7aQgPcR2VI/fS/oc
tPmfC6L0l4eL0u1zZzbxJ8z5mop0M+0Wss8gWdpO7t7MNHu/GJ78gRRhb6Yz2JQf
jTZcVGyDsI8PJZoH+if3slVCUcq14zy85hb9sF9spaDhTEBbhx+rAgMBAAE=
-----END RSA PUBLIC KEY-----
family $5A8B78AB293475D6D55F1CBFA5D2A1CEEB09545B $EAE900D1DB28D56F4535C06F1BAEB92B9E3BFEE6
hidden-service-dir
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 *:*
router-signature
-----BEGIN SIGNATURE-----
PohhIu5DPg4iK+5AV3/sLMbpiwCItMbnaNVWrve9nKXyHM18eskYpL1sLyj7/3Nk
YKmFheD/alawStTr3rHkopdR8yj+1LZmWPlSHTy3x/U+uAzQl+66YcECEdw1xKMY
oaYngrHlZSrCEgwDKwIS4GJ/rOYjGUl0HCC9z0OaZ5M=
-----END SIGNATURE-----

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

Thanks!