{5} Accepted, Active Tickets by Owner (Full Description) (112 matches)
List tickets accepted, group by ticket owner. This report demonstrates the use of full-row display.
Results (1 - 100 of 112)
Cthulhu (2 matches)
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#13421 | GoodBadISP's Revamp | Community/Relays | project | Oct 15, 2014 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Following a discussion on the mailing list [1] the GoodBadISP page could do with some updating and proper arranging. Some of the categories I have in mind to make available in the table format are as follows: Country, Company Name, ASN, Bridges Allowed, Relays Allowed, Exits Allowed, Last Updated, Correspondence. Would "Bridges Allowed" be a redundant measure since they won't be in the public sphere? Moritz @ Torservers already has done a fair deal of work, some is outdated or could use an update though but it's a good place to start our focus and give inspiration where needed. [2] [3] [4] [1] https://lists.torproject.org/pipermail/tor-relays/2014-October/005493.html [2] https://www.torservers.net/wiki/hoster/experience [3] https://www.torservers.net/wiki/hoster/inquiry [4] https://www.torservers.net/wiki/hoster/index Note: Those wishing to assist on this project please feel free to CC yourself in and keep an eye on the child tickets. I can be found under the pseudonym "TheCthulhu" on IRC or contacted at thecthulhu <at> riseup <dot> net if you wish to ask me directly what to work on next. If this is the first time you've assisted using Trac or the Tor Wiki, don't hesitate to ask for help. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#13473 | Sort Existing GoodBadISP page into tables | Community/Relays | task | Oct 19, 2014 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The existing GoodBadISP tables need sorting into the new format. All opinions, feedback and communications to that ISP must go in the correct section on ISPCorrespondence page to keep the primary page clean and to the point since it will grow substantially over time. The new format should be available soon after this ticket is posted as it will be done for the US hosts (good experiences). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Hello71 (1 match) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#22233 | Reconsider behavior on .z URLs with Accept-Encoding header | Core Tor/Tor | Tor: unspecified | defect | May 11, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
In proposal 278, I said: If a directory server receives a request to a document with the ".z" suffix, where the client does not include an "Accept-Encoding" header, the server should respond with the zlib compressed version of the document for backwards compatibility with client that does not support this proposal. But on #22206 it became apparent that we've got a problem there: there are already tools (built e.g. on wget) that ask for the .z URL but which send "Accept-Encodings: Identity." And onn #22206, Yawning says:
We'd like the end result here to be something where new Tor clients can interoperate with older directory caches without breaking anything, and getting the new compression type if they support it. And we certainly don't want anybody doing two layers of compression: that's a waste of cycles. But we should see if there's a way where we can be more standards compliant without breaking anything we care about. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jaruga (3 matches) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#20537 | Tor Browser User Manual needs meta section | Community/Tor Browser Manual | defect | Nov 2, 2016 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The Tor Browser User Manual on https://tb-manual.torproject.org/windows/en-US/ needs a section covering
Cheers, |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#24872 | remove outdated tor relay security recommendations and update these wiki pages | Community/Relays | defect | Jan 11, 2018 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
While working on #24497 I wanted to link to existing security related recommendations and found: https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity https://trac.torproject.org/projects/tor/wiki/doc/OperationalSecurity IMHO these are severely outdated and give bad advises. I'm proposing to remove some outdated content and if no one disagrees I'll proceed soon. I'll send email to tor-dev about this. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#13703 | Adding doc/HARDENING | Community | Tor: unspecified | enhancement | Nov 7, 2014 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The two text files currently in the doc directory are doc/HACKING and doc/TUNING. The latter is the only one that deals with relay operation, and its subject is oddly specific: increasing the maximum number of file descriptors. If we're going to put critical documentation in the codebase, I think it would also be worthwhile to have a basic hardening guide. It could include suggestions like:
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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jkee299 (1 match) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#28541 | Exit | HTTPS Everywhere | project | Nov 20, 2018 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-quit |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
JohnnyFrog (1 match) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#29345 | Can't install TOR as a service on Windows 10 | Community/Tor Support | defect | Feb 5, 2019 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
When trying to execute tor.exe --service install --options -f C:\absolute\path\to\torrc an <unformattable error> is given: Running on a Post-Win2K OS, so we'll assume that the LocalService account exists. Done with CreateService. Service installed successfully Service failed to start : <unformattable error> This bug happens when there is something written in the torrc file, but on other attempts it was happening when using HiddenServiceAuthorizeClient basic PCNAME and so deleting this line it has been starting again. If I leave the torrc file empty the error doesn't show up and the service is installed and working. I tried to differently formatting torrc file, so using LF and CRLF, but the result is the same. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
MB (1 match) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#9328 | o2online.de Live Check not working with enabled SSL strictness | HTTPS Everywhere/EFF-HTTPS Everywhere | defect | Jul 25, 2013 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
With enabled HTTPS Everywhere, http://www.o2online.de/microsite/o2-netz/live-check/ does not load additional JavaScript from a non-SSL CDN |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ahf (2 matches) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#11660 | Make tor_spawn_background and related interfaces work the same on windows and *nix | Core Tor/Tor | Tor: unspecified | defect | Apr 30, 2014 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#21678 | Unify Windows and Unix API for tor_read_all_handle() in util.c | Core Tor/Tor | Tor: unspecified | enhancement | Mar 8, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
While working on #21654 I noticed that we have some different code paths that depends upon whether we're running on Windows or not where it would be trivial to turn them into a single code path. I do not have access to a Windows machine right now, so it would be useful if someone could help test the patch(es). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
arma (5 matches) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#15713 | toggling DisableNetwork during bootstrap causes delay | Core Tor/Tor | Tor: unspecified | defect | Apr 17, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
While testing a fix for #11879, Kathy and I noticed that if the bootstrap process is interrupted by setting DisableNetwork=1 via the control port, Tor waits about a minute after DisableNetwork is set back to 0 before continuing network activity. We observed this problem on a Mac OS 10.8.5 system. Possibly related tickets: #9229, #11069. Once release candidates for Tor Browser 4.5 are available, this should be reproducible by following these steps:
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):
We used the torrc-defaults file that ships with Tor Browser 4.5a5: # If non-zero, try to write to disk less frequently than we would otherwise. AvoidDiskWrites 1 # Where to send logging messages. Format is minSeverity[-maxSeverity] # (stderr|stdout|syslog|file FILENAME). Log notice stdout # Bind to this address to listen to connections from SOCKS-speaking # applications. SocksPort 9150 ControlPort 9151 CookieAuthentication 1 ## fteproxy configuration ClientTransportPlugin fte exec PluggableTransports/fteproxy.bin --managed ## obfs4proxy configuration ClientTransportPlugin obfs2,obfs3,obfs4,scramblesuit exec PluggableTransports/obfs4proxy ## flash proxy configuration # # Change the second number here (9000) to the number of a port that can # receive connections from the Internet (the port for which you # configured port forwarding). ClientTransportPlugin flashproxy exec PluggableTransports/flashproxy-client --register :0 :9000 ## meek configuration ClientTransportPlugin meek exec PluggableTransports/meek-client-torbrowser -- PluggableTransports/meek-client Our torrc is also from Tor Browser and it just contains a few paths: DataDirectory /Users/.../tb-11879.app/TorBrowser/Data/Tor GeoIPFile /Users/.../tb-11879.app/TorBrowser/Data/Tor/geoip GeoIPv6File /Users/.../tb-11879.app/TorBrowser/Data/Tor/geoip6 I will attach some log output. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#15715 | spurious "Network is unreachable" error after setting DisableNetwork=1 | Core Tor/Tor | Tor: unspecified | defect | Apr 17, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
If DisableNetwork is set to 1 via SETCONF during bootstrapping, Tor sometimes generates spurious errors such as "Network is unreachable". Kathy and I saw this while testing a fix for #11879. We realize this may be difficult to fix due to the internal architecture / concurrency inside Tor. See #15713 for steps to reproduce (but note that an error does not occur every time). In the log that is attached to #15713 you can see an example:
(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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#19162 | Make it even harder to become HSDir | Core Tor/Tor | Tor: unspecified | defect | May 23, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
In #8243 we started requiring 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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#17773 | Should clients avoid using guards that lost the Guard flag? | Core Tor/Tor | Tor: unspecified | enhancement | Dec 8, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Nick and I both thought that at least in the past, Tor clients would stop using a relay as their guard, if it loses the Guard flag. But it looks like the code doesn't do that -- once a relay is your guard, you'll use it in the guard position regardless of whether it has the Guard flag at this moment or not. This is actually a tricky design decision. In favor of avoiding guards that don't have the guard flag:
In favor of using non-Guard guards anyway:
That "can't push you away" one looks big. What other aspects should we be considering here? |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#18213 | The parameter WarnUnsafeSocks does not work as specified in the documentation, no warning is logged in the log file | Core Tor/Tor | Tor: unspecified | defect | Feb 2, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The parameter WarnUnsafeSocks does not work as specified in the documentation, no warning is logged in the log file when a connection is done to an ip address. If WarnUnsafeSocks 1 (default) is set there is no warning in the log file. If you look at the code for log_unsafe_socks_warning, the only case where an error is logged is when safe_socks is true. safe_socks is true only when SafeSocks parameter is set, but not when WarnUnsafeSocks is set. The code should be if (safe_socks || options->WarnUnsafeSocks) { instead of if (safe_socks) { |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
atagar (1 match) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#16348 | Suppress exception chaining when PEP 3134 is merged | Core Tor/Stem | defect | Jun 10, 2015 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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() |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
boklm (2 matches) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#11508 | Test that about:tor page is properly loaded | Applications/Quality Assurance and Testing | enhancement | Apr 14, 2014 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
During the last beta release we realized that some translators translate "about:tor" which breaks it. We should write a test that checks this crucial page is working in built bundles. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#11509 | Make sure search engine strings are not translated | Applications/Quality Assurance and Testing | enhancement | Apr 14, 2014 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bug #11236 is caused by translated search engine strings. We should make sure those strings are not translated. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
catalyst (2 matches) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#22619 | SessionGroup = Reading config failed | Core Tor/Tor | Tor: unspecified | defect | Jun 15, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
If i specify SessionGroup as described in manual. tor stops with error. torrc: SocksPort 9051 SessionGroup=1 Jun 15 16:46:24.700 [warn] Invalid SocksPort option '"SessionGroup=INT"' Jun 15 16:46:24.700 [warn] Failed to parse/validate config: Invalid SocksPort/SocksListenAddress configuration Jun 15 16:46:24.701 [err] Reading config failed--see warnings above. second try SocksPort 9051 SessionGroup=INT Results into: Jun 15 16:46:35.677 [warn] Invalid SocksPort option '"SessionGroup=1"' Jun 15 16:46:35.678 [warn] Failed to parse/validate config: Invalid SocksPort/SocksListenAddress configuration Jun 15 16:46:35.677 [warn] Invalid SocksPort option '"SessionGroup=1"' Jun 15 16:46:35.678 [warn] Failed to parse/validate config: Invalid SocksPort/SocksListenAddress configuration Jun 15 16:46:35.678 [err] Reading config failed--see warnings above. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#23756 | tor's .gitlab-ci.yml is doing mirroring? why? | Core Tor/Tor | Tor: unspecified | defect | Oct 4, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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:
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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
cypherpunks (1 match) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#21518 | Pluggable transports for zero-rated services | Applications/Orbot | project | Feb 20, 2017 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Tor increases data usage, and most of the demographics that need Tor the most have very limited data, so please make PTs available for zero-rated services. For example FreedomPop zero-rates WhatsApp (https://9to5mac.com/2016/08/17/freedompop-whatsapp-sim-free-iphone/) in 30 countries on a free ($0/month) plan. A WhatsApp plugable transport would therefor allow users in poverty-stricken, massively oppressed countries to have unlimited free access to information through Tor. I'm not sure if the component should be Orbot or Tor; the WhatsApp example is for mobile but there is also zero-rating for house internet, or someone might want to use a WhatsApp PT on a desktop/laptop/notebook with conventional Tor, tethered to a smartphone for the zero-rated protocol. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
dgoulet (24 matches) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#22893 | prop224: Make intro point per-service and not per-descriptor | Core Tor/Tor | Tor: unspecified | enhancement | Jul 12, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#23744 | sched: Notification events have different meaning for each scheduler | Core Tor/Tor | Tor: unspecified | defect | Oct 2, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
As an example, KIST controls how much and when channel data is pushed on the network which means this A channel is scheduled in when it has cells in the queue, then they are flushed one by one by the KIST scheduler until the kernel says "no more space". Then, that channel is put back in the channel pending list and will get handled at the next tick of KIST.
So, we really don't need KIST to be notified of this event from
Where it is useful is the second callsite of that even in That being said, what needs to happened:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#26806 | Check if Tor clients sometimes send duplicate cells on rendezvous circuits: Possible replay detected! An INTRODUCE2 cell with thesame ENCRYPTED section was seen | Core Tor/Tor | Tor: unspecified | defect | Jul 16, 2018 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
As my v3 onion service is getting more and more popular, I started to get: [warn] Possible replay detected! An INTRODUCE2 cell with thesame ENCRYPTED section was seen 32 seconds ago. Dropping cell. I am inclined to think that this is more like a bug in Tor, maybe due to a race condition, rather than a replay attack.
I also think this is what causes #15618 - dgoulet confirmed that the warning can be reproduced every time a second This can probably go away if we fix #21084. I am not sure if that should be a parent ticket here or not, please change if you feel like it. I think I still have yawning's tool and notes about how to reproduce #21084. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#29136 | PT_LOG and PT_STATUS event fields unspecifed | Core Tor/Tor | Tor: 0.4.0.x-final | defect | Jan 19, 2019 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Recently Tor added PT_LOG and PT_STATUS events to the spec... https://gitweb.torproject.org/torspec.git/commit/?id=3028cf1 https://gitweb.torproject.org/torspec.git/commit/?id=b38257e Unfortunately the 'pt-spec.txt section 3.3.5' section they mention does not exist, and in looking around I can't find anything that describes what these event fields are defined as ('PT=' 'TYPE=', 'CONNECT=', etc). I started to write a stem parser for these but can't continue until this is done (I can't parse events without knowing what fields they include). David is aware of this and plans to has kindly offered to add the missing info... 22:24 <+atagar> dgoulet: Your control-spec addition to descript PT_LOG and PT_STATUS cite a pt-spec section 3.3.4 which does not exist. 22:24 <+atagar> s/descript/describe 22:29 <+atagar> dgoulet: Huh. I'm not spotting anything that lists the keyword arguments ('PT=' and 'SEVERITY=') so guess the sections simply missing from the spec. I need that for stem support so please give me a nudge when the event spec's done. :) 22:59 <+dgoulet> atagar: oh hmmm I'll fix that sorry 23:17 <+atagar> Thanks! Much appreciated. :) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#3733 | Tor should abandon rendezvous circuits that cause a client request to time out | Core Tor/Tor | Tor: unspecified | defect | Aug 14, 2011 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Aug 14 05:59:04.639 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'. Aug 14 05:59:09.631 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'. Aug 14 06:04:08.637 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'. Aug 14 06:04:10.634 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'. Aug 14 06:04:30.680 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'. All of these streams had been attached to the same rendezvous circuit. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#14322 | torsocks fails to wrap setcap binaries | Core Tor/Torsocks | defect | Jan 22, 2015 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/iputils.install?h=packages/iputils |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#16934 | youtube-dl (recent), torsocks 2.1.0 and TBB5+ failure | Core Tor/Torsocks | defect | Aug 31, 2015 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ERROR torsocks[29369]: [socks5] Resolve destination buffer too small (in socks5_recv_resolve_reply() at socks5.c:690) ERROR: Unable to download webpage: <urlopen error [Errno -4] Non-recoverable failure in name resolution> (caused by URLError(gaierror(-4, 'Non-recoverable failure in name resolution'),)) The error changes over time. But it is mostly in this range. With a fresh restart the problem goes away, but it is back after some time blocking all requests. Stopping any TBB5 running and starting TBB4.5.3 makes everything go smooth again. Besides TBB, nothing changes in the configuration. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#21084 | sometimes we call circuit has_opened() more than 2 times on client side | Core Tor/Tor | Tor: unspecified | defect | Dec 26, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
We have a branch 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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#23108 | prop224: Don't rotate all service descriptors at once | Core Tor/Tor | Tor: unspecified | defect | Aug 4, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
In /* XXX We rotate all our service descriptors at once. In the future it might * be wise, to rotate service descriptors independently to hide that all * those descriptors are on the same tor instance */ |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#23507 | Add single onion unreachable address algorithm to prop224 | Core Tor/Tor | Tor: unspecified | defect | Sep 13, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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:
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). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#23711 | sched: KIST writes to kernel and get a "wants to write" notification right after | Core Tor/Tor | Tor: unspecified | defect | Sep 29, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
KIST scheduler does call a write to kernel contrary to the vanilla scheduler. This is done through
That last function will ultimately call datalen = connection_get_outbuf_len(TO_CONN(conn)); if (datalen < OR_CONN_LOWWATER) { scheduler_channel_wants_writes(TLS_CHAN_TO_BASE(conn->chan));
That is OK if Could be the fix here is probably simple as: if (datalen > 0 && datalen < OR_CONN_LOWWATER) {
I suspect with KIST, the datalen will always be 0 because KIST in theory controls exactly what goes in the outbuf and what can be written to the kernel so when it triggers a connection write(), the entire outbuf should be drained (in theory). So the effect of this is that every write to the kernel from KIST triggers a useless "wants to write" event rescheduling the channel. Note that this only happens if the channel is in |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#23712 | sched: DESTROY cell on a circuit bypasses the scheduler | Core Tor/Tor | Tor: unspecified | defect | Sep 29, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
If you look at In the case the flush is triggered, the cell is immediately put in the outbuf and written to kernel by libevent which completely bypasses the scheduler. Maybe it is what we want that is go as fast as we can in destroying a circuit? Don't know but it has this effect on the scheduler where the channel is scheduled with a "wants_to_write" event from the connection subsystem and ultimately the channel gets scheduled with nothing in the queue because it is already on the outbuf. For KIST, this is not ideal because KIST should control the flow of data to the kernel.
It seems there are two places we queue cells into a cmux queue: I think it should simply trigger that notify to the scheduler instead of flushing it by itself. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#24008 | service_intro_point_new() should return NULL when passed a NULL extend_info | Core Tor/Tor | Tor: unspecified | defect | Oct 26, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
We pass a NULL extend_info to service_intro_point_new() in the unit tests, and expect a non-NULL return value. But buggy code could also pass NULL here, and we should return NULL if that happens. One way to fix this is to split the function into two, and only call the first half in the unit tests. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#24181 | Put IPv6 and unrecognised link specifiers in onion service EXTEND cells | Core Tor/Tor | Tor: unspecified | defect | Nov 8, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Prop224 says: The hidden service SHOULD NOT reject any LSTYPE fields which it doesn't recognize; instead, it should use them verbatim in its EXTEND request to the rendezvous point. https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n1689 We should either remove this from the spec, or we should:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#11579 | Torsocks should support Java | Core Tor/Torsocks | enhancement | Apr 21, 2014 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Right now Java programs run with torsocks have their network calls dropped, or sometimes crash. Torsocks should force Java programs to use Tor. This could be done by setting the proxy settings in the JVM with -DsockProxyHost=127.0.0.1 -DsocksProxyPort=8080. To ensure proxy obedience for DNS calls, torsocks might implement a DNS provider that uses SOCKS for resolution, add that to the classpath, and use it to override the DNS provider the JVM uses at runtime. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#11724 | Check recvmmsg() FD passing on Unix socket for TCP socket | Core Tor/Torsocks | enhancement | May 4, 2014 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
recvmsg() is supported as of now. A full exit should be done here because Torsocks can't handle this inet socket with Tor. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#11727 | Support shared onion pool for DNS resolution in separate process | Core Tor/Torsocks | enhancement | May 4, 2014 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
So it turns out that in irssi is doing DNS resolution in an other process and passing the result back to the first process which will make the connection. This means that the two process have two distinct onion pools so the process doing the DNS resolution will store the onion address with the reserved cookie but the other process, when connecting using that cookie, will be unable to find the onion address in its pool. One solution I have in mind is to create that onion pool in a shared memory (SHM) and hijack the clone/fork symbol so when we detect a new process we can set the onion pool reference in it thus sharing the pool across processes that have a common parent. I have a PoC that works but maybe there could be an IPC approach instead. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#13184 | Add an option to whitelist networks | Core Tor/Torsocks | enhancement | Sep 17, 2014 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This warning is possible for anything socket trying to connect to a localhost address.
We should implement a whitelist mechanism so the user can tell which local network is allowed such as localhost. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#17945 | Stop single hop client connections to Single Onion Services | Core Tor/Tor | Tor: unspecified | enhancement | Dec 29, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Tor2Web clients make a one-hop connection to HSDirs, intro points, and rend points. Single Onion Services also make a one-hop connection to the rendezvous point. This uses Tor as a one-hop proxy (in this case, to a single onion service), which we try to avoid, because it enables certain attacks. We also try to avoid single hop connections in the onion service protocol, because they give IP addresses to middle relays. See the child tickets for details. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#19407 | Support FD passing on Unix socket | Core Tor/Torsocks | enhancement | Jun 13, 2016 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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!?... |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#23579 | sched: Add accessors for channel_pending list | Core Tor/Tor | Tor: unspecified | enhancement | Sep 19, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Let's make this list private and have accessors. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#24451 | Put IPv6 link specifiers in client EXTEND cells | Core Tor/Tor | Tor: unspecified | enhancement | Nov 28, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Clients should put IPv6 link specifiers in the EXTEND cells to relays they choose from directory documents. We need to do this in the same releases as #24181, to avoid adding an v3 onion service distinguisher. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#19926 | BUG warning in connection_ap_attach_pending: waiting for rendezvous desc :* | Core Tor/Tor | Tor: unspecified | defect | Aug 17, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
connection_ap_attach_pending: Bug: 0x613000b8d680 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.2.9.1-alpha f6c7e131a1ceb178) Yeah, why? |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#19793 | Torsocks - only torify .onion domains | Core Tor/Torsocks | enhancement | Jul 31, 2016 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
What torsocks does: Routes all traffic through Tor. What it should do: It shoud have an option to route .onion domains through Tor, while normal traffic is not routed through Tor. Advantages This would allow Mail/XMPP servers to connect to .onion domains, without any configuration hassle. Original discussion http://tor-talk.torproject.narkive.com/j7MtPG5T/torsocks-usewithtor-only-for-onion |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
feynman (1 match) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#9022 | Create an XMPP pluggable transport | Obfuscation/Pluggable transport | task | Jun 5, 2013 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
We should look into XMPP pluggable transports. There are many public XMPP services that see widespread use even from censored countries. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
hiro (5 matches) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#22530 | Redirection loop with disabled js on every page of blog.torproject.org | Webpages/Blog | defect | Jun 8, 2017 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
For several years everyone was able to post on https://blog.torproject.org without enabling JavaScript and other dangerous things. Observed behaviour: can not post unless slider set to medium or low Expected behaviour: high security supported Steps to reproduce: try to post at https://blog.torproject.org with security slider on high |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#23574 | Don't allow text injection in our 404 page | Internal Services/Tor Sysadmin Team | defect | Sep 19, 2017 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
We got a report on HackerOne by sumitthehacker: i want to report a text injection and a misconfiguration of the 404 page the bug exists at : 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." |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#28065 | Tor web docs | Internal Services/Services Admin Team | defect | Oct 16, 2018 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
During the meeting in CDMX some of us chatted about the possibility to build and maintain a sort of Tor web docs (like the mozilla web docs [1]). The idea is to collect all the techniques we use to make websites tor-browser and privacy friendly in a single place. We could also include the reasoning behind doing certain things in pure css vs js. Or why we decide to do things in a certain way. Some topic that I have been thinking about are:
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:
[1] https://developer.mozilla.org/en-US/ [2] https://lists.torproject.org/pipermail/tor-onions/2018-August/000295.html |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#22842 | Create a knowledge base that's more in-depth than FAQs | Webpages/Website | WebsiteV3 | task | Jul 6, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
It would be useful for visitors to our web pages to have access to content that:
These pages would form sort of a knowledge base or resource section. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#23809 | Add instructions for running a relay on a Raspberry Pi | Community/Tor Support | website redesign | task | Oct 10, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I know this is basically just Debian instructions, but framing this differently could really help for those that don't already know that Raspbian is essentially just Debian underneath. This could be deferred until after the big website changes. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
irl (7 matches) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#21378 | Archive bwauth bandwidth files | Metrics/CollecTor | enhancement | Feb 2, 2017 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The raw bwauth votes (sample: https://bwauth.ritter.vg/bwauth/bwscan.V3BandwidthsFile) contain information such as last measured time, circuit failures and (eventually) scanner information. This can be used for debugging purposes. Blocked by #21377, possible next steps in comment 14. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#26838 | Port the research portal content to Lektor | Webpages/Website | enhancement | Jul 17, 2018 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This will allow easy update to conform to the styleguide and make it easier to edit the content, and provide translations if desired. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#27138 | display timestamp and version information on page with no results | Metrics/Relay Search | enhancement | Aug 14, 2018 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
" Information for relays was published: 2018-08-14 11:00:00 UTC. Information for bridges was published: 2018-08-14 10:42:38 UTC. Onionoo version: 6.2/7d73a0c " this information is not displayed on the page if no result is found, but especially in that cases it would be important to know https://metrics.torproject.org/rs.html#search/NOTEXISTING |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#27154 | Do not display "AS0" in results or details pages | Metrics/Relay Search | enhancement | Aug 15, 2018 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
RS uses "AS0" as a placeholder for "unknown AS number", but "AS0" has a special meaning in BGP (https://tools.ietf.org/html/rfc7607 ), lets use something else? maybe "ASXY"? |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#28465 | Use or remove "package" lines from votes | Core Tor/Tor | Tor: unspecified | enhancement | Nov 15, 2018 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Currently dir-spec permits "package" lines in votes that can be used to vote on what the digest and location for a particular version of a software package is. This is not present in any votes I've seen. We should either use this, or remove it from the spec (and any code that supports it in tor). Roughly around here: https://spec.torproject.org/dir-spec#n1722 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#15948 | Can we do away with public SVN? | Internal Services/Service - git | task | May 7, 2015 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
According to https://svn.torproject.org/cgi-bin/viewvc.cgi/Tor/ , it's been at least six months since anything changed on the public SVN repository. Most of the repositories there have been migrated to git. We could migrate all the rest to git (if appropriate) or archive them (if appropriate), and turn off the lights on public svn. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#28271 | Check OnionPerf instances from Nagios | Metrics/Onionperf | task | Oct 31, 2018 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
There are a few things that we can check, some are easier than others.
For monitoring the Onion service, I'm looking at reusable plugins, so there are two tests. One checks to see how old the descriptor is and a second test actually tries connecting to the service. The first of these tests is affected by #28269 (but not blocked) and both are blocked by onionperf#42. As a workaround for monitoring the Onion service, which really is the bit that is breaking, we can instead monitor the analysis of timeouts from Tor Metrics' CSV files. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
juga (1 match) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#28045 | Start supporting python 3.7 | Core Tor/sbws | sbws: unspecified | defect | Oct 15, 2018 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
lunar (1 match) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#11355 | Provide obfsproxy nightlies in our debian repositories | Obfuscation/Obfsproxy | task | Mar 28, 2014 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
People are asking for obfsproxy nightlies (#10954). It would be brilliant if people could add our debian repo, and get the latest obfsproxy master through it. How can I help you do this? No hurry on this one. I mainly made this ticket because #10954 was not very specific. Thanks! |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
mikeperry (1 match) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#2161 | Allow subscription to external rule feeds | HTTPS Everywhere/EFF-HTTPS Everywhere | enhancement | Nov 6, 2010 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The ultimate direction we want to go is towards an adblock plus model, where people can subscribe to rule feeds that are relevant to them, maintained by third parties. This involves both altering our XML schema to include a 'rulefeed' envelope tag, and adding a bit of UI to add and manage subscription urls. It also depends upon a few enhancements being completed first. These are in the child ticket list below: |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
n8fr8 (6 matches) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#2424 | Android purges firewall rules after network disable/airplane mode. | Applications/Orbot | defect | Jan 22, 2011 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Setting my phone to disable data access and/or enable airplane mode seems to cause the transproxy iptables rules created by OrBot to get silently flushed. After re-enabling, all apps access everything without tor, until I go into the orbot config screen to cause it to reapply them. OrBot should listen for these network disable/loss/disconnect events if possible, and reinstate the iptables rules after this happens. Someone should also test if switching from cell data to+from wifi also triggers this iptables reset. I have not tested that yet. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#3595 | Connections with IPv4-mapped IPv6 addresses bypass transproxy | Applications/Orbot | defect | Jul 14, 2011 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A user (DEplan on #guardianproject) reported that Gibberbot was using his real IP despite Orbot's transproxy being turned on; further research led to the conclusion that recent releases of Android seem to use IPv4-mapped IPv6 adresses for a large portion of connections. For examples, please see http://pastebin.com/Z4KDDq40. These connections completely bypass transproxy. I am not yet sure about the circumstances under which Android employs these addresses. The problems in finding a solution are that Android usually does not include ip6tables (though Orbot could simply package that) and kernels do usually not include IPv6 netfilter modules. The latter is a major issue, since Orbot can't package modules for every single kernel a user might be running. As a side note, IPv6 does not support NAT (which is what transproxying is based on). I'll try to figure out what triggers this behaviour of Android and find possible solutions (using sysctl to disable IPv6 does not solve it). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#5393 | orbot relay bug - orbot is not setting the relay values into torrc properly causing orbot to not work when set as relay | Applications/Orbot | defect | Mar 15, 2012 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This is about the bug discussed with 'n8fr8' on #guardianproject at freenode. So, the relay functionality you said was broken and needs to be fixed for 'orbot' on smartphones. I checked with the orbot version '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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#2761 | Orbot Service not shutting down | Applications/Orbot | defect | Mar 15, 2011 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Behaviour: When closing tor network with big Button and exiting Orbot after tor is "deactivated", privoxy is still running and the Orbot service is not stopped. Actions:
Env:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#3775 | Permission error on Orbot | Applications/Orbot | defect | Aug 21, 2011 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
There's some kind of problem with permissions in Orbot. I'm not sure if this happens only to me, but when I try to start Tor, it cannot access cache/control_auth_cookie. I can chmod it every time, but it is a bit annoying. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#5469 | Orbot: can't specify node restrictions | Applications/Orbot | defect | Mar 24, 2012 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I'm using Orbot (v0.2.3.10-alpha-1.0.7-FINAL, on Android ICS v4.0.1) and I can't seem to get the exit node I request. In the Exit and Entrance Node fields I have "{us}" entered, yet sometimes I get IP's outside the US. Yesterday I got a UK ip. Also, at random (usually after 30 minutes or so) I seem to lose connection to the Tor network without Orbot notifying me. I'm using Pandora from Canada. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
nickm (30 matches) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#17278 | Fix malleable relay crypto | Core Tor/Tor | Tor: unspecified | defect | Oct 7, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This has been an annoyance in our protocol for entirely too long. Once we have a solid proposal (#5460) for this, we should implement it posthaste. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#19984 | Use a better set of comparison/evaluation functions for deciding which connections to kill when OOS | Core Tor/Tor | Tor: unspecified | defect | Aug 25, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Our existing OOS code kills low-priority OR connections. But really, we need to look at all connections that an adversary might be able to create (especially dir and exit connections), or else an adversary will be able to open a bunch of those, and force us to kill as many OR connections as they want. This problem is the reason that DisableOOSCheck is now on-by-default. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#25386 | Link Rust Tests to C Dependencies in Tor (allow integration testing from Rust to C) | Core Tor/Tor | Tor: unspecified | defect | Feb 28, 2018 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
currently, it is not possible to call C Tor, directly or indirectly, from rust tests. one of the following must be done:
my branch https://cgit.alxu.ca/tor.git/commit/?h=fix-rust-tests implements option 3 poorly. this is a bad solution firstly because it is very ugly, and secondly because it does not properly pass the system linking arguments, e.g. -L/opt/ssl. thirdly, it may hide problems in or cause to be compiled incorrectly dependency crates. this ticket blocks a number of rust improvements, since of course we would like to actually test the improvements, and doctests are the best way to do it in rust. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#18346 | Separate the various roles that directory authorities play, from a configuration POV | Core Tor/Tor | Tor: unspecified | enhancement | Feb 19, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
It would be handy if the following roles were split up:
Splitting roles up in this way would better prepare us for an implementation of prop#257 down the road. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#18637 | Have OOM handler look at all memory consumption, not just some | Core Tor/Tor | Tor: unspecified | enhancement | Mar 25, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Just because our OOM handler doesn't know how to free every kind of memory we allocate, doesn't mean we shouldn't teach it to consider our total allocation when deciding that we're low on memory. For platforms where malloc() can return NULL, we could have it look at that too. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#18788 | Make the copyright license clear for torspec and proposals | Core Tor/Tor | Tor: unspecified | enhancement | Apr 11, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Once upon a time, the tor spec files and proposals were in the Tor tarball, so they clearly were covered under Tor's copyright license (3-clause BSD). But now they're in their own git repository. I think maybe they technically have no copyright license now? We should pick one (I vote cc-by) and try to apply it. This plan could become tricky for proposals, because there are a lot of authors on proposals by now. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#18636 | Write sub-proposals for each part of prop257: Refactoring authorities. Implement as appropriate. | Core Tor/Tor | Tor: unspecified | project | Mar 25, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Proposal 257 outlines a pretty large amount of stuff to do, but each part of it probably needs its own proposal. Let's get cracking on that ! |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#15940 | Make a standard transition plan for killing off a client version | Core Tor/Tor | Tor: unspecified | task | May 6, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Parent ticket for transitioning current and future client versions off the tor network with a minimal amount of pain. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#15941 | Form a plan for killing off client versions which assume they'll live forever | Core Tor/Tor | Tor: unspecified | task | May 6, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
From at least 0.2.4 to 0.2.6, tor client versions assume that they will keep on using the network forever. They have no "request to stop" code or other mechanisms that prevent them becoming a drain on the network. It would help to plan their transition out at some point, so we can work out what to do to make version obsolescence in future. See #15233 for killing off 0.2.2 and 0.2.3 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#20835 | Refactor choose_good_entry_server so it is (almost) never used | Core Tor/Tor | Tor: unspecified | task | Nov 29, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
From my prop271 branch: * XXXX prop271 this function is used in four ways: picking out guards for * the old (pre-prop271) guard algorithm; picking out guards for circuits; * picking out guards for testing circuits on non-bridgees; * picking out entries when entry guards are disabled. These options * should be disentangled. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#21509 | Fuzz v3 hidden services | Core Tor/Tor | Tor: unspecified | task | Feb 19, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
If we want the fuzzer to effectively fuzz v3 hidden services, we need to:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#16579 | (Sandbox) Caught a bad syscall attempt (syscall socket) | Core Tor/Tor | Tor: unspecified | defect | Jul 14, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I'm running tor on Gentoo Hardened. The bug exists in 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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#18308 | Use a better pattern for "create mutex if not already initialized" | Core Tor/Tor | Tor: unspecified | defect | Feb 12, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Tor relies on double checked locking for various threading initializations. Double checked locking is not guaranteed to work. For Posix: 4.11, Memory Synchronization: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html Applications shall ensure that access to any memory location by more than one thread of control (threads or processes) is restricted such that no thread of control can read or modify a memory location while another thread of control may be modifying it. Race conditions: compat_pthreads.c:threads_initialized log.c:log_mutex_initialized Mutex static initialization is supported by pthreads via PTHREAD_MUTEX_INITIALIZER. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#18321 | Exclude our own vote from the consensus if we think our own vote is invalid | Core Tor/Tor | Tor: unspecified | defect | Feb 16, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
We're creating a vote that is invalid, but try to make a consensus anyway like nothing's wrong. Then we fail doing that as described above. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#19329 | Integrate callgraph complexity measures into our regular process | Core Tor/Tor | Tor: unspecified | defect | Jun 7, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Unless we track the size of the largest cycles in our code, big cycles may return |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#21474 | Fix make test-fuzz-corpora warnings | Core Tor/Tor | Tor: unspecified | defect | Feb 15, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The following bug warnings should probably be protocol warnings, or be caught earlier: ./src/test/fuzz_static_testcases.sh Running tests for consensus Feb 16 02:17:26.012 [warn] tor_timegm: Bug: Out-of-range argument to tor_timegm (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb) Feb 16 02:17:30.133 [warn] sr_parse_commit: Bug: SR: Commit algorithm "sha6-256" is not recognized. (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb) Feb 16 02:17:34.625 [warn] commit_decode: Bug: SR: Commit from authority 20EE989200EF98A75102B461DF62F01B2932C0D6 decoded length doesn't match the expected length (36 vs 40). (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb) Feb 16 02:17:40.758 [warn] commit_decode: Bug: SR: Commit from authority B0F141F4B8CCBCC328572C71E5590BBA19775594 can't be decoded. (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb) Running tests for descriptor Feb 16 02:18:08.780 [warn] tor_timegm: Bug: Out-of-range argument to tor_timegm (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb) Running tests for extrainfo Feb 16 02:18:18.548 [warn] tor_timegm: Bug: Out-of-range argument to tor_timegm (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb) ... I'm not sure whether we need this in 030, but it would be nice to fix them eventually. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#22264 | Remove old cached_dir_t code | Core Tor/Tor | Tor: unspecified | defect | May 15, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I'm pretty sure that with the completion of prop 278, we no longer use the old cached_dir_t code for anything at all. Let's rip it out! |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#22351 | Should bridge lines in the state file use unlisted_since? | Core Tor/Tor | Tor: unspecified | defect | May 23, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I have a bridge in my recent Tor (post prop#271), and my state file now says: Guard in=bridges rsa_id=C7BE8154678E7537CCAC60B097D51A8A7EF8BCDF bridge_addr=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? |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#27245 | Don't store (micro)descriptor text on the heap so much. | Core Tor/Tor | Tor: unspecified | defect | Aug 21, 2018 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
We could use less RAM for our (micro)descriptor text if we kept the .new file mmapped, so that we didn't need to use the heap to hold them. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#28481 | Tor's startup time is getting slower on Android | Core Tor/Tor | Tor: unspecified | defect | Nov 16, 2018 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
When upgrading Briar's Tor binaries from 0.2.9.16 to 0.3.4.8, we noticed a difference in Tor's startup time on older Android phones. Measuring the startup time of several recent Tor versions revealed an interesting pattern. The time that elapses between starting the Tor process and the creation of the authentication cookie file hasn't changed across versions, but the time between the creation of the cookie file and the response to the AUTHENTICATE command has changed substantially. (Briar sends the AUTHENTICATE command as soon as the cookie file's created.) I measured five runs of each version on a Motorola Moto G 4G running Android 5.1. Here are the min and max times in seconds for each version:
The min and max have both increased substantially since 0.2.9, and the distribution has widened. This is having a noticeable impact on how long it takes for Briar to connect to contacts when the app's started. I'll repeat these experiments on Linux x64 to see whether this is Android-specific. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#29310 | control-spec: "limits/max-mem-in-queues" appears to be undocumented | Core Tor/Tor | Tor: 0.4.1.x-final | defect | Feb 2, 2019 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
GETINFO info/names [...] limits/max-mem-in-queues -- Actual limit on memory in queues [...] but it can not be found in: https://gitweb.torproject.org/torspec.git/tree/control-spec.txt |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#17295 | Route-selection and guard-selection logic completely replaced | Core Tor/Tor | Tor: unspecified | enhancement | Oct 7, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
By Nov 2016, we have a deliverable to get our route selection much more right than today, and to have it very tested. We should get this done significantly earlier. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#20719 | prop271 -- make parameters configurable | Core Tor/Tor | Tor: unspecified | enhancement | Nov 18, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#20931 | [prop271] Generate GUARD controller events | Core Tor/Tor | Tor: unspecified | enhancement | Dec 8, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#28248 | Add comments around rust compilation flags | Core Tor/Tor | Tor: 0.3.5.x-final | enhancement | Oct 30, 2018 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
In particular, we should make sure that all the new and changed items in https://github.com/torproject/tor/pull/381 have explanatory comments. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#22962 | Clarify the security severity of issues that make denial of service easier | Core Tor/Tor | Tor: unspecified | task | Jul 18, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/SecurityPolicy In #22948, we discovered that the relay integrity digest was easier to guess than it should be. This makes the following classes of attacks easier:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#29269 | Evaluation of bridge statistics | Obfuscation/BridgeDB | task | Feb 1, 2019 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
See what we information we have, what we need, and how we can use these statistics. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#449 | dns failures prevent legitimate options being set | Core Tor/Tor | Tor: unspecified | defect | Jun 9, 2007 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Outright hostname lookup failures for previously configured hidden services prevent other options being set while DNS is down. For example, I configure a hidden service redirecting to google.com while DNS is working. DNS subsequently stops working, e.g. nameserver becomes completely unreachable. If I then attempt to set a config option using the controller, it will not get set as long as tor cannot resolve the hidden service name. Rejection of hidden service configurations (and hence any subsequent or unrelated config change) made while tor is running needs to be more tolerant of lookup failures. The following attempts to validate the hidden service config currently in use (and previously validated when DNS was working). If the validation fails, it must be because DNS is down, so the existing config is retained. If the user was attempting to add a new hidden service config, then it doesn't get added. Index: src/or/config.c =================================================================== --- src/or/config.c (revision 10545) +++ src/or/config.c (working copy) @@ -963,10 +963,15 @@ } } - if (running_tor && rend_config_services(options, 0)<0) { - log_warn(LD_BUG, - "Previously validated hidden services line could not be added!"); - return -1; + if (running_tor && rend_config_services(options, 1)<0) { + log_warn(LD_CONFIG, + "Previously validated hidden services line no longer valid! Retaining existing hidden services config if there is one."); + }else{ + if (rend_config_services(options, 0)<0){ + log_warn(LD_BUG, + "Previously validated hidden services line could not be added!"); + return -1; + } } if (running_tor) { @@ -2920,9 +2925,10 @@ } } +/* if (rend_config_services(options, 1) < 0) REJECT("Failed to configure rendezvous options. See logs for details."); - +*/ if (parse_virtual_addr_network(options->VirtualAddrNetwork, 1, NULL)<0) return -1; [Automatically added by flyspray2trac: Operating System: All] |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#21454 | tor_version_compare and version spec comparison order are inconsistent | Core Tor/Tor | Tor: unspecified | defect | Feb 14, 2017 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Similar to #21449, when we compare versions, we compare the status before the patchlevel, and then compare status tag and SCM information. But the spec says: 1. The Old Way ... We compare the elements in order (major, minor, micro, status, patchlevel, cvs) ... 2. The New Way ... MAJOR, MINOR, MICRO, and PATCHLEVEL are numbers ... All versions should be distinguishable purely by those four numbers. The STATUS_TAG is purely informational ... If we *do* encounter two versions that differ only by status tag, we compare them lexically ... This doesn't matter much at the moment because we don't use patchlevels. But we should fix this issue, probably by modifying the spec. Reported by arma. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#16598 | fsync ed25519 master key files before closing them. | Core Tor/Tor | Tor: unspecified | defect | Jul 15, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Weasel says this is a good idea, and IMO it can't hurt. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
pde (2 matches) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket | Summary | Component | Milestone | Type | Created | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#3777 | Should not generate mixed-content warnings if rewriting all http to https | HTTPS Everywhere/EFF-HTTPS Everywhere | defect | Aug 21, 2011 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
As far as I can tell, Firefox produces mixed-content warnings on an https page that references resources (images, scripts, etc) via http, even if HTTPS Everywhere can rewrite all of those http URLs to use https. (HTTPS Everywhere does rewrite resource requests, right?) Ideally, if HTTPS Everywhere successfully rewrites every http request from a page to an https request, the page should not generate a mixed content warning. (Though I'd still like to see some indication that the page was only secure due to HTTPS Everywhere, so I know to report the insecure resources to the site owner.) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#4278 | MSDN navigation breakage (due to Origin: header omission?) | HTTPS Everywhere/EFF-HTTPS Everywhere | defect | Oct 20, 2011 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Reported here: https://bugzilla.mozilla.org/show_bug.cgi?id=694611 Test case: Clicking on the fold-out tabs on the left of this page produces no results: http://msdn.microsoft.com/en-ca/subscriptions/downloads/default.aspx |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||