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

This should be done via Apache config in the Ansible playbook

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
• hardcoded macros in the ferm module's me.conf.erb into exported resources
• templates looping over allnodeinfo into exported resources
• the $roles array into Hiera
• the $localinfo into Hiera (assuming all the data is there)
• 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
  ./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.

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.

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

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

​https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/log/?h=snowflake-windows&id=0f48dc9e1904fa0643576fc8dcf3db50a4d2f959

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

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

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

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

• ​https://chromium.googlesource.com/chromium/src/+/master/docs/win_cross.md says that we need to add target_os = ['win'] to our .gclient file before calling gclient sync to get some additional deps.

• ​https://chromium.googlesource.com/chromium/tools/depot_tools.git/+/master/win_toolchain/README.md says that Googlers have access to the necessary toolchain, but we don't.

• ​https://chromium.googlesource.com/chromium/tools/depot_tools.git/+/master/win_toolchain/package_from_installed.py points to a method of creating it from a fresh VM. Presumably we can use ​https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ and the community version of Visual Studio (steps to reproduce will follow)

Our standalone proxies were recently blocked in China: #30350

We should start running some probe tests like we are for obfs4 to see whether this blocking was a one-off event and detect blocking of new proxy instances.

This is a parent ticket for all single hop anti-DoS mitigation we want to put in Tor. Not only that but it should be seen as "any client single hop" hidden service requests rather than tor2web specific.

Child tickets are really the meat of the work so anything related to this topic should have a child ticket and this parent ticket should not be used for discussions.

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

I know this is basically just Debian instructions, but framing this differently could really help for those that don't already know that Raspbian is essentially just Debian underneath.

This could be deferred until after the big website changes.

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.

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.

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

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

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

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

FF 10.0.3 ESR HTTPS-E v2.1

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

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

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

We almost missed a memory safety bug in #31012, because our CI doesn't run our tools. We should write some quick tool tests, and run them in our CI.

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

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

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

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?

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