Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:42Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34311Space out code in relay.c2020-06-13T15:53:42ZNeel Chauhanneel@neelc.orgSpace out code in relay.cYes, I do understand that Tor is working on automatic code checks for things like code spacing and that I should work on that instead of sending spacing patches, but I still noticed a lot of spacing issues in relay.c (more than normal) s...Yes, I do understand that Tor is working on automatic code checks for things like code spacing and that I should work on that instead of sending spacing patches, but I still noticed a lot of spacing issues in relay.c (more than normal) so I just **had** to submit this.
My PR fixes all (or at least most) of relay.c.Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34310Maybe add new type of errors in the bandwidth file2020-06-13T16:16:42ZjugaMaybe add new type of errors in the bandwidth fileAs commented in https://trac.torproject.org/projects/tor/ticket/30905#comment:9
Things that are not really failures:
when loading the results, the relays that changed ip are excluded. I could add a patch to count all the results fi...As commented in https://trac.torproject.org/projects/tor/ticket/30905#comment:9
Things that are not really failures:
when loading the results, the relays that changed ip are excluded. I could add a patch to count all the results first, which reduces the number of failures in around 1000.
when sbws is restarted, all the queued relays to measure that didn't start to be measured yet, are not saved in the results, but the attempt has already been count. We could also add a patch to count the attempt in measure_relay, instead of main_loop, though then we won't know the number of attempts counting from the moment they were queued.
real failures would happen when result_putter_error is triggered, or some bug makes sbws stall, which then will print the TICKET_MSG error. In the 1st case, we could actually count an error.sbws: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34309Check that relay_recent_measurement_attempt_count and relay_recent_priority_l...2021-03-09T16:28:13ZjugaCheck that relay_recent_measurement_attempt_count and relay_recent_priority_list_count are correcThis was a comment in https://trac.torproject.org/projects/tor/ticket/30905#comment:9This was a comment in https://trac.torproject.org/projects/tor/ticket/30905#comment:9sbws: 1.1.x-finaljugajugahttps://gitlab.torproject.org/legacy/trac/-/issues/34308Creating a new Snowflake Android project.2020-06-13T18:22:17ZHashikDCreating a new Snowflake Android project.Creating a new/fresh project for Snowflake Android with just empty activity.
Project Name: Snowflake-Mobile
Package Name: org.torproject.snowflake
Min-SDK: API-21 - Android 5.0 LollipopCreating a new/fresh project for Snowflake Android with just empty activity.
Project Name: Snowflake-Mobile
Package Name: org.torproject.snowflake
Min-SDK: API-21 - Android 5.0 Lollipophttps://gitlab.torproject.org/legacy/trac/-/issues/34307RxJava library for making asynchronous calls.2020-06-13T18:22:17ZHashikDRxJava library for making asynchronous calls.To be clear it's perfectly fine starting a project without this library by using Android's official inbuild **AsyncTask** class but Google is deprecating the Async task library in favor of RxJava. Async task works for now but might not w...To be clear it's perfectly fine starting a project without this library by using Android's official inbuild **AsyncTask** class but Google is deprecating the Async task library in favor of RxJava. Async task works for now but might not work in future versions of Android.
[Reference](https://www.xda-developers.com/asynctask-deprecate-android-11/)https://gitlab.torproject.org/legacy/trac/-/issues/34306retire omeiense2020-06-13T17:02:17Zanarcatretire omeienseanarcatanarcathttps://gitlab.torproject.org/legacy/trac/-/issues/34305NoScript inconsistent behaviour in Firefox 77 (currently beta)2020-06-16T01:13:09ZAlex CatarineuNoScript inconsistent behaviour in Firefox 77 (currently beta)While working on fixing the testsuite (#27105) I ran into some inconsistent blocking behaviour of NoScript in a Tor Browser WIP build based on Firefox 77 beta.
Basically, the issue is that with Tor Browser `Safer` NoScript configuratio...While working on fixing the testsuite (#27105) I ran into some inconsistent blocking behaviour of NoScript in a Tor Browser WIP build based on Firefox 77 beta.
Basically, the issue is that with Tor Browser `Safer` NoScript configuration when visiting a `http:` page (containing a https: iframe) and then going to the `https:` version of the same page results in JavaScript being blocked, but it should not be. Manually reloading the `https:` page results in JavaScript being executed correctly.
After some effort, I managed to reproduce in current Firefox 77 beta directly, more specifically: `f2e0df68e569b43ca337535927ed63068ed01c664eea7e397378cae668f63d0a firefox-77.0b9.tar.bz2`. Tested with NoScript 11.0.26 and 11.0.25.
Steps to reproduce (in a fresh profile):
- Install NoScript addon.
- Go to NoScript options page (either via about:addons or via NoScript toolbar badge).
- Enable "script" option and "Cascade top document's restrictions to subdocuments" in the General + Default tab.
- Still in General, go to "UNTRUSTED" and enable "frame".
- Go to "Per-site permission" tab and add a new rule: "http:" and mark it as "untrusted" (basically, setting non-https pages as untrusted).
- Open a new tab and visit http://alltaken.xyz/https_iframe.html
- When loaded, open a new tab and visit https://alltaken.xyz/https_iframe.html
- Result: JavaScript is blocked, but it should not be. When the page is manually reloaded (press F5), the script is executed correctly, and the `JavaScriptEnabled` text is displayed.Alex CatarineuAlex Catarineuhttps://gitlab.torproject.org/legacy/trac/-/issues/34304new gnt-fsn node (fsn-node-07)2020-06-13T17:02:17Zanarcatnew gnt-fsn node (fsn-node-07)need to create one last ganeti node to replace kvm5 (#33084)need to create one last ganeti node to replace kvm5 (#33084)HiroHirohttps://gitlab.torproject.org/legacy/trac/-/issues/34303Find out why onion service measurements have gotten slower2020-06-13T15:53:42ZKarsten LoesingFind out why onion service measurements have gotten slowerToday I changed the ["Time to download files over Tor" graph](https://metrics.torproject.org/torperf.html) to include version 3 onion service measurements.
By chance, I also looked at the [onion server measurements](https://metrics.torp...Today I changed the ["Time to download files over Tor" graph](https://metrics.torproject.org/torperf.html) to include version 3 onion service measurements.
By chance, I also looked at the [onion server measurements](https://metrics.torproject.org/torperf.html?start=2020-02-25&end=2020-05-25&server=onion&filesize=50kb) and found that the onion service measurements made by op-nl2, op-us2, and op-hk2 have gotten much slower as compared to their op-nl, op-us, and op-hk predecessors.
I'm 95% certain that this is not a bug in the graphs.
My current best guess is that something in `tor` has changed. I'd like to set up a small number of experimental OnionPerf instances all in the same place but with different `tor` versions. Any suggestions on locations (Amsterdam, Florida, Hong Kong) or `tor` versions?
This is also relevant to Sponsor 59 in order to make sure that our current measurements are going to be a baseline for future experiments. Classifying as potential defect.Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/34302Include version 3 onion service measurements in all performance graphs2020-06-13T18:15:35ZKarsten LoesingInclude version 3 onion service measurements in all performance graphsIn #33434 we found that the results of version 2 and version 3 onion service measurements are almost identical. But so far we're not plotting the version 3 measurements at all. We need to fix that, in particular due to version 2 measurem...In #33434 we found that the results of version 2 and version 3 onion service measurements are almost identical. But so far we're not plotting the version 3 measurements at all. We need to fix that, in particular due to version 2 measurements going away soon.
I started working on a patch over the weekend that includes version 3 onion service measurements in all performance graphs. I'll merge and deploy that today.Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/34301Fix shellcheck issues in our tor-browser-build scripts2020-06-16T01:26:29ZGeorg KoppenFix shellcheck issues in our tor-browser-build scriptsWe add more and more shell scripts for different tasks into our `tor-browser-build` repo, which is great. We should go over the already existing ones and fix `shellcheck` issues.
This is the parent ticket for that effort.We add more and more shell scripts for different tasks into our `tor-browser-build` repo, which is great. We should go over the already existing ones and fix `shellcheck` issues.
This is the parent ticket for that effort.https://gitlab.torproject.org/legacy/trac/-/issues/34300Ensure GetTor's email unit tests are properly formatted2020-06-21T18:06:14ZCecylia BocovichEnsure GetTor's email unit tests are properly formattedFrom #34286:
[comment:3 phw]:
> Looks good to me!
>
> On a slightly related note: I believe that an email's body is supposed to be separated by two (rather than one) newlines from its header. GetTor's unit tests are using only one (and...From #34286:
[comment:3 phw]:
> Looks good to me!
>
> On a slightly related note: I believe that an email's body is supposed to be separated by two (rather than one) newlines from its header. GetTor's unit tests are using only one (and mix \n with \r\n). Python's email module is also confused by this and thinks that the body is part of the `To` field:
>
> {{{
> In [1]: from email import message_from_string
> In [3]: m=message_from_string("From: MAILER-DAEMON@mx1.riseup.net\nSubject: Undelivered Mail Returned to Sender\r\nTo: gettor@torproject.org\n osx en\n")
> In [6]: m.items()
> Out[6]:
> [('From', 'MAILER-DAEMON@mx1.riseup.net'),
> ('Subject', 'Undelivered Mail Returned to Sender'),
> ('To', 'gettor@torproject.org\n osx en')]
> }}}
>
> This seems like something we should fix.https://gitlab.torproject.org/legacy/trac/-/issues/34299man page has wrong default for MinUptimeHidServDirectoryV22020-06-13T15:53:41ZRoger Dingledineman page has wrong default for MinUptimeHidServDirectoryV2In #14149 (Tor 0.2.6.3-alpha) we changed the default for MinUptimeHidServDirectoryV2 to 96 hours, to reflect that the directory authorities had already changed it manually. We changed the spec too. But we forgot to change the man page.In #14149 (Tor 0.2.6.3-alpha) we changed the default for MinUptimeHidServDirectoryV2 to 96 hours, to reflect that the directory authorities had already changed it manually. We changed the spec too. But we forgot to change the man page.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34298Address networkx's API change, which breaks OnionPerf2020-06-13T18:04:42ZPhilipp Winterphw@torproject.orgAddress networkx's API change, which breaks OnionPerfNetworkx in version [2.4](https://networkx.github.io/documentation/stable/release/release_2.4.html) deprecated the `node` attribute of `DiGraph` and suggests using `nodes` instead. This breaks OnionPerf but luckily, it's an easy fix.
He...Networkx in version [2.4](https://networkx.github.io/documentation/stable/release/release_2.4.html) deprecated the `node` attribute of `DiGraph` and suggests using `nodes` instead. This breaks OnionPerf but luckily, it's an easy fix.
Here's the error I'm getting on master:
```
Traceback (most recent call last):
File "/home/phw/rcs/onionperf/venv/bin/onionperf", line 4, in <module>
__import__('pkg_resources').run_script('OnionPerf==0.2rc0', 'onionperf')
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/pkg_resources/__init__.py", line 666, in run_script
self.require(requires)[0].run_script(script_name, ns)
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/pkg_resources/__init__.py", line 1453, in run_script
exec(script_code, namespace, namespace)
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/EGG-INFO/scripts/onionperf", line 529, in <module>
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/EGG-INFO/scripts/onionperf", line 350, in main
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/EGG-INFO/scripts/onionperf", line 401, in measure
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/onionperf/measurement.py", line 239, in run
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/onionperf/measurement.py", line 315, in __start_tgen_client
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/onionperf/measurement.py", line 341, in __start_tgen
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/onionperf/model.py", line 66, in __init__
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/onionperf/model.py", line 74, in generate
AttributeError: 'DiGraph' object has no attribute 'node'
```Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34297Explore different options other than crontab to have a flexible scheduling sy...2020-06-13T17:56:18ZBarkin SimsekExplore different options other than crontab to have a flexible scheduling systemCurrently, I use crontab for fetching web pages at regular intervals. I believe it is not the best option, and it is worth exploring the options available.Currently, I use crontab for fetching web pages at regular intervals. I believe it is not the best option, and it is worth exploring the options available.https://gitlab.torproject.org/legacy/trac/-/issues/34296Develop a mechanism for disabling/enabling cookie, JavaScript, etc. functiona...2020-06-13T17:56:18ZBarkin SimsekDevelop a mechanism for disabling/enabling cookie, JavaScript, etc. functionality of the web browsershttps://gitlab.torproject.org/legacy/trac/-/issues/34295Develop a module for parsing and modifying the HTTP headers2020-06-13T17:56:18ZBarkin SimsekDevelop a module for parsing and modifying the HTTP headersWe need to develop a module for parsing and modifying the HTTP headers to test different conditions.We need to develop a module for parsing and modifying the HTTP headers to test different conditions.https://gitlab.torproject.org/legacy/trac/-/issues/34294Integrate Tor Stem2020-06-13T17:56:17ZBarkin SimsekIntegrate Tor StemIntegrate [Tor Stem](https://stem.torproject.org/) to choose specific Tor exit nodes for testing.Integrate [Tor Stem](https://stem.torproject.org/) to choose specific Tor exit nodes for testing.https://gitlab.torproject.org/legacy/trac/-/issues/34293Create an API for running the system on the user-provided websites2020-06-13T17:56:17ZBarkin SimsekCreate an API for running the system on the user-provided websitesThis part of the API aims to run certain tests on user-provided websites. So that people are not limited to the types of websites provided by the CAPTCHA Monitor.This part of the API aims to run certain tests on user-provided websites. So that people are not limited to the types of websites provided by the CAPTCHA Monitor.https://gitlab.torproject.org/legacy/trac/-/issues/34292Create an API for people to fetch data easily2020-06-13T17:56:16ZBarkin SimsekCreate an API for people to fetch data easilyThis API might feature customized queries to get a specific part of the dataset rather than the whole dataset.This API might feature customized queries to get a specific part of the dataset rather than the whole dataset.