tor-commits January 2020

tor-commits@lists.torproject.org

19 participants
1596 discussions

[tor/master] copy 0.4.1.8 and 0.4.2.6 entries to master ChangeLog, ReleaseNotes.
by nickm＠torproject.org 30 Jan '20

30 Jan '20

commit 342ea3155196ed0b696ce368a4e226ba832586d0 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Jan 30 10:05:42 2020 -0500 copy 0.4.1.8 and 0.4.2.6 entries to master ChangeLog, ReleaseNotes. --- ChangeLog | 98 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ReleaseNotes | 98 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 196 insertions(+) diff --git a/ChangeLog b/ChangeLog index f64848a6c..195093a5b 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,101 @@ +Changes in version 0.4.2.6 - 2020-01-30 + This is the second stable release in the 0.4.2.x series. It backports + several bugfixes from 0.4.3.1-alpha, including some that had affected + the Linux seccomp2 sandbox or Windows services. If you're running with + one of those configurations, you'll probably want to upgrade; + otherwise, you should be fine with 0.4.2.5. + + o Major bugfixes (linux seccomp sandbox, backport from 0.4.3.1-alpha): + - Correct how we use libseccomp. Particularly, stop assuming that + rules are applied in a particular order or that more rules are + processed after the first match. Neither is the case! In + libseccomp <2.4.0 this lead to some rules having no effect. + libseccomp 2.4.0 changed how rules are generated, leading to a + different ordering, which in turn led to a fatal crash during + startup. Fixes bug 29819; bugfix on 0.2.5.1-alpha. Patch by + Peter Gerber. + - Fix crash when reloading logging configuration while the + experimental sandbox is enabled. Fixes bug 32841; bugfix on + 0.4.1.7. Patch by Peter Gerber. + + o Minor bugfixes (correctness checks, backport from 0.4.3.1-alpha): + - Use GCC/Clang's printf-checking feature to make sure that + tor_assertf() arguments are correctly typed. Fixes bug 32765; + bugfix on 0.4.1.1-alpha. + + o Minor bugfixes (logging, crash, backport from 0.4.3.1-alpha): + - Avoid a possible crash when trying to log a (fatal) assertion + failure about mismatched magic numbers in configuration objects. + Fixes bug 32771; bugfix on 0.4.2.1-alpha. + + o Minor bugfixes (testing, backport from 0.4.3.1-alpha): + - When TOR_DISABLE_PRACTRACKER is set, do not apply it to the + test_practracker.sh script. Doing so caused a test failure. Fixes + bug 32705; bugfix on 0.4.2.1-alpha. + - When TOR_DISABLE_PRACTRACKER is set, log a notice to stderr when + skipping practracker checks. Fixes bug 32705; bugfix + on 0.4.2.1-alpha. + + o Minor bugfixes (windows service, backport from 0.4.3.1-alpha): + - Initialize the publish/subscribe system when running as a windows + service. Fixes bug 32778; bugfix on 0.4.1.1-alpha. + + o Testing (backport from 0.4.3.1-alpha): + - Turn off Tor's Sandbox in Chutney jobs, and run those jobs on + Ubuntu Bionic. Turning off the Sandbox is a work-around, until we + fix the sandbox errors in 32722. Closes ticket 32240. + - Re-enable the Travis CI macOS Chutney build, but don't let it + prevent the Travis job from finishing. (The Travis macOS jobs are + slow, so we don't want to have it delay the whole CI process.) + Closes ticket 32629. + + o Testing (continuous integration, backport from 0.4.3.1-alpha): + - Use zstd in our Travis Linux builds. Closes ticket 32242. + + +Changes in version 0.4.1.8 - 2020-01-30 + This release backports several bugfixes from later release series, + including some that had affected the Linux seccomp2 sandbox or Windows + services. If you're running with one of those configurations, you'll + probably want to upgrade; otherwise, you should be fine with your + current version of 0.4.1.x. + + o Major bugfixes (linux seccomp sandbox, backport from 0.4.3.1-alpha): + - Correct how we use libseccomp. Particularly, stop assuming that + rules are applied in a particular order or that more rules are + processed after the first match. Neither is the case! In + libseccomp <2.4.0 this lead to some rules having no effect. + libseccomp 2.4.0 changed how rules are generated, leading to a + different ordering, which in turn led to a fatal crash during + startup. Fixes bug 29819; bugfix on 0.2.5.1-alpha. Patch by + Peter Gerber. + - Fix crash when reloading logging configuration while the + experimental sandbox is enabled. Fixes bug 32841; bugfix on + 0.4.1.7. Patch by Peter Gerber. + + o Minor bugfixes (crash, backport form 0.4.2.4-rc): + - When running Tor with an option like --verify-config or + --dump-config that does not start the event loop, avoid crashing + if we try to exit early because of an error. Fixes bug 32407; + bugfix on 0.3.3.1-alpha. + + o Minor bugfixes (windows service, backport from 0.4.3.1-alpha): + - Initialize the publish/subscribe system when running as a windows + service. Fixes bug 32778; bugfix on 0.4.1.1-alpha. + + o Testing (backport from 0.4.3.1-alpha): + - Turn off Tor's Sandbox in Chutney jobs, and run those jobs on + Ubuntu Bionic. Turning off the Sandbox is a work-around, until we + fix the sandbox errors in 32722. Closes ticket 32240. + - Re-enable the Travis CI macOS Chutney build, but don't let it + prevent the Travis job from finishing. (The Travis macOS jobs are + slow, so we don't want to have it delay the whole CI process.) + Closes ticket 32629. + + o Testing (continuous integration, backport from 0.4.3.1-alpha): + - Use zstd in our Travis Linux builds. Closes ticket 32242. + + Changes in version 0.4.3.1-alpha - 2020-01-22 This is the first alpha release in the 0.4.3.x series. It includes improved support for application integration of onion services, support diff --git a/ReleaseNotes b/ReleaseNotes index 97e16a6d8..c33355f68 100644 --- a/ReleaseNotes +++ b/ReleaseNotes @@ -2,6 +2,104 @@ This document summarizes new features and bugfixes in each stable release of Tor. If you want to see more detailed descriptions of the changes in each development snapshot, see the ChangeLog file. +Changes in version 0.4.2.6 - 2020-01-30 + This is the second stable release in the 0.4.2.x series. It backports + several bugfixes from 0.4.3.1-alpha, including some that had affected + the Linux seccomp2 sandbox or Windows services. If you're running with + one of those configurations, you'll probably want to upgrade; + otherwise, you should be fine with 0.4.2.5. + + o Major bugfixes (linux seccomp sandbox, backport from 0.4.3.1-alpha): + - Correct how we use libseccomp. Particularly, stop assuming that + rules are applied in a particular order or that more rules are + processed after the first match. Neither is the case! In + libseccomp <2.4.0 this lead to some rules having no effect. + libseccomp 2.4.0 changed how rules are generated, leading to a + different ordering, which in turn led to a fatal crash during + startup. Fixes bug 29819; bugfix on 0.2.5.1-alpha. Patch by + Peter Gerber. + - Fix crash when reloading logging configuration while the + experimental sandbox is enabled. Fixes bug 32841; bugfix on + 0.4.1.7. Patch by Peter Gerber. + + o Minor bugfixes (correctness checks, backport from 0.4.3.1-alpha): + - Use GCC/Clang's printf-checking feature to make sure that + tor_assertf() arguments are correctly typed. Fixes bug 32765; + bugfix on 0.4.1.1-alpha. + + o Minor bugfixes (logging, crash, backport from 0.4.3.1-alpha): + - Avoid a possible crash when trying to log a (fatal) assertion + failure about mismatched magic numbers in configuration objects. + Fixes bug 32771; bugfix on 0.4.2.1-alpha. + + o Minor bugfixes (testing, backport from 0.4.3.1-alpha): + - When TOR_DISABLE_PRACTRACKER is set, do not apply it to the + test_practracker.sh script. Doing so caused a test failure. Fixes + bug 32705; bugfix on 0.4.2.1-alpha. + - When TOR_DISABLE_PRACTRACKER is set, log a notice to stderr when + skipping practracker checks. Fixes bug 32705; bugfix + on 0.4.2.1-alpha. + + o Minor bugfixes (windows service, backport from 0.4.3.1-alpha): + - Initialize the publish/subscribe system when running as a windows + service. Fixes bug 32778; bugfix on 0.4.1.1-alpha. + + o Testing (backport from 0.4.3.1-alpha): + - Turn off Tor's Sandbox in Chutney jobs, and run those jobs on + Ubuntu Bionic. Turning off the Sandbox is a work-around, until we + fix the sandbox errors in 32722. Closes ticket 32240. + - Re-enable the Travis CI macOS Chutney build, but don't let it + prevent the Travis job from finishing. (The Travis macOS jobs are + slow, so we don't want to have it delay the whole CI process.) + Closes ticket 32629. + + o Testing (continuous integration, backport from 0.4.3.1-alpha): + - Use zstd in our Travis Linux builds. Closes ticket 32242. + + +Changes in version 0.4.1.8 - 2020-01-30 + This release backports several bugfixes from later release series, + including some that had affected the Linux seccomp2 sandbox or Windows + services. If you're running with one of those configurations, you'll + probably want to upgrade; otherwise, you should be fine with your + current version of 0.4.1.x. + + o Major bugfixes (linux seccomp sandbox, backport from 0.4.3.1-alpha): + - Correct how we use libseccomp. Particularly, stop assuming that + rules are applied in a particular order or that more rules are + processed after the first match. Neither is the case! In + libseccomp <2.4.0 this lead to some rules having no effect. + libseccomp 2.4.0 changed how rules are generated, leading to a + different ordering, which in turn led to a fatal crash during + startup. Fixes bug 29819; bugfix on 0.2.5.1-alpha. Patch by + Peter Gerber. + - Fix crash when reloading logging configuration while the + experimental sandbox is enabled. Fixes bug 32841; bugfix on + 0.4.1.7. Patch by Peter Gerber. + + o Minor bugfixes (crash, backport form 0.4.2.4-rc): + - When running Tor with an option like --verify-config or + --dump-config that does not start the event loop, avoid crashing + if we try to exit early because of an error. Fixes bug 32407; + bugfix on 0.3.3.1-alpha. + + o Minor bugfixes (windows service, backport from 0.4.3.1-alpha): + - Initialize the publish/subscribe system when running as a windows + service. Fixes bug 32778; bugfix on 0.4.1.1-alpha. + + o Testing (backport from 0.4.3.1-alpha): + - Turn off Tor's Sandbox in Chutney jobs, and run those jobs on + Ubuntu Bionic. Turning off the Sandbox is a work-around, until we + fix the sandbox errors in 32722. Closes ticket 32240. + - Re-enable the Travis CI macOS Chutney build, but don't let it + prevent the Travis job from finishing. (The Travis macOS jobs are + slow, so we don't want to have it delay the whole CI process.) + Closes ticket 32629. + + o Testing (continuous integration, backport from 0.4.3.1-alpha): + - Use zstd in our Travis Linux builds. Closes ticket 32242. + + Changes in version 0.4.2.5 - 2019-12-09 This is the first stable release in the 0.4.2.x series. This series improves reliability and stability, and includes several stability and

1 0

[tor/master] buf_read_from_tls: Return ERROR_MISC, not WANTWRITE, on BUG().
by nickm＠torproject.org 30 Jan '20

30 Jan '20

commit 2985a6018f1123b8843023f09d004f477f59a009 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Jan 29 08:49:01 2020 -0500 buf_read_from_tls: Return ERROR_MISC, not WANTWRITE, on BUG(). Fixes bug 32673; bugfix on 0.3.0.4-alpha. We introduced these checks in ee5471f9aab5526 to help diagnose 21369, but we used "-1" when "TOR_TLS_ERROR_MISC" would have been correct. Found by opara. I don't think that this is actually getting triggered in the wild, but if it were, it could cause nasty behavior: spurious WANTREAD/WANTWRITE returns have a way of turning into CPU-eating busy-loops. --- changes/bug32673 | 5 +++++ src/lib/tls/buffers_tls.c | 4 ++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/changes/bug32673 b/changes/bug32673 new file mode 100644 index 000000000..32f02c639 --- /dev/null +++ b/changes/bug32673 @@ -0,0 +1,5 @@ + o Minor bugfixes (TLS bug handling): + - When encountering a bug in buf_read_freom_tls(), return a + "MISC" error code rather than "WANTWRITE". This change might + help avoid some CPU-wasting loops if the bug is ever triggered. + Bug reported by opara. Fixes bug 32673; bugfix on 0.3.0.4-alpha. diff --git a/src/lib/tls/buffers_tls.c b/src/lib/tls/buffers_tls.c index e92cb9163..52be78811 100644 --- a/src/lib/tls/buffers_tls.c +++ b/src/lib/tls/buffers_tls.c @@ -69,9 +69,9 @@ buf_read_from_tls(buf_t *buf, tor_tls_t *tls, size_t at_most) check_no_tls_errors(); IF_BUG_ONCE(buf->datalen >= INT_MAX) - return -1; + return TOR_TLS_ERROR_MISC; IF_BUG_ONCE(buf->datalen >= INT_MAX - at_most) - return -1; + return TOR_TLS_ERROR_MISC; while (at_most > total_read) { size_t readlen = at_most - total_read;

1 0

[tor/master] Merge branch 'bug32673_035'
by nickm＠torproject.org 30 Jan '20

30 Jan '20

commit af76b9dcc6dd24d2dac2c8710386af86f0c50822 Merge: 9ea0c0bfc 2985a6018 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Jan 30 09:58:23 2020 -0500 Merge branch 'bug32673_035' changes/bug32673 | 5 +++++ src/lib/tls/buffers_tls.c | 4 ++-- 2 files changed, 7 insertions(+), 2 deletions(-)

1 0

[tor/master] Change BUG() messages in buf_flush_to_tls() to IF_BUG_ONCE()
by nickm＠torproject.org 30 Jan '20

30 Jan '20

commit 1f163fcbde4591bcb5764d6bbe0fea8aa559fc33 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Jan 29 08:31:22 2020 -0500 Change BUG() messages in buf_flush_to_tls() to IF_BUG_ONCE() We introduced these BUG() checks in b0ddaac07428a06 to prevent a recurrence of bug 23690. But there's a report of the BUG() message getting triggered and filling up the disk. Let's change it to IF_BUG_ONCE(). Fixes bug 33093; bugfix on 0.3.2.2-alpha. --- changes/bug33093_logging | 5 +++++ src/lib/tls/buffers_tls.c | 4 ++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/changes/bug33093_logging b/changes/bug33093_logging new file mode 100644 index 000000000..e26e4a64a --- /dev/null +++ b/changes/bug33093_logging @@ -0,0 +1,5 @@ + o Minor bugfixes (logging): + - If we encounter a bug when flushing a buffer to a TLS connection, + only log the bug once per invocation of the Tor process. Previously we + would log with every occurrence, which could cause us to run out of + disk space. Fixes bug 33093; bugfix on 0.3.2.2-alpha. diff --git a/src/lib/tls/buffers_tls.c b/src/lib/tls/buffers_tls.c index e92cb9163..b570216df 100644 --- a/src/lib/tls/buffers_tls.c +++ b/src/lib/tls/buffers_tls.c @@ -146,10 +146,10 @@ buf_flush_to_tls(buf_t *buf, tor_tls_t *tls, size_t flushlen, size_t flushed = 0; ssize_t sz; tor_assert(buf_flushlen); - if (BUG(*buf_flushlen > buf->datalen)) { + IF_BUG_ONCE(*buf_flushlen > buf->datalen) { *buf_flushlen = buf->datalen; } - if (BUG(flushlen > *buf_flushlen)) { + IF_BUG_ONCE(flushlen > *buf_flushlen) { flushlen = *buf_flushlen; } sz = (ssize_t) flushlen;

1 0

[tor/master] Merge branch 'bug33093_logging_035'
by nickm＠torproject.org 30 Jan '20

30 Jan '20

commit 9ea0c0bfcdbed7734f49f20a032da7f978b48ad4 Merge: 39c5e1b84 1f163fcbd Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Jan 30 09:55:40 2020 -0500 Merge branch 'bug33093_logging_035' changes/bug33093_logging | 5 +++++ src/lib/tls/buffers_tls.c | 4 ++-- 2 files changed, 7 insertions(+), 2 deletions(-)

1 0

[community/master] Fix template tags and homepage for gsoc
by hiro＠torproject.org 30 Jan '20

30 Jan '20

commit c7e7da927b6f8ff8e8b8359f230b0047da0421e0 Author: hiro <hiro(a)torproject.org> Date: Thu Jan 30 15:42:56 2020 +0100 Fix template tags and homepage for gsoc --- content/gsoc/cloudflare-captcha-monitoring/contents.lr | 3 ++- content/gsoc/contents.lr | 2 ++ content/gsoc/onion-toolbox/contents.lr | 5 ++++- content/gsoc/privacy-friendly-web/contents.lr | 6 +++++- content/gsoc/tor-relay-ipv6-support/contents.lr | 3 ++- content/gsoc/tor-weather/contents.lr | 3 ++- lego | 2 +- models/project.ini | 6 +++--- templates/home.html | 2 +- templates/macros/projects.html | 4 +++- templates/project.html | 4 ++-- 11 files changed, 27 insertions(+), 13 deletions(-) diff --git a/content/gsoc/cloudflare-captcha-monitoring/contents.lr b/content/gsoc/cloudflare-captcha-monitoring/contents.lr index e5b71a5..2263ecc 100644 --- a/content/gsoc/cloudflare-captcha-monitoring/contents.lr +++ b/content/gsoc/cloudflare-captcha-monitoring/contents.lr @@ -14,7 +14,8 @@ color: primary --- key: 1 --- -languages: javascript +languages: +javascript --- mentors: arma, gk --- diff --git a/content/gsoc/contents.lr b/content/gsoc/contents.lr index 1e973f0..25d1562 100644 --- a/content/gsoc/contents.lr +++ b/content/gsoc/contents.lr @@ -1,5 +1,7 @@ _template: layout.html --- +_undiscoverable: true +--- section: GSoC --- section_id: gsoc diff --git a/content/gsoc/onion-toolbox/contents.lr b/content/gsoc/onion-toolbox/contents.lr index b9f50bc..7968f31 100644 --- a/content/gsoc/onion-toolbox/contents.lr +++ b/content/gsoc/onion-toolbox/contents.lr @@ -14,7 +14,10 @@ color: primary --- key: 1 --- -languages: Python, Docker, PythonQt5 +languages: +Python +Docker +PythonQt5 --- mentors: hiro, asn --- diff --git a/content/gsoc/privacy-friendly-web/contents.lr b/content/gsoc/privacy-friendly-web/contents.lr index be886de..fb32b0f 100644 --- a/content/gsoc/privacy-friendly-web/contents.lr +++ b/content/gsoc/privacy-friendly-web/contents.lr @@ -14,7 +14,11 @@ color: primary --- key: 1 --- -languages: javascript, CSS, HTML, Python +languages: +javascript +CSS +HTML +Python --- mentors: hiro --- diff --git a/content/gsoc/tor-relay-ipv6-support/contents.lr b/content/gsoc/tor-relay-ipv6-support/contents.lr index 3b0cd0f..1300b87 100644 --- a/content/gsoc/tor-relay-ipv6-support/contents.lr +++ b/content/gsoc/tor-relay-ipv6-support/contents.lr @@ -14,7 +14,8 @@ color: primary --- key: 1 --- -languages: C +languages: +C --- mentors: teor, ahf, dgoulet, catalyst --- diff --git a/content/gsoc/tor-weather/contents.lr b/content/gsoc/tor-weather/contents.lr index 95aa94a..0c69dec 100644 --- a/content/gsoc/tor-weather/contents.lr +++ b/content/gsoc/tor-weather/contents.lr @@ -14,7 +14,8 @@ color: primary --- key: 2 --- -languages: TBD +languages: +TBD --- mentors: karsten --- diff --git a/lego b/lego index f0ea955..e9dd081 160000 --- a/lego +++ b/lego @@ -1 +1 @@ -Subproject commit f0ea955c50f147813fd7735d226e7f4689e94523 +Subproject commit e9dd081027132aa21f6abd74be708323ff3b9180 diff --git a/models/project.ini b/models/project.ini index 2ee985e..17c3260 100644 --- a/models/project.ini +++ b/models/project.ini @@ -15,7 +15,7 @@ label = Active type = boolean [fields.subtitle] -label = Summary +label = Subtitle type = markdown [fields.color] @@ -23,7 +23,7 @@ label = Color type = string [fields.body] -label = Description +label = body type = markdown [fields.mentors] @@ -32,7 +32,7 @@ type = string [fields.languages] label = Languages -type = string +type = strings [fields.mentors] label = Mentors diff --git a/templates/home.html b/templates/home.html index 8b6f12f..08d04c9 100644 --- a/templates/home.html +++ b/templates/home.html @@ -7,7 +7,7 @@ <section> <div class="container"> <div class="row"> - {% for child in this.children|sort(attribute='key') %} + {% for child in site.query('/').filter(F.section_id != 'gsoc')|sort(attribute='key') %} <div class="col-sm-6 col-md-4 col-sm-12 col-xl-4 py-4"> <div class="card h-100 p-2"> <div class="card-body"> diff --git a/templates/macros/projects.html b/templates/macros/projects.html index 8f26811..d4da228 100644 --- a/templates/macros/projects.html +++ b/templates/macros/projects.html @@ -4,7 +4,9 @@ <h5 class="mb-0"> <a href="{{ item.path|url }}">{{ item.title }}</a> </h5> - <span class="badge badge-primary">{{ item.languages }}</span> + {% for lang in item.languages %} + <span class="badge badge-primary">{{ lang }}</span> + {% endfor %} </div> <div> <div class="card-body"> diff --git a/templates/project.html b/templates/project.html index 1aaed71..f9c5623 100644 --- a/templates/project.html +++ b/templates/project.html @@ -17,13 +17,13 @@ <div class="container py-3 mt-5"> <h4>Project Summary:</h4> <p> - {{ this.summary }} + {{ this.subtitle }} </p> </div> <div class="container py-3"> <h4>Project Description:</h4> <p> - {{ this.description }} + {{ this.body }} </p> </div> <div class="container py-3">

1 0

[community/master] Add Project Ideas for GSoC to Community Portal
by pili＠torproject.org 30 Jan '20

30 Jan '20

commit de6de2744026f461739e41fb790176f5a624dd97 Author: Pili Guerra <pili(a)piliguerra.com> Date: Wed Jan 22 13:04:16 2020 +0100 Add Project Ideas for GSoC to Community Portal Fix gosc template and contents files Change contents files for a few projects Fix gsoc template --- .../gsoc/cloudflare-captcha-monitoring/contents.lr | 49 ++++++++++++ content/gsoc/contents.lr | 21 +++++ content/gsoc/onion-toolbox/contents.lr | 60 +++++++++++++++ content/gsoc/privacy-friendly-web/contents.lr | 45 +++++++++++ content/gsoc/tor-relay-ipv6-support/contents.lr | 58 ++++++++++++++ content/gsoc/tor-weather/contents.lr | 90 ++++++++++++++++++++++ models/project.ini | 51 ++++++++++++ models/projects.ini | 33 ++++++++ templates/gsoc.html | 24 ++++++ templates/macros/projects.html | 16 ++++ templates/project.html | 49 ++++++++++++ 11 files changed, 496 insertions(+) diff --git a/content/gsoc/cloudflare-captcha-monitoring/contents.lr b/content/gsoc/cloudflare-captcha-monitoring/contents.lr new file mode 100644 index 0000000..e5b71a5 --- /dev/null +++ b/content/gsoc/cloudflare-captcha-monitoring/contents.lr @@ -0,0 +1,49 @@ +_model: project +--- +_template: layout.html +--- +html: two-columns-page.html +--- +active: True +--- +section: GSoC +--- +section_id: gsoc +--- +color: primary +--- +key: 1 +--- +languages: javascript +--- +mentors: arma, gk +--- +difficulty: medium +--- +title: Cloudflare Captcha Monitoring +--- +subtitle: + +We should track the rate that cloudflare gives captchas to Tor users over time. + +--- +body: + +My suggested way of doing that tracking is to sign up a very simple static webpage to be fronted by cloudflare, and then fetch it via Tor over time, and record and graph the rates of getting a captcha vs getting the real page. + +The reason for the "simple static page" is to make it really easy to distinguish whether we're getting hit with a captcha. The "distinguishing one dynamic web page from another" challenge makes exitmap tricky in the general case, but we can remove that variable here. + +One catch is that Cloudflare currently gives alt-svc headers in response to fetches from Tor addresses. So that means we need a web client that can follow alt-srv headers -- maybe we need a full Selenium like client? + +Once we get the infrastructure set up, we would be smart to run a second one which is just wget or curl or lynx or something, i.e. which doesn't behave like Tor Browser, in order to be able to track the difference between how Cloudflare responds to Tor Browser vs other browsers. + +I imagine that Cloudflare should be internally tracking how they're handling Tor requests, but having a public tracker (a) gives the data to everybody, and (b) helps Cloudflare have a second opinion in case their internal data diverges from the public version. + +The Berkeley ICSI group did research that included this sort of check: +https://www.freehaven.net/anonbib/#differential-ndss2016 +https://www.freehaven.net/anonbib/#exit-blocking2017 +but what I have in mind here is essentially a simpler subset of this research, skipping the complicated part of "how do you tell what kind of response you got" and with an emphasis on automation and consistency. + +There are two interesting metrics to track over time: one is the fraction of exit relays that are getting hit with captchas, and the other is the chance that a Tor client, choosing an exit relay in the normal weighted faction, will get hit by a captcha. + +Then there are other interesting patterns to look for, e.g. "are certain IP addresses punished consistently and others never punished, or is whether you get a captcha much more probabilistic and transient?" And does that pattern change over time? diff --git a/content/gsoc/contents.lr b/content/gsoc/contents.lr new file mode 100644 index 0000000..1e973f0 --- /dev/null +++ b/content/gsoc/contents.lr @@ -0,0 +1,21 @@ +_template: layout.html +--- +section: GSoC +--- +section_id: gsoc +--- +html: gsoc.html +--- +color: primary +--- +subtitle: Some projects ideas for GSoC. +--- +cta: Get coding +--- +key: 0 +--- +title: Project Ideas +--- +body: + +You may find some of these projects to be good ideas for Google Summer of Code. We have labelled each idea with which of our core developers would be good mentors. If one or more of these ideas looks promising to you, please contact us to discuss your plans rather than sending blind applications. diff --git a/content/gsoc/onion-toolbox/contents.lr b/content/gsoc/onion-toolbox/contents.lr new file mode 100644 index 0000000..b9f50bc --- /dev/null +++ b/content/gsoc/onion-toolbox/contents.lr @@ -0,0 +1,60 @@ +_model: project +--- +_template: layout.html +--- +html: two-columns-page.html +--- +active: True +--- +section: GSoC +--- +section_id: gsoc +--- +color: primary +--- +key: 1 +--- +languages: Python, Docker, PythonQt5 +--- +mentors: hiro, asn +--- +difficulty: medium +--- +title: Onion Tool Box +--- +subtitle: + +Myonion is a developer tool box, providing a command line interface and a GUI to configure and deploy existing services via .onion. A minimal prototype for myonion already [exists](https://github.com/hiromipaw/myonion). + +Someone that may want to run an onion service can use the myonion wrapper app to start a .onion from their computer and sharea static website or a web application. + +Myonion can also be used to deploy the resulting configured app to a defined set of cloud providers. + +--- +body: + +## Problem definition + +It is not necessarily difficult to use onion services, but it might be tricky to configure a web service to be offered via .onion so that it doesn’t leak sensitive information. + +There are detailed [guides](https://riseup.net/en/security/network-security/tor/onionservices-b… available for users that would like to offer a web application via .onion and some tools have been developed to help service operators: discover known misconfiguration or [vulnerabilities](https://onionscan.org/) or deploy an [onion site](https://github.com/alecmuffett/eotk). + +## Scope + +Myonion provides a way to build and deploy onion ready applications, allowing developers to build and test web applications and easily share them with others, bundling the code and configuration in a lightweight, portable Docker container application that runs thesame everywhere. + +The experience for developers will be similar to using other industry solutions, like the [Docker desktop app](https://www.docker.com/products/docker-desktop). + +Developers using myonion are provided with pre-defined and customizable application templates, with corresponding configuration and a test set, eliminating error-prone manual setup and known onion service configuration mistakes. + +The resulting application is therefore deployable via a set of endpoint management tools to known providers. Providing a way to deploy onion services at scale. + +## Impact + +The idea behind myonion is to make onion services accessible to developers that might be interested to innovate in the privacy space, building applications that are designed for privacy and security. + +Involving a wider developer community can help creating a better image of Tor and onion services, replacing the “dark net” narrative with the secure and private web one. + +Onion services can also be relevant to all those people interested in the “zero-trust” strategy. The concept behind zero-trust is to adopt strategies and tools to help prevent data breaches by eliminating the concept of trust from an organization’s network architecture, with the principle of never trust, always verify. + +Ultimately myonion is about creating a better experience for onion services developers and operators and therefore fostering a more legitimate onion service ecosystem. diff --git a/content/gsoc/privacy-friendly-web/contents.lr b/content/gsoc/privacy-friendly-web/contents.lr new file mode 100644 index 0000000..be886de --- /dev/null +++ b/content/gsoc/privacy-friendly-web/contents.lr @@ -0,0 +1,45 @@ +_model: project +--- +_template: layout.html +--- +html: two-columns-page.html +--- +active: True +--- +section: GSoC +--- +section_id: gsoc +--- +color: primary +--- +key: 1 +--- +languages: javascript, CSS, HTML, Python +--- +mentors: hiro +--- +difficulty: medium +--- +title: Privacy Friendly Web +--- +subtitle: + +The scope of this project is creating a open-source community-driven browsable list of patterns and release a css/js framework that web developers can extend and use in their work. +--- +body: + +Security concerned web users take conscious steps to limit the amount of data they share with the websites visited and third party services. + +There are a number of security enhancing tools available. Some come in the form of browser extensions and javascript blockers, others are full fledged web browsers designed with providing extra security to their users. + +One of this is the Tor Browser. The Tor Browser was designed to provide privacy while surfing the web and defend users against both network and local forensic adversaries. There are two main categories of requirements that have been considered: Security Requirements, and Privacy Requirements. + +Security Requirements are the minimum properties in order for a browser to be able to support Tor and similar privacy proxies safely. Privacy requirements are primarily concerned with reducing linkability: the ability for a user's activity on one site to be linked with their activity on another site without their knowledge or explicit consent. + +Websites can work seamsly with the Tor Browser and other privacy enhancing browsers and tools if they adopt a series of respectful and ethical patterns. + +The Tor Browser is in fact, based on Mozilla's Extended Support Release (ESR) Firefox branch. We have a series of patches against this browser to enhance privacy and security. Browser behavior is additionally augmented through the Torbutton extension, and we also change a number of Firefox preferences from their defaults. + +The Tor Project has developed over the years a set of web development guidelines that allow websites to work with security enhanced browsers without causing any or minimal functionality destruption to their users. These guidelines have been shaped in an internal styleguide that has been adopted across all torproject.org websites. + +We are now formalizing these web development patterns and some security concerns that need to be considered when developing websites for users surfing the web with security enhanced browsers and tools. diff --git a/content/gsoc/tor-relay-ipv6-support/contents.lr b/content/gsoc/tor-relay-ipv6-support/contents.lr new file mode 100644 index 0000000..3b0cd0f --- /dev/null +++ b/content/gsoc/tor-relay-ipv6-support/contents.lr @@ -0,0 +1,58 @@ +_model: project +--- +_template: layout.html +--- +html: two-columns-page.html +--- +active: True +--- +section: GSoC +--- +section_id: gsoc +--- +color: primary +--- +key: 1 +--- +languages: C +--- +mentors: teor, ahf, dgoulet, catalyst +--- +difficulty: Medium +--- +title: Improve Tor Relay IPv6 Support +--- +subtitle: + +Tor helps people stay safe on the internet, by keeping their internet use secure and anonymous. More Tor clients are running on IPv6-only or dual-stack networks. But only 20% of Tor’s available relay bandwidth supports IPv6. We want to automate relay IPv6 address discovery and reachability checks, so that it is easier for relay operators to run IPv6 relays. + +--- +body: + +Students may choose to focus on designing and implementing core features, tor relay testing, reporting statistics, or diagnosing and fixing bugs. + + +## Prerequisites + +* Network configuration skills +* Basic understanding of Internet Protocol (IP) versions + +Recommended: + +* Experience testing network software +* Experience running Internet-connected servers + +## Links/Resources + +https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#IPv6 + +https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6Features#ReachabilityChecks + +## Programming skills needed: + +* C coding +* Building Unix-based software + +Recommended: + +* Experience with network programming diff --git a/content/gsoc/tor-weather/contents.lr b/content/gsoc/tor-weather/contents.lr new file mode 100644 index 0000000..95aa94a --- /dev/null +++ b/content/gsoc/tor-weather/contents.lr @@ -0,0 +1,90 @@ +_model: project +--- +_template: layout.html +--- +html: two-columns-page.html +--- +active: True +--- +section: GSoC +--- +section_id: gsoc +--- +color: primary +--- +key: 2 +--- +languages: TBD +--- +mentors: karsten +--- +difficulty: medium +--- +title: Tor Weather +--- +subtitle: + +Tor Weather is the most efficient way to achieve and maintain a healthy Tor network on the long run. + +--- +body: + +Tor Weather was [discontinued on 2016-04-04](https://lists.torproject.org/pipermail/tor-relays/2016-April/00…, however "Tor Weather is still a good idea, it just needs somebody to implement it." + +How Tor Weather looked like: +https://web.archive.org/web/20141004055709/https://weather.torproject.org/subscribe/ + +## Motivation + +If a relay disappears today, it is unlikely that anyone will notice or even send an email to the operator unless it is a big one. + +Relay operators and the entire tor network would benefit from a Tor Weather service because it notifies relay operators when the state of their relays changed (and more). This will increase the likelihood that relay operators notice problems and actually mitigate the problem otherwise there is no "user feedback" since tor can cope with disappearing relays quite well. + +It also: +- shows the relay operator that someone actually cares if their relays go down or become outdated or have another problem +- gives the operator relay best-practices information. + +## Expected Effects + +If enough operators subscribe to such a service: +- relays might become more long lived / the churn rate might decrease +- the fraction of relays running outdated tor versions might decrease +- the fraction of exits with broken DNS might decrease + +It also has the benefit of being able to contact relay operators: +- completely automatically +- even if they choose to not set a public ContactInfo string in their torrc files. + +## Ideas for Notification Types + +_(sorted by importance)_ + +Support subscribing via single relay FP or MyFamily groups (should not need any subscription change if a relay gets added to the family). + +- [ ] Email me when my node is down +_How long before we send a notification?_ +- [ ] email me when my relay is affected by a security vulnerability +- [ ] email me when my relay runs an end-of-life version of tor +- [ ] email me when my relay runs an outdated tor version (note: this should depend on the related onionoo bugs to avoid emailing alpha relay people) +- [ ] email me when my exit relay fails to resolve hostnames (DNS failure) +- [ ] email me when my relay looses the [ ] stable, [ ] guard, [ ] exit flag +- [ ] email me when my MyFamily configuration is broken (meaning: non-mutual config detected or relay with same contactInfo but no MyFamily) +- [ ] email me when you detect issues with my relay +- [ ] email me with suggestions for configuration improvements for my relay (only once per improvement) +- [ ] email me when my relay is on the top [ ] 20 [ ] 50 [ ] 100 relays list +- [ ] email me with monthly/quarterly status information that includes information like what my position in the overall relay list is (sorted by CW), how much traffic my relay did during the last month and what fraction of the months time your relay was included in consensus as running (this shows information on how many % of the months' consensuses this relay has been included and running) +- [ ] aggregate emails for all my relays into a single digest email +- [ ] email me about new relay requirements +- [ ] email me about tor relay operator events + + +*Task:* Write a specification describing the meaning of each checkbox + +## Security and Privacy Implications + +The service stores email addresses of potential tor relay operators, they should be kept private and safeguarded, but a passive observer can collect them by watching outbound email traffic if no TLS is used. Suggest to use a dedicated email address for this service. + +## Additional Ideas + +- easy: integration into tor: show the URL pointing to the new Tor Weather service like the current link to the lifecycle blogpost when tor starts and detects to be a new relay +- Provide an uptimerobot-style status page for relay operators using onionoo data diff --git a/models/project.ini b/models/project.ini new file mode 100644 index 0000000..2ee985e --- /dev/null +++ b/models/project.ini @@ -0,0 +1,51 @@ +[model] +name = Project +label = {{ this.title }} + +[fields.title] +label = Title +type = string + +[fields.link] +label = Link +type = url + +[fields.active] +label = Active +type = boolean + +[fields.subtitle] +label = Summary +type = markdown + +[fields.color] +label = Color +type = string + +[fields.body] +label = Description +type = markdown + +[fields.mentors] +label = Mentors +type = string + +[fields.languages] +label = Languages +type = string + +[fields.mentors] +label = Mentors +type = string + +[fields.difficulty] +label = Difficulty Level +type = string + +[fields.html] +label = Html +type = string + +[fields.key] +label = key +type = string diff --git a/models/projects.ini b/models/projects.ini new file mode 100644 index 0000000..c09bf77 --- /dev/null +++ b/models/projects.ini @@ -0,0 +1,33 @@ +[model] +name = Projects +label = {{ this.title }} + +[fields.title] +label = Title +type = string + +[fields.section] +label = Section +type = string +translate = True + +[fields.section_id] +label = Section_id +type = string +translate = False + +[fields.body] +label = Body +type = markdown + +[fields.color] +label = Color +type = string + +[fields.html] +label = Html +type = string + +[children] +model = project +order_by = title diff --git a/templates/gsoc.html b/templates/gsoc.html new file mode 100644 index 0000000..15f388d --- /dev/null +++ b/templates/gsoc.html @@ -0,0 +1,24 @@ +<div class="container py-5"> + <div class="row py-5"> + <div class="col-lg-12"> + {{ this.body }} + </div> + </div> + <div class="col-12"> + {% from "macros/projects.html" import render_active %} + {% for child in this.children.filter(F.active == True).all() %} + <div class="row"> + {{ render_active(child, this.alt) }} + </div> + {% endfor %} + </div> + <div class="row"> + <ul> + {% for child in this.children.filter(F.active == False).all() %} + <li>{{ item.title }}</li> + {% endfor %} + </div> + <div class="row py-5 text-center mx-auto"> + <p class="text-center">{{ _('None of these ideas seem appealing? You may also want to propose your own project idea — which often results in the best projects.') }} <a href="mailto:gso@torproject.org">{{ _('We invite you to contact us to discuss your own project idea.') }}</a></p> + </div> +</div> diff --git a/templates/macros/projects.html b/templates/macros/projects.html new file mode 100644 index 0000000..8f26811 --- /dev/null +++ b/templates/macros/projects.html @@ -0,0 +1,16 @@ +{% macro render_active(item, alternative) %} +<div class="card border-0"> + <div class="card-header bg-white border-0" id="headingOne"> + <h5 class="mb-0"> + <a href="{{ item.path|url }}">{{ item.title }}</a> + </h5> + <span class="badge badge-primary">{{ item.languages }}</span> + </div> + <div> + <div class="card-body"> + {{ item.summary }} + <a href="{{ item.path|url }}">{{ _('Read more.') }}</a> + </div> + </div> +</div> +{% endmacro %} diff --git a/templates/project.html b/templates/project.html new file mode 100644 index 0000000..1aaed71 --- /dev/null +++ b/templates/project.html @@ -0,0 +1,49 @@ +<!doctype html> +{% include 'meta.html' %} +<body class="no-gutters"> + <header> + {% include 'navbar.html' %} + </header> + <div class="page"> + {% include 'header.html' %} + {% include 'pagenav.html' %} + <div class="container-fluid"> + <div class="row flex-xl-nowrap"> + <main role="main" class="mx-auto col-12 {{ bag('alternatives', this.alt, 'order') }}"> + <div class="container py-3 mt-5"> + <h4>Project Title: {{ this.title }}</h4> + <span class="badge badge-primary">{{ this.languages }}</span> <span class="badge badge-secondary">{{ this.difficulty }}</span> + </div> + <div class="container py-3 mt-5"> + <h4>Project Summary:</h4> + <p> + {{ this.summary }} + </p> + </div> + <div class="container py-3"> + <h4>Project Description:</h4> + <p> + {{ this.description }} + </p> + </div> + <div class="container py-3"> + <h4>Mentors:</h4> + <p> + {{ this.mentors }} + </p> + </div> + </main> + </div> + <div class="card mt-5"> + <ul class="list-group list-group-flush"> + <li class="list-group-item"> + <a href="{{ this.parent|url }}">{{ _("Back to ") }}{{ this.parent.title }}</a> + </li> + </ul> + </div> + </div> +</div> +<footer> + {% include 'footer.html' %} +</footer> +</body>

1 0

[tor-browser-build/master] Merge remote-tracking branch 'gk/bug_32700'
by boklm＠torproject.org 30 Jan '20

30 Jan '20

commit b1690c3404c0454cb805a01e94e7d45e74ad17e0 Merge: 4e682a9 40502c9 Author: Nicolas Vigier <boklm(a)torproject.org> Date: Thu Jan 30 14:14:09 2020 +0100 Merge remote-tracking branch 'gk/bug_32700' projects/firefox/mozconfig-windows-i686 | 1 - projects/firefox/mozconfig-windows-x86_64 | 1 - 2 files changed, 2 deletions(-)

1 0

[tor-browser-build/master] Bug 32700: Don't disable GeckoDriver separately
by boklm＠torproject.org 30 Jan '20

30 Jan '20

commit 40502c9d0abb4e2c6b732162536fd2ea26bfe35b Author: Georg Koppen <gk(a)torproject.org> Date: Mon Dec 9 07:46:12 2019 +0000 Bug 32700: Don't disable GeckoDriver separately --- projects/firefox/mozconfig-windows-i686 | 1 - projects/firefox/mozconfig-windows-x86_64 | 1 - 2 files changed, 2 deletions(-) diff --git a/projects/firefox/mozconfig-windows-i686 b/projects/firefox/mozconfig-windows-i686 index fe3cc7d..4fd9958 100644 --- a/projects/firefox/mozconfig-windows-i686 +++ b/projects/firefox/mozconfig-windows-i686 @@ -38,7 +38,6 @@ ac_add_options --disable-maintenance-service ac_add_options --enable-proxy-bypass-protection ac_add_options --disable-webrtc # Bug 1393901 ac_add_options --disable-tests -ac_add_options --disable-geckodriver # Bug 1489320 # Disable telemetry ac_add_options MOZ_TELEMETRY_REPORTING= diff --git a/projects/firefox/mozconfig-windows-x86_64 b/projects/firefox/mozconfig-windows-x86_64 index ef28c9b..ae5cf67 100644 --- a/projects/firefox/mozconfig-windows-x86_64 +++ b/projects/firefox/mozconfig-windows-x86_64 @@ -38,7 +38,6 @@ ac_add_options --disable-maintenance-service ac_add_options --enable-proxy-bypass-protection ac_add_options --disable-webrtc # Bug 1393901 ac_add_options --disable-tests -ac_add_options --disable-geckodriver # Bug 1489320 # Disable telemetry ac_add_options MOZ_TELEMETRY_REPORTING=

1 0

[tor-browser-build/master] Bug 27903: Isolate Tor Browser from dconf-service
by boklm＠torproject.org 30 Jan '20

30 Jan '20

commit 4e682a909ec2af4c0452934446392f7ff918d8d1 Author: cypherpunks <cypherpunks(a)torproject.org> Date: Thu Jan 30 13:52:50 2020 +0100 Bug 27903: Isolate Tor Browser from dconf-service --- projects/tor-browser/RelativeLink/start-tor-browser | 3 +++ 1 file changed, 3 insertions(+) diff --git a/projects/tor-browser/RelativeLink/start-tor-browser b/projects/tor-browser/RelativeLink/start-tor-browser index 9356d4c..624bb3c 100755 --- a/projects/tor-browser/RelativeLink/start-tor-browser +++ b/projects/tor-browser/RelativeLink/start-tor-browser @@ -346,6 +346,9 @@ setControlPortPasswd ${TOR_CONTROL_PASSWD:='"secret"'} export FONTCONFIG_PATH="${HOME}/TorBrowser/Data/fontconfig" export FONTCONFIG_FILE="fonts.conf" +# Avoid overwriting user's dconf values. Fixes #27903. +export GSETTINGS_BACKEND=memory + cd "${HOME}" # We pass all additional command-line arguments we get to Firefox.

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
160
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits January 2020