Re: [tor-bugs] #25604 [Core Tor]: V3 onion is critically unreliable since latest Tor update.

[Tor Bug Tracker & Wiki]

#25604: V3 onion is critically unreliable since latest Tor update.
-+---
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  needs_information
 Priority:  Very High|  Milestone:
Component:  Core Tor |Version:
 Severity:  Critical | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by Dbryrtfbcbhgf):

 * status:  new => needs_information


Comment:

 Please provide a log or a more detailed explanation of your problem, you
 can remove all personal information from the log before you posted.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25605 [Core Tor/Tor]: Add tests for Rust protover::compute_for_old_tor() and C functions it calls (was: Rust protover::compute_for_old_tor() always says the version is newer than 0.2.9

[Tor Bug Tracker & Wiki]

#25605: Add tests for Rust protover::compute_for_old_tor() and C functions it 
calls
+
 Reporter:  isis|  Owner:  isis
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.3.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  033-must, fast-fix  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:  Sponsor8-can
+
Changes (by isis):

 * status:  assigned => needs_review


Comment:

 Okay the tests are in my `bug25605` branch. I'll need to rebase that
 branch once #25386 is merged.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25605 [Core Tor/Tor]: Rust protover::compute_for_old_tor() always says the version is newer than 0.2.9.3-alpha

[Tor Bug Tracker & Wiki]

#25605: Rust protover::compute_for_old_tor() always says the version is newer 
than
0.2.9.3-alpha
+
 Reporter:  isis|  Owner:  isis
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.3.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  033-must, fast-fix  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:  Sponsor8-can
+
Changes (by isis):

 * priority:  High => Medium


Comment:

 O, actually this is just a problem in the test code, this function is
 behaving as we expect it to in C. So the fix is to have the tests call it
 like this `protover::compute_for_old_tor("Tor 0.2.4.20")` instead. I wrote
 some tests for the C in the process.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20283 [Applications/Tor Browser]: Tor Browser should run without a `/proc` filesystem.

[Tor Bug Tracker & Wiki]

#20283: Tor Browser should run without a `/proc` filesystem.
--+---
 Reporter:  yawning   |  Owner:  pospeselr
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-sandboxing|  Actual Points:
Parent ID:  #20773| Points:
 Reviewer:|Sponsor:
--+---

Comment (by yawning):

 > Note that there may be other horrific things that happen

 The content process will SIGSEGV on JS heavy pages if
 `pthread_attr_getstack()` returns a `NULL` `stackaddr`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25154 [Applications/Tor Browser Sandbox]: Tab crashing in sandboxed 8.0a1, sandbox 0.0.16, linux x86_64

[Tor Bug Tracker & Wiki]

#25154: Tab crashing in sandboxed 8.0a1, sandbox 0.0.16, linux x86_64
--+-
 Reporter:  ln5   |  Owner:  yawning
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by yawning):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 >  Is this just #25540-come-early

 That's what a sensible person would do.

 > or is this a little simple bug that should be found and squashed? :)

 https://gitweb.torproject.org/tor-browser/sandboxed-tor-
 browser.git/commit/?id=bec4340f2083dcc5779859cee26d6809f7def083

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25566 [Applications/Tor Browser]: Include or add an option to close connection to Cloudflare.

[Tor Bug Tracker & Wiki]

#25566: Include or add an option to close connection to Cloudflare.
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  project  | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare,mozilla |
Parent ID:  #18361   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * status:  closed => reopened
 * resolution:  duplicate =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25386 [Core Tor/Tor]: fix rust tests

[Tor Bug Tracker & Wiki]

#25386: fix rust tests
-+-
 Reporter:  Hello71  |  Owner:  Hello71
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-test, 033-backport,|  Actual Points:
  review-group-34|
Parent ID:   | Points:  3
 Reviewer:  isis |Sponsor:
 |  Sponsor8-can
-+-

Comment (by isis):

 Oh, also this needs a changes file. I can add that, if you like.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25605 [Core Tor/Tor]: Rust protover::compute_for_old_tor() always says the version is newer than 0.2.9.3-alpha

[Tor Bug Tracker & Wiki]

#25605: Rust protover::compute_for_old_tor() always says the version is newer 
than
0.2.9.3-alpha
--+
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Normal|   Keywords:  033-must, fast-fix
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:  Sponsor8-can  |
--+
 In https://trac.torproject.org/projects/tor/ticket/25386#comment:21, after
 changing/adding some tests, I noticed that
 `protover::compute_for_old_tor()` always returns an empty string, meaning
 that the version we parsed is new enough that the router should be
 reporting its own protocol versions. It's because the Rust code is calling
 the C version of `tor_version_as_new_as()`, which expects a ''platform
 string'', not a version, so it gets to `tor_version_parse_platform()`,
 decides this is a "non-standard tor" and returns true early. So, in the
 top of the Rust function `protover::compute_for_old_tor()`, when we call
 `tor_version_as_new_as(version, FIRST_TOR_VERSION_TO_ADVERTISE_PROTOCOLS)`
 it says true, and we never reach the rest of the function.

 The solution is to prepend `"Tor "` to each of the query strings in
 `protover::compute_for_old_tor()`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25386 [Core Tor/Tor]: fix rust tests

[Tor Bug Tracker & Wiki]

#25386: fix rust tests
-+-
 Reporter:  Hello71  |  Owner:  Hello71
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-test, 033-backport,|  Actual Points:
  review-group-34|
Parent ID:   | Points:  3
 Reviewer:  isis |Sponsor:
 |  Sponsor8-can
-+-
Changes (by isis):

 * status:  needs_review => merge_ready


Comment:

 Hi, this looks great! Thanks!

 Just one tiny thing: when you squash, please remove commit
 f7b714ba411eb7ccdfcafe676df28f81bb823b57, as it breaks out-of-directory
 builds. (It should be `$abs_top_srcdir` in that line, since the
 test_rust.sh script doesn't get copied to the build dir.)

 I added a commit on top in my `bug25386_v2` branch, which changed the test
 you added to actually check the functionality of
 `protover::compute_for_old_tor`, and found a bug (#XXX), so this is pretty
 cool.

 I recommend merging whenever Hello71 squashes, and then I'll put the tests
 I made/changed in #XXX.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25604 [Core Tor]: V3 onion is critically unreliable since latest Tor update.

[Tor Bug Tracker & Wiki]

#25604: V3 onion is critically unreliable since latest Tor update.
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Core Tor |Version:
 Severity:  Critical |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
-+
 I am hosting V2 and V3 onion and V2 onion is way reliable than V3. What is
 going on? SHould I recreate V3 onion?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25560 [Core Tor/Tor]: test all rust crates for realsies

[Tor Bug Tracker & Wiki]

#25560: test all rust crates for realsies
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  defect   | Status:  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-testing, rust, 033-must  |  Actual Points:
Parent ID:   | Points:  .2
 Reviewer:  nickm|Sponsor:  SponsorM-can
-+-

Comment (by isis):

 Okay, quoting directories is actually fixed now, I think.  Surprisingly,
 building in directories with spaces in their names was/is already broken,
 because `src/test/include.am` does this:

 {{{
 test-rust:
 $(TESTS_ENVIRONMENT) $(abs_top_srcdir)/src/test/test_rust.sh
 }}}

 which for me expanded to:

 {{{
 export PYTHON="python"; export SHELL="/bin/bash"; export
 abs_top_srcdir="/home/isis/code/torproject/foo bar/../tor"; export
 abs_top_builddir="/home/isis/code/torproject/foo bar"; export
 builddir="."; export TESTING_TOR_BINARY="./src/or/tor"; export
 CARGO="cargo"; export CARGO_ONLINE=""; /home/isis/code/torproject/foo
 bar/../tor/src/test/test_rust.sh
 }}}

 So I've quoted it in the Makefile as well and everything seems to work
 now.

 Let me know if you want me to squash first.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25341 [Core Tor/Tor]: Remove now-unnecessary Rust linking workaround

[Tor Bug Tracker & Wiki]

#25341: Remove now-unnecessary Rust linking workaround
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-build, autoconf, review-   |  Actual Points:
  group-34   |
Parent ID:   | Points:  .1
 Reviewer:  catalyst |Sponsor:
-+-

Comment (by isis):

 catalyst is totally right, I just checked in my copy of the rust repo and
 it's in the current `beta`, which I think means we have to defer this
 until 1.25 is stable.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25603 [Applications/Tor Browser]: Update Orfox HTTPS-E Add-on

[Tor Bug Tracker & Wiki]

#25603: Update Orfox HTTPS-E Add-on
--+
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-mobile
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Orfox bundles NoScript and HTTPS-Everywhere as distribution extensions.
 The HTTPS-E version is old. Orfox contains NoScript Anywhere (NSA) 3.5a15,
 but it seems like this is still the latest version. We'll start using
 NoScript when we start using the WebExtensions version.

 Orfox uses HTTPS-Everywhere 5.2.20, so (at a minumum) we should bump this
 to 5.2.21 [0] (as gk mentioned in #19675 [1]). We should also test the
 WebExtensions version and decide if we should simply upgrade to version
 2018.3.13 (like Desktop).

 I think we should continue using the Orfox distribution, and we can move
 to a better solution during the rebase (and when we move to rbm).

 Orfox includes the tor-browser-settings [2] add-on, too, but that hasn't
 changed.

 [0] https://addons.mozilla.org/en-US/firefox/addon/https-
 everywhere/versions/?page=1#version-5.2.21
 [1] https://trac.torproject.org/projects/tor/ticket/19675#comment:20
 [2] https://git.synz.io/synzvato/tor-browser-settings.git

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25461 [Core Tor/Tor]: main event-loop spins consuming 100% of a CPU core at times

[Tor Bug Tracker & Wiki]

#25461: main event-loop spins consuming 100% of a CPU core at times
--+
 Reporter:  Dhalgren  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  performance   |  Actual Points:
Parent ID:  #25500| Points:
 Reviewer:|Sponsor:
--+

Comment (by Dhalgren):

 A theory randomly popped into my mind as to the possible cause:

 Use a Linux `tc` police rule to limit bandwidth on ingress and noticed the
 CPU saturation problem shows up, at least at times, when average ingress
 traffic is near the tc police limit but not in excess of it.  Probably
 packet discards from tc-police stalls many TCP connections in the middle
 of app-layer buffer deliveries.  Is it possible that libevent or a tor
 dameon handler spins when incomplete buffers are pending assembly rather
 than blocking?

 Did not investigate code--is just an idea.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25519 [Core Tor/Tor]: move away from asciidoc

[Tor Bug Tracker & Wiki]

#25519: move away from asciidoc
--+
 Reporter:  dkg   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by catalyst):

 From having used Sphinx elsewhere, I know its manpage output at least used
 to rely on groff features, so wouldn't work on plain nroff/troff.  Maybe
 we don't care, but it's something to be aware of.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25602 [Core Tor/Tor]: Fix two comment typos in hs_cell.c

[Tor Bug Tracker & Wiki]

#25602: Fix two comment typos in hs_cell.c
--+
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  merge_ready
 Priority:  Very Low  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Trivial   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+
Changes (by isis):

 * status:  assigned => merge_ready


Comment:

 {{{#!diff
 -   * make the adjustment to the encryptled_len to ommit the MAC length.
 */
 +   * make the adjustment to the encrypted_len to omit the MAC length. */
 }}}

 Fixed in my `bug25602` branch.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25602 [Core Tor/Tor]: Fix two comment typos in hs_cell.c

[Tor Bug Tracker & Wiki]

#25602: Fix two comment typos in hs_cell.c
--+
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  assigned
 Priority:  Very Low  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Trivial   |   Keywords:
Actual Points:|  Parent ID:
   Points:  .1|   Reviewer:
  Sponsor:|
--+


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24740 [Core Tor/Tor]: Tor launches two requests for authority certificates on first bootstrap

[Tor Bug Tracker & Wiki]

#24740: Tor launches two requests for authority certificates on first bootstrap
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-bootstrap, tor-bandwidth, easy,  |  Actual Points:
  intro, review-group-34 |
Parent ID:   | Points:  0.5
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8-can
-+-
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Code changes look good to me.  I haven't exhaustively analyzed it the way
 teor has, so I'll defer to their judgment about the strategy.

 I wish we had a way to automatically test for the intended behavior, but
 it seems difficult to write such a test given what I see of the existing
 code structure.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25519 [Core Tor/Tor]: move away from asciidoc

[Tor Bug Tracker & Wiki]

#25519: move away from asciidoc
--+
 Reporter:  dkg   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by atagar):

 Hi Nick, for what it's worth another option is reStructuredText. Sphinx
 generates html, man docs, and others...

 http://www.sphinx-doc.org/en/master/rest.html
 http://www.sphinx-doc.org/en/stable/man/sphinx-build.html

 This is what Stem and Nyx uses to generate their docs.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25520 [Metrics/Statistics]: Adapt webstats to read CollecTor provided logs

[Tor Bug Tracker & Wiki]

#25520: Adapt webstats to read CollecTor provided logs
+--
 Reporter:  iwakeh  |  Owner:  karsten
 Type:  enhancement | Status:  needs_review
 Priority:  High|  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+--
Changes (by karsten):

 * priority:  Medium => High
 * status:  accepted => needs_review
 * reviewer:   => iwakeh


Comment:

 Please review [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=task-25520=4ca4df91fcd05720ba717e0d96fb66f6229dd7cf
 commit 4ca4df9 from my task-25520 branch].

 Optimistically assigning iwakeh as reviewer. :)

 Setting priority to high, because I'd really like to cross this off the
 list by end of the month.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25519 [Core Tor/Tor]: move away from asciidoc

[Tor Bug Tracker & Wiki]

#25519: move away from asciidoc
--+
 Reporter:  dkg   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by catalyst):

 * cc: catalyst (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25582 [Core Tor/Tor]: Manual includes non-existant ExitPolicyDefault option

[Tor Bug Tracker & Wiki]

#25582: Manual includes non-existant ExitPolicyDefault option
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by atagar):

 Oh! Did a little more looking and it's not there to provide an anchor at
 all. Rather, it's a hack so the following text is formatted as a
 paragraph. This is discussed in #20885.

 Sure, reverting that line back to an anchor sounds good. Preferably with a
 comment above that, the SocksPortFlagsMisc, and ORPortFlagsExclusive (if
 they're still around) to explain that these are formatting hacks rather
 than intentional anchors.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21863 [Applications/Tor Browser]: Ensure proxy safety on Android (was: Ensure proxy safety on Android when switching to ESR 52)

[Tor Bug Tracker & Wiki]

#21863: Ensure proxy safety on Android
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-7.0-must,|  Actual Points:
  TorBrowserTeam201803, tbb-proxy-bypass |
Parent ID:  #5709| Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by sysrqb):

 * keywords:  ff52-esr, tbb-mobile, tbb-7.0-must, TorBrowserTeam201803 =>
 tbb-mobile, tbb-7.0-must, TorBrowserTeam201803, tbb-proxy-bypass


Old description:

> Mike mentions in #21625:
> {{{
> Android stuff that definitely leaks that we should fix (missing proxy
> params to HttpUrlConnection - these need to use the buildHttpConnection
> helper to get a proxy):
>  * mobile/android/base/java/org/mozilla/gecko/feeds/FeedFetcher.java
>  *
> mobile/android/base/java/org/mozilla/gecko/media/GeckoMediaDrmBridgeV21.java
>  *
> mobile/android/base/java/org/mozilla/gecko/search/SearchEngineManager.java
>  * mobile/android/thirdparty/com/keepsafe/switchboard/SwitchBoard.java
> }}}

New description:

 Mike mentions in #21625:
 {{{
 Android stuff that definitely leaks that we should fix (missing proxy
 params to HttpUrlConnection - these need to use the buildHttpConnection
 helper to get a proxy):
  * mobile/android/base/java/org/mozilla/gecko/feeds/FeedFetcher.java
  *
 mobile/android/base/java/org/mozilla/gecko/media/GeckoMediaDrmBridgeV21.java
  *
 mobile/android/base/java/org/mozilla/gecko/search/SearchEngineManager.java
  * mobile/android/thirdparty/com/keepsafe/switchboard/SwitchBoard.java
 }}}

 Blocker of releasing TBA.

--

Comment:

 We're past ESR 52, this is for whatever release we choose (probably 60).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25519 [Core Tor/Tor]: move away from asciidoc

[Tor Bug Tracker & Wiki]

#25519: move away from asciidoc
--+
 Reporter:  dkg   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:   => Tor: 0.3.5.x-final


Comment:

 Makes sense to me.  Is there anything that consumes markdown and produces
 good manpages nowadays?  The reason we went with asciidoc originally was
 that it produced better roff than the other tools we had around, and it
 didn't force us to learn sgml.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25582 [Core Tor/Tor]: Manual includes non-existant ExitPolicyDefault option

[Tor Bug Tracker & Wiki]

#25582: Manual includes non-existant ExitPolicyDefault option
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 let's leave the anchor in -- somebody may be using it, and I'd rather not
 remove anchors once we've added them, unless they're ''completely''
 pointless.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25600 [Obfuscation/Snowflake]: Running 2 instances of snowflake-client leads to the former one stopping

[Tor Bug Tracker & Wiki]

#25600: Running 2 instances of snowflake-client leads to the former one stopping
---+---
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by cypherpunks):

 * status:  new => closed
 * resolution:   => not a bug


Comment:

 Replying to [comment:2 dcf]:
 > Thanks for this.
 >
 > I tried it, but I wasn't able to reproduce it. On Debian, I used a
 browser from https://people.torproject.org/~dcf/pt-
 bundle/snowflake/20180321-8.0a4-4a5889af2891/ and a command line
 snowflake-client from [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/log/?id=07291a0136b8a01bd8761a14a51876f08ca0d578
 07291a0136].
 >  1. Started a download of
 
https://mirrors.edge.kernel.org/centos/7.4.1708/isos/x86_64/CentOS-7-x86_64-Everything-1708.iso.
 Was getting about 400 KB/s.
 >  2. In the snowflake/client directory, ran `tor -f torrc SOCKSPort
 1`. It finished bootstrapping and the Browser download was still
 running.
 >  3. Download through the command-line client: `curl -O --proxy
 socks5h://127.0.0.1:1/
 
https://mirrors.edge.kernel.org/centos/7.4.1708/isos/x86_64/CentOS-7-x86_64-Everything-1708.iso`.
 I was getting about 500 KB/s on this download and the browser was still
 about 400 KB/s.
 >
 > Maybe it was a coincidence that one of the clients died when the other
 one started? I'm currently testing some proxy changes from
 comment:63:ticket:21312, and it seems there is still a problem with
 proxies hanging up occasionally. Does it happen for you repeatedly?

 Interesting, I had actually repeated the steps twice at different times (I
 left the download going for quiet some bit at one time, probably 7 min)
 and I always had the same result. I was experiencing repeated shortages
 but I thought that this may have been due to the other snowflake-client
 process that I had running. But the good news is that I can't reproduce it
 now which means you're right :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #10177 [Applications/Tor Check]: get oftc using bulkexitlist again

[Tor Bug Tracker & Wiki]

#10177: get oftc using bulkexitlist again
+-
 Reporter:  arma|  Owner:  arlolra
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Check  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by pastly):

 * cc: pastly (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25260 [Applications/Tor Launcher]: Merge mozbuild files into tor-launcher.git

[Tor Bug Tracker & Wiki]

#25260: Merge mozbuild files into tor-launcher.git
---+---
 Reporter:  sysrqb |  Owner:  brade
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #24856 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by sysrqb):

 Replying to [comment:12 sysrqb]:
 > Replying to [comment:10 igt0]:
 > > sysrqb, I see that the tor-launcher is still using
 `general.useragent.locale` and `intl.locale.matchOS`. Looks like a new
 XPCOM method was added `LocaleService::GetRequestedLocales`[1] to replace
 them.
 > >
 > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1346616
 >
 > Oh, yes, good find. I'll correct this.

 I looked into this a bit more. We're not actually providing dynamic locale
 selection (#21920), so I don't think this is a priority at this moment and
 we don't need to worry about it in esr60. We should adjust this if/when we
 begin supporting this (#17400).

 For future reference:
 
https://groups.google.com/forum/#!msg/mozilla.dev.platform/DAxXcr1rh2c/KUUwoPM2AwAJ
 https://groups.google.com/forum/#!topic/mozilla.dev.platform/0FnHBfOPKdk
 https://hg.mozilla.org/mozilla-
 central/file/tip/intl/locale/mozILocaleService.idl#l19

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22718 [Obfuscation/Snowflake]: OpenWebRTC?

[Tor Bug Tracker & Wiki]

#22718: OpenWebRTC?
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arlolra):

 > Note: OpenWebRTC is currently not being actively maintained.
 > Also note that the upcoming [gstreamer release
 1.14](https://gstreamer.freedesktop.org/releases/1.14/) will have built in
 support for WebRTC.

 \\ From
 
https://github.com/EricssonResearch/openwebrtc/commit/4cbd779137ca514765ac27ba311c79260b0bf39c

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25600 [Obfuscation/Snowflake]: Running 2 instances of snowflake-client leads to the former one stopping

[Tor Bug Tracker & Wiki]

#25600: Running 2 instances of snowflake-client leads to the former one stopping
---+
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dcf):

 Thanks for this.

 I tried it, but I wasn't able to reproduce it. On Debian, I used a browser
 from https://people.torproject.org/~dcf/pt-
 bundle/snowflake/20180321-8.0a4-4a5889af2891/ and a command line
 snowflake-client from [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/log/?id=07291a0136b8a01bd8761a14a51876f08ca0d578
 07291a0136].
  1. Started a download of
 
https://mirrors.edge.kernel.org/centos/7.4.1708/isos/x86_64/CentOS-7-x86_64-Everything-1708.iso.
 Was getting about 400 KB/s.
  2. In the snowflake/client directory, ran `tor -f torrc SOCKSPort 1`.
 It finished bootstrapping and the Browser download was still running.
  3. Download through the command-line client: `curl -O --proxy
 socks5h://127.0.0.1:1/
 
https://mirrors.edge.kernel.org/centos/7.4.1708/isos/x86_64/CentOS-7-x86_64-Everything-1708.iso`.
 I was getting about 500 KB/s on this download and the browser was still
 about 400 KB/s.

 Maybe it was a coincidence that one of the clients died when the other one
 started? I'm currently testing some proxy changes from
 comment:63:ticket:21312, and it seems there is still a problem with
 proxies hanging up occasionally. Does it happen for you repeatedly?

 Or, there could be some weird interaction, like maybe it only happens when
 both of the clients are using the same proxy instance.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25592 [Obfuscation/Snowflake]: Consider webrtc<-->webrtc vs webrtc<-->websocket for the browser proxy

[Tor Bug Tracker & Wiki]

#25592: Consider webrtc<-->webrtc vs webrtc<-->websocket for the browser proxy
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  worksforme
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by arlolra):

 * status:  new => closed
 * resolution:   => worksforme


Comment:

 Agreed, let's decline.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25600 [Obfuscation/Snowflake]: Running 2 instances of snowflake-client leads to the former one stopping

[Tor Bug Tracker & Wiki]

#25600: Running 2 instances of snowflake-client leads to the former one stopping
---+
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by cypherpunks):

 Some more details: This was tested on Debian. Also the `snowflake-client`
 used for Ricochet is a copy placed in `/usr/bin`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25601 [Obfuscation/Snowflake]: Multiplex - one snowflake proxy should be able to support multiple clients

[Tor Bug Tracker & Wiki]

#25601: Multiplex - one snowflake proxy should be able to support multiple 
clients
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 Migrated from https://github.com/keroserene/snowflake/issues/11

 This seems to exist for the `proxy-go` but the JavaScript side has things
 like,

 {{{
 MAX_NUM_CLIENTS = 1
 CONNECTIONS_PER_CLIENT = 1
 }}}

 so I'm guessing it wasn't finished.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25592 [Obfuscation/Snowflake]: Consider webrtc<-->webrtc vs webrtc<-->websocket for the browser proxy

[Tor Bug Tracker & Wiki]

#25592: Consider webrtc<-->webrtc vs webrtc<-->websocket for the browser proxy
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dcf):

 In my opinion, WebSocket wins for simplicity and robustness. I don't know
 why WebRTC would have higher performance either (but I haven't tried it).
 Even WebRTC has to do a DTLS handshake, you still have overhead there.

 With a WebSocket bridge, the issue of Cgo and threads doesn't come up. We
 only use Cgo on the client, which doesn't have to scale very much. The
 proxies are running in browsers, no Cgo there. (proxy-go is another story,
 but that's orthogonal to the protocol used for the proxy–bridge link.) And
 the WebSocket bridge is essentially just an HTTPS server, like meek-
 server, which scales pretty well.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25600 [Obfuscation/Snowflake]: Running 2 instances of snowflake-client leads to the former one stopping

[Tor Bug Tracker & Wiki]

#25600: Running 2 instances of snowflake-client leads to the former one stopping
---+
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 Steps to reproduce:

 1. Use the fresh testbuilds by dcf `https://people.torproject.org/~dcf/pt-
 bundle/snowflake/20180321-8.0a4-4a5889af2891/`
 2. Start a download
 
`https://mirrors.edge.kernel.org/centos/7.4.1708/isos/x86_64/CentOS-7-x86_64-Everything-1708.iso`
 and watch `about:downloads` or your Task Manager.
 3. Open another instance of `snowflake-client` (for example in Ricochet
 edit the `torrc` in `./local/share/Ricochet/ricochet/tor` with the
 relevant config).
 4. Watch the download failing, or the receiving/s in the Task Manager go
 down to 0.

 Doesn't seem to be reproducible with the earlier version of `snowflake-
 client`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25597 [Obfuscation/Snowflake]: Proxy - better polling / reset

[Tor Bug Tracker & Wiki]

#25597: Proxy - better polling / reset
---+---
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by arlolra):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 Let's go with #25598

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25344 [Obfuscation/Snowflake]: proxy-go needs to relax between polls

[Tor Bug Tracker & Wiki]

#25344: proxy-go needs to relax between polls
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dcf):

 Replying to [comment:5 arlolra]:
 > > Maybe open a ticket for that.
 >
 > Or this can be done in #25597

 Oops, just made #25598.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25599 [Obfuscation/Snowflake]: SOCKS4 failure message

[Tor Bug Tracker & Wiki]

#25599: SOCKS4 failure message
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 > Sometimes, Tor emits this:
 >
 >> [warn] The connection to the SOCKS4 proxy server at 127.0.0.1:$someport
 just failed. Make sure that the proxy >> server is up and running.
 >
 > At which point no more handlers fire. Looking at the Tor source, this
 happens when SOCKS is "marked for close". This is inconvenient because
 then the client must be restarted for connectivity to work again.

 \\

 > Are you still experiencing this? Is it reproducible?

 \\

 > I experienced this sporadically while working on multiplexing. Right now
 it seems fine though.
 >
 > It seems to be 100% reproducible if I explicitly readPipe.Close() on the
 webrtc peer. My guess is that when the copyLoop sends an error or EOF at
 SOCKS, Tor interprets that as an unexpected situation, "marks for close /
 deletion" and so the SOCKS4 server disappears.
 >
 > Maybe there's a way to account for this in main() to also be able to
 recover the initial SOCKS listening? (this is not in the goptlib example,
 which we were originally based on) When the SOCKS connection is closed
 normally in handler, there's doesn't seem to be an issue.
 >
 > But, should test more possibilities / longer times.

 \\ Migrated from https://github.com/keroserene/snowflake/issues/32

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25598 [Obfuscation/Snowflake]: Let the broker inform proxies how often to poll

[Tor Bug Tracker & Wiki]

#25598: Let the broker inform proxies how often to poll
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 Currently, proxies poll the broker at a static rate of once every 5–10
 seconds. If we're anticipating thousands of proxies, we don't need them to
 poll so frequently.

 The broker could instead tell each proxy how long to wait before polling
 again. The broker could even dynamically adjust the rate based on an
 estimate of supply and demand.

 One way to do this would be a custom header in responses to `/proxy`
 requests:
 {{{
 Snowflake-Next-Poll: Thu, 22 Mar 2018 18:05:47 GMT
 }}}
 Or using a relative time offset:
 {{{
 Snowflake-Next-Poll: 600
 }}}

 There was a similar idea for flash proxy.
  #8171::
The facilitator included a fixed `check-back-in=600` in its responses.
  #8172::
Adjust polling interval dynamically (never implemented).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25597 [Obfuscation/Snowflake]: Proxy - better polling / reset

[Tor Bug Tracker & Wiki]

#25597: Proxy - better polling / reset
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arlolra):

 See https://trac.torproject.org/projects/tor/ticket/25344#comment:2

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25344 [Obfuscation/Snowflake]: proxy-go needs to relax between polls

[Tor Bug Tracker & Wiki]

#25344: proxy-go needs to relax between polls
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arlolra):

 > Maybe open a ticket for that.

 Or this can be done in #25597

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25597 [Obfuscation/Snowflake]: Proxy - better polling / reset

[Tor Bug Tracker & Wiki]

#25597: Proxy - better polling / reset
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 Migrated from https://github.com/keroserene/snowflake/issues/15

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25596 [Obfuscation/Snowflake]: Configure TURN servers for the proxy and/or client

[Tor Bug Tracker & Wiki]

#25596: Configure TURN servers for the proxy and/or client
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 > This may require spinning up our own TURN servers somewhere.
 >
 >> In most cases, the public ip candidates given by STUN servers are
 sufficient for peers to negotiate a working p2p path. But sometimes, maybe
 14% of the time [1], this isn't enough -- usually due to symmetric NAT /
 lack of port preservation, and a TURN relay is required as a last resort.
 >>
 >> Also, once snowflake proxies & clients are multiplexed, perhaps the
 likelihood that TURN continuous to be absolutely required for every pair
 of peers greatly decreases and we might be fine again. More thought is
 needed here.

 \\ Migrated from https://github.com/keroserene/snowflake/issues/18

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25594 [Obfuscation/Snowflake]: Broker: investigate non-domain-fronting secure client / proxy registrations

[Tor Bug Tracker & Wiki]

#25594: Broker: investigate non-domain-fronting secure client / proxy 
registrations
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dcf):

 An idea to use DNS over HTTPS:
 https://groups.google.com/forum/#!topic/traffic-obf/ZQohlnIEWM4
 > The circumvention idea is to take any existing DNS tunneling scheme and
 send it through DNS over HTTPS. To be a bit more specific: you send
 recursive DNS queries (encoding your upstream traffic) to the DNS-over-
 HTTPS server, which then forwards the queries to another specialized
 server that decodes them and proxies the data they contain.
 >
 > Even if not a general-purpose transport, DNS-over-HTTPS could be an
 ideal rendezvous mechanism for a system like Snowflake or Moat. One where
 you only need to send/receive a small amount of very hard-to-block data in
 order to bootstrap a connection.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25595 [Obfuscation/Snowflake]: Test suite for Snowflake on various NAT topologies

[Tor Bug Tracker & Wiki]

#25595: Test suite for Snowflake on various NAT topologies
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 Migrated from https://github.com/keroserene/snowflake/issues/20

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25594 [Obfuscation/Snowflake]: Broker: investigate non-domain-fronting secure client / proxy registrations

[Tor Bug Tracker & Wiki]

#25594: Broker: investigate non-domain-fronting secure client / proxy 
registrations
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 > Pasting discussion from email,
 >
 >> in the Flashproxy case, registration wasn't
 >> bidi, and I think they imagined using insecure
 >> channels to register like OSSes. In Snowflake,
 >> the client is making TLS connections with the
 >> broker, which amounts to the same thing as
 >> encrypting the payload with the facilitator's
 >> public key.
 >
 > Also,
 >
 >> There's also the case where an adversary DOSes the facilitator with a
 >> bunch of fake client or proxy registrations and things like that.
 >
 > This is now #25593
 >
 >> Also, there is the potential that in the future we might need some
 >> sort of non-domain-fronting rendezvous. It seems that right now we
 >> have an ecosystem of tools growing that assumes domain-fronting will
 >> always be available & effective. May be worth considering how to
 >> prepare for regions where this might not work as well in the future.
 >
 > So this ticket should probably be for that.

 \\ Migrated from https://github.com/keroserene/snowflake/issues/13

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25593 [Obfuscation/Snowflake]: Broker needs better resilience against DoS

[Tor Bug Tracker & Wiki]

#25593: Broker needs better resilience against DoS
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 Migrated from https://github.com/keroserene/snowflake/issues/25

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25344 [Obfuscation/Snowflake]: proxy-go needs to relax between polls

[Tor Bug Tracker & Wiki]

#25344: proxy-go needs to relax between polls
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dcf):

 * status:  merge_ready => closed
 * resolution:   => fixed


Comment:

 [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=07291a0136b8a01bd8761a14a51876f08ca0d578
 07291a0136b8a01bd8761a14a51876f08ca0d578]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25592 [Obfuscation/Snowflake]: Consider webrtc<-->webrtc vs webrtc<-->websocket for the browser proxy

[Tor Bug Tracker & Wiki]

#25592: Consider webrtc<-->webrtc vs webrtc<-->websocket for the browser proxy
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 > webrtc <-->websocket is the current situation, which works.
 > webrtc <--> webrtc would take a bit more work.

 \\

 > Quoting @Yawning,
 >
 > What are your plans for actually getting the server side to scale well?
 Since you're using cgo you will run into Really Interesting behavior wrt
 OS threads as you try to increase concurrency.
 >
 > https://lists.torproject.org/pipermail/tor-dev/2016-January/010311.html

 \\

 > Yes, that does complicate the potential of using a second WebRTC
 connection to the relay...
 >
 > The benefit of WebRTC on both sides should be performance / latency,
 whereas right now the websocket connection to the relay is most likely
 bottlenecking the first WebRTC data channel from the client.
 >
 > But maybe it's actually not, at least significantly. It's quite possible
 the typical latency of the network is already most of what the user
 experiences compared to the websocket relay, in which case the benefit of
 the 2nd WebRTC would be negligible with respect to the effort of making it
 happen maybe we need to measure this (I haven't found any obvious
 latency numbers on metrics.torproject.org), or we could just decide not to
 bother and close this.

 \\ Migrated from https://github.com/keroserene/snowflake/issues/8

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25582 [Core Tor/Tor]: Manual includes non-existant ExitPolicyDefault option

[Tor Bug Tracker & Wiki]

#25582: Manual includes non-existant ExitPolicyDefault option
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by atagar):

 Gotcha. Is such an anchor useful? I just did a quick grep of webwml but no
 hits. An anchor seems pretty boot if nothing links to it.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25591 [Obfuscation/Snowflake]: Pass ICE server information from Broker to WebRTC Client

[Tor Bug Tracker & Wiki]

#25591: Pass ICE server information from Broker to WebRTC Client
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 > The clients may be in filtered regions where common ICE servers may be
 unavailable.
 >
 > May need to revise the Configuration interface of go-webrtc while
 figuring this part out.

 \\ Migrated from https://github.com/keroserene/snowflake/issues/3

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24832 [Core Tor/Nyx]: Drop 'measured' bandwidth from nyx

[Tor Bug Tracker & Wiki]

#24832: Drop 'measured' bandwidth from nyx
--+
 Reporter:  atagar|  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by atagar):

 Certainly, have at it!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25344 [Obfuscation/Snowflake]: proxy-go needs to relax between polls

[Tor Bug Tracker & Wiki]

#25344: proxy-go needs to relax between polls
---+-
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by arlolra):

 * status:  needs_review => merge_ready


Comment:

 LGTM

 > Ideally, in the future, we will have the broker adjust the interval
 based on the number of proxies present, in order to maintain a desired
 average poll rate.

 Maybe open a ticket for that.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24862 [Metrics/Consensus Health]: Add per-relay descriptor timestamps to the consensus health detailed page

[Tor Bug Tracker & Wiki]

#24862: Add per-relay descriptor timestamps to the consensus health detailed 
page
--+---
 Reporter:  teor  |  Owner:  tom
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by tom):

 * status:  new => needs_information


Comment:

 Is this still desirable?  I started working on it, and got zero relays
 with

 > self.consensus.routers[r].published != vote.routers[r].published

 Happy to add if we'd still like it though.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22584 [Applications/Tor Browser]: More RWX memory pages for TBB on some Windows versions

[Tor Bug Tracker & Wiki]

#22584: More RWX memory pages for TBB on some Windows versions
--+--
 Reporter:  arthuredelstein   |  Owner:  tom
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * owner:  tbb-team => tom
 * status:  needs_information => assigned


Comment:

 https://android.googlesource.com/platform/bionic/+/master/android-changes-
 for-ndk-developers.md#Writable-and-Executable-Segments-Enforced-for-API-
 level-26

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25396 [Metrics/Consensus Health]: Consensus health reports wrong latest valid-after time

[Tor Bug Tracker & Wiki]

#25396: Consensus health reports wrong latest valid-after time
--+
 Reporter:  asn   |  Owner:  tom
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by tom):

 * status:  new => closed
 * resolution:   => fixed


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25590 [Internal Services/Tor Sysadmin Team]: Add a configuration line to the consensus-health Apache config

[Tor Bug Tracker & Wiki]

#25590: Add a configuration line to the consensus-health Apache config
-+
 Reporter:  tom  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #25588
   Points:   |   Reviewer:
  Sponsor:   |
-+
 >  SetEnvIf X-Requested-With XMLHttpRequest no-gzip

 #25588 is a feature to allow users to load individual relay details on the
 index page; without having to load the entire detailed page. It uses Range
 requests.

 consensus-health.torproject.org currently supports Range requests, so no
 configuration needed for that:

 > curl -H "Range: bytes=0-100" -H "X-Requested-With: XMLHttpRequest" https
 ://consensus-health.torproject.org

 But using compression in conjunction with Range requests confuses Apache.
 (Should the Range be before the compression, or after? Apparently it's
 never been decided.)

 So for AJAX requests we need to disable compression. The only thing making
 AJAX requests to consensus-health is my new feature so we're not going to
 be sending a ton of data uncompressed.

 Once the configuration is correct, the following two commands will have
 the same output:

 > curl -H "Range: bytes=0-100" -H "X-Requested-With: XMLHttpRequest" https
 ://consensus-health.torproject.org
 > curl -H "Range: bytes=0-100" -H "X-Requested-With: XMLHttpRequest" https
 ://consensus-health.torproject.org --compressed

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25589 [Metrics/Website]: Add test to ensure that output of ATOM feed is valid XML

[Tor Bug Tracker & Wiki]

#25589: Add test to ensure that output of ATOM feed is valid XML
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Most clients will refuse to parse the feed if it's not valid XML. This
 could be a unit test or it could be part of the ant task for updating the
 news.json file.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25588 [Metrics/Consensus Health]: Allow people to dynamically load single relay info on the consensus-health index page

[Tor Bug Tracker & Wiki]

#25588: Allow people to dynamically load single relay info on the 
consensus-health
index page
--+-
 Reporter:  tom   |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 See https://lists.torproject.org/pipermail/tor-dev/2018-March/012975.html
 for more details

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #14389 [Applications/Tor Browser]: Improve TBB UI of hidden service client authorization

[Tor Bug Tracker & Wiki]

#14389: Improve TBB UI of hidden service client authorization
+--
 Reporter:  asn |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, tbb-usability, ux-team  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by asn):

 Replying to [comment:27 dgoulet]:
 > Replying to [comment:22 asn]:
 > > Executive summary No2: v2 descriptors do not let us distinguish
 between descs where the auth is enabled or whether they are corrupted, so
 Tor keeps on trying new directories in hope of finding a non-corrupted
 desc. In this sense, the current approach of the patch is not bad.
 >
 > Indeed... and not only that but a warning will be emitted because we'll
 try to parse the introduction point using a binary blob (encrypted).
 >
 > Proposition:
 >
 > Upon receiving a descriptor from the HSDir, if we can parse it (passes
 `rend_parse_v2_service_descriptor()`) but unable to decode intro points,
 we actually keep it in the client cache. Meaning that once Tor browser (or
 tor client) comes back with the authentication token, we don't have to
 refetch it. We'll probably to patch couples things here to make sure that
 we can use a descriptor in our cache with client auth but also that if the
 auth token is invalid, we trigger a `BAD_DESC` event.
 >
 > Another approach would be to have a control port option (or torrc) to
 tell tor to keep any invalid but parseable descriptor which TB would
 enable. But honestly, for the sake of simplicity, I think we could easily
 keep it in the client cache which is bound to expire after a while
 normally.
 >
 > That being said, TB does need to check for the `BAD_DESC` event of
 `HS_DESC` mentioned in comment:11. Once you get that, you should prompt
 for a client authorization. If you don't see that event after, it should
 be connecting. Else, tor should trigger the event again and TB should ask
 again for the auth code.


 Hmmm, that does seem like a plan. However it's only approximately
 specified how it would work. And looking at the codebase it's quite hairy
 at those parts and the interfaces are not obvious to me. And also it's the
 legacy v2 codebase that we would ideally not touch a lot.

 Another approach would be: Do nothing on the little-t-tor side and just
 use Arthur's approach of checking for `BAD_DESC` events. The tradeoffs:
 {{{
 + No extra complexity on the Tor side (no chance for extra bugs,
 complicated code, review process, etc.)
 - Some extra network load from users of this feature
 }}}

 The pros are quite obvious, so let's try to estimate the extra load we
 impose:

 First let's assume that regular users don't stumble on random HSes with
 client auth, and even if they did, they would impose the same network load
 with this feature and without it (6 HSDir requests for unparseable
 descriptors). So it's safe to assume that the extra load comes from people
 who want to use this feature:

 So when a person wants to use this feature (with the right password), they
 will cause 6 HSDir requests on the network, until TB realizes that it
 needs to try client auth. Then it will need to do one additional HSDir
 request to properly decrypt it. This means that legit users of this
 feature cause 6 useless HSDir requests. Basically the same load as
 mistyping an onion address. OTOH, when a person wants to use this feature
 with the wrong password, they will cause 12 useless HSDir requests.

 It's unclear to me whether this tradeoff is worthwhile, however I do feel
 bad about spending time to reengineer the v2 codebase just for this, since
 the effort seems far from trivial. Then in v3 we can do it the right way.

 I'm not actually sure this is a good idea, but I'll just throw it here for
 now.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25587 [Applications/Tor Browser]: Investigate optimizing APK for Smart App Updating

[Tor Bug Tracker & Wiki]

#25587: Investigate optimizing APK for Smart App Updating
--+
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-mobile
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 In mid-2012, beginning with Jelly Bean (4.1), Google Play began using
 Smart App Updates [0]
 {{{
 Smart App Updates

 Smart app updates is a new feature of Google Play that introduces a better
 way
 of delivering app updates to devices. When developers publish an update,
 Google
 Play now delivers only the bits that have changed to devices, rather than
 the
 entire APK. This makes the updates much lighter-weight in most cases, so
 they
 are faster to download, save the device’s battery, and conserve bandwidth
 usage
 on users’ mobile data plan. On average, a smart app update is about 1/3
 the
 size of a full APK update.
 }}}

 Considering Orfox is now ~30MB, and this may increase with additional
 locales, we should track the current diff patch size Google Play
 distributes for incremental updates, and we should investigate if we can
 tweak our APK so it provides minimal diffs.

 Can we (nearly) reproduce their results?

 StackOverflow suggests they are using GDIFF [1].

 Google was nice enough to publish some more details (4 years later) about
 how they're now using a newer diff method in some situations [2]:

 {{{
 For approximately 98% of app updates from the Play Store, only changes
 (deltas)
 to APK files are downloaded and merged with the existing files, reducing
 the
 size of updates. Google Play has used delta algorithms since 2012, and we
 recently rolled out an additional delta algorithm, bsdiff (created by
 Colin
 Percival1), that our experimentation shows can reduce delta size by up to
 50%
 or more compared to the previous algorithm for some APKs. Bsdiff is
 specifically targeted to produce more efficient deltas of native libraries
 by
 taking advantage of the specific ways in which compiled native code
 changes
 between versions. To be most effective, native libraries should be stored
 uncompressed (compression interferes with delta algorithms).
 }}}

 Unfortunately, we are restricted by our user base and by which platforms
 Mozilla is targeting. At this point, Mozilla are still targeting SDK 16,
 which is good for us, but we don't get new optimizations:

 {{{
 However, please note, native libraries should only be uncompressed when
 the
 minimum SDK version for an APK is 23 (Marshmallow) or later
 }}}

 So we should keep bsdiff optimizations in mind for when Mozilla eventually
 move to min-sdk 23+.

 [0] https://developer.android.com/about/versions/jelly-bean.html
 [1] https://stackoverflow.com/questions/12860938/smart-app-updates-on-
 google-play-store-how-does-it-work/12877791#12877791
 [2] https://android-developers.googleblog.com/2016/07/improvements-for-
 smaller-app-downloads.html

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25440 [Core Tor/Tor]: Broken openat syscall in Sandbox mode

[Tor Bug Tracker & Wiki]

#25440: Broken openat syscall in Sandbox mode
-+-
 Reporter:  ageisp0lis   |  Owner:  nickm
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox 033-must regression  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * owner:  (none) => nickm
 * keywords:  sandbox => sandbox 033-must regression
 * status:  new => accepted
 * milestone:   => Tor: 0.3.3.x-final


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25512 [Core Tor/Tor]: Tor in-process restart fails to write auth cookie

[Tor Bug Tracker & Wiki]

#25512: Tor in-process restart fails to write auth cookie
-+-
 Reporter:  tla  |  Owner:  ahf
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, auth cookie, restart,|  Actual Points:
  in-process, s8-api |
Parent ID:  #23684   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by nickm):

 * keywords:  tor-mobile, auth cookie, restart, in-process => tor-mobile,
 auth cookie, restart, in-process, s8-api
 * sponsor:   => Sponsor8


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25580 [Applications/Tor Browser]: Should Tor Browser auto update for me when it starts and it knows it's out of date?

[Tor Bug Tracker & Wiki]

#25580: Should Tor Browser auto update for me when it starts and it knows it's 
out
of date?
--+--
 Reporter:  arma  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 A little background info: updates are automatic (unless the user disables
 that behavior by changing preferences). As part of the UX work, we should
 improve feedback so that: (1) we don't ask the user to request an update
 when the browser has already done that for them and (2) so the user knows
 that an update is being downloaded and applied.

 We also need to sort out how to provide an update experience that is
 appropriate for Tor Browser users within the constraints of Firefox's
 implementation. My impression is that in recent versions of Firefox (55
 and newer?) the update notifications are more subtle, at least for some
 period of time. For Tor Browser, we may want to communicate more loudly
 than Firefox does about the fact that an update is pending and that a
 restart is needed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25581 [Core Tor/Tor]: Inconsistent underscore config options (for vanguard options)

[Tor Bug Tracker & Wiki]

#25581: Inconsistent underscore config options (for vanguard options)
-+
 Reporter:  atagar   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  regression 033-must  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 (let's get this settle in 0.3.3 before it stabilizes)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25581 [Core Tor/Tor]: Inconsistent underscore config options (for vanguard options)

[Tor Bug Tracker & Wiki]

#25581: Inconsistent underscore config options (for vanguard options)
-+
 Reporter:  atagar   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  regression 033-must  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * keywords:   => regression 033-must
 * milestone:   => Tor: 0.3.3.x-final


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25398 [Core Tor/Tor]: tests fail if COMPAT_HAS_MMAN_AND_PAGESIZE is not set

[Tor Bug Tracker & Wiki]

#25398: tests fail if COMPAT_HAS_MMAN_AND_PAGESIZE is not set
-+-
 Reporter:  Hello71  |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  easy, intro, tor-test, review-   |  Actual Points:
  group-34   |
Parent ID:   | Points:  0.1
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 LGTM. Builds and passes tests on Linux and MinGW too.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25581 [Core Tor/Tor]: Inconsistent underscore config options (for vanguard options) (was: Inconsistent underscore config options)

[Tor Bug Tracker & Wiki]

#25581: Inconsistent underscore config options (for vanguard options)
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * cc: mikeperry (added)


Comment:

 I'd be okay with double-underscores on these

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25582 [Core Tor/Tor]: Manual includes non-existant ExitPolicyDefault option

[Tor Bug Tracker & Wiki]

#25582: Manual includes non-existant ExitPolicyDefault option
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Have a look at the state before 3563a2c8194ebe9430603803a53b073e181ce773
 -- I think that it was meant to be an anchor only, with no label.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25057 [Community/Tor Support]: Warn Tor users about how to use Bitcoin over Tor, using blog and official twitter.

[Tor Bug Tracker & Wiki]

#25057: Warn Tor users about how to use Bitcoin over Tor, using blog and 
official
twitter.
---+-
 Reporter:  cypherpunks|  Owner:  Jaruga
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by Jaruga):

 * status:  assigned => closed
 * resolution:   => implemented


Comment:

 Resolved.

 https://trac.torproject.org/projects/tor/wiki/doc/bitcoin

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #16221 [Applications/Tor Browser]: Investigate WebRTC with TCP-ICE and hidden services

[Tor Bug Tracker & Wiki]

#16221: Investigate WebRTC with TCP-ICE and hidden services
--+--
 Reporter:  mikeperry |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:16 cypherpunks]:
 > PLZ CAN HAZ NICE THINGS?

 PLZ CAN HAZ NICE PATCHES?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #16221 [Applications/Tor Browser]: Investigate WebRTC with TCP-ICE and hidden services

[Tor Bug Tracker & Wiki]

#16221: Investigate WebRTC with TCP-ICE and hidden services
--+--
 Reporter:  mikeperry |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 There is a lot of awesome p2p stuff happening with WebRTC nowadays, and
 Tor Browser is left out of all of this. Is anyone working on building
 ephemeral hidden service WebRTC integration?

 https://github.com/Chocobozzz/PeerTube is one example awesome webrtc thing
 that actually does work with Tor Browser today, albeit not with webrtc,
 so, Tor users are all leeches (only able to get the video from the
 peertube instance's server, which typically has limited resources)
 Ideally TBB users could connect to eachother's onions, but, even lacking
 that, it would at least be nice of TBB users could make outbound
 connections to peers even if they can't receive inbound connections.

 PLZ CAN HAZ NICE THINGS?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25516 [Core Tor/Tor]: Refactor relay cell crypto into a new relaycrypt.c

[Tor Bug Tracker & Wiki]

#25516: Refactor relay cell crypto into a new relaycrypt.c
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  task | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-cell, crypto, refactor, tor- |  Actual Points:
  testing, tor-modularity|
Parent ID:   | Points:  .5
 Reviewer:   |Sponsor:
 |  Sponsor3-can
-+-
Changes (by nickm):

 * status:  assigned => accepted


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25575 [Internal Services/Tor Sysadmin Team]: Server space request (175 GB total) for hosting Tor Browser downloads

[Tor Bug Tracker & Wiki]

#25575: Server space request (175 GB total) for hosting Tor Browser downloads
-+-
 Reporter:  arthuredelstein  |  Owner:  tpa
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * cc: brade, mcs (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25399 [Core Tor/Tor]: mmap length doesn't need to be page-aligned

[Tor Bug Tracker & Wiki]

#25399: mmap length doesn't need to be page-aligned
-+
 Reporter:  Hello71  |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Low  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:  fixed
 Keywords:  review-group-34  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:  ahf  |Sponsor:
-+
Changes (by nickm):

 * status:  merge_ready => closed
 * resolution:   => fixed


Comment:

 okay; merging this to master.  I wonder if any of the mingw workarounds
 are still needed, but I guess we'll find out soon :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25515 [Core Tor/Tor]: Add a unit test for geoip_load_file()

[Tor Bug Tracker & Wiki]

#25515: Add a unit test for geoip_load_file()
--+--
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * status:  accepted => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25515 [Core Tor/Tor]: Add a unit test for geoip_load_file()

[Tor Bug Tracker & Wiki]

#25515: Add a unit test for geoip_load_file()
--+--
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * status:  merge_ready => accepted
 * reviewer:  isis =>
 * keywords:  review-group-35 =>
 * milestone:  Tor: 0.3.4.x-final => Tor: unspecified


Comment:

 merged to master; thanks!

 Putting this back into new in case juga or someone else wants to do the
 other tests discussed above.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24832 [Core Tor/Nyx]: Drop 'measured' bandwidth from nyx

[Tor Bug Tracker & Wiki]

#24832: Drop 'measured' bandwidth from nyx
--+
 Reporter:  atagar|  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Guinness):

 Hi,
 Can I take this issue ?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25586 [Core Tor/Torsocks]: gethostbyaddr_r doesn't populate h_addrtype field of output hostent struct

[Tor Bug Tracker & Wiki]

#25586: gethostbyaddr_r doesn't populate h_addrtype field of output hostent 
struct
---+-
 Reporter:  exarkun|  Owner:  dgoulet
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by exarkun):

 * Attachment "torsocks-h_addrtype.patch" added.

 unit tests and bug fix

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25586 [Core Tor/Torsocks]: gethostbyaddr_r doesn't populate h_addrtype field of output hostent struct

[Tor Bug Tracker & Wiki]

#25586: gethostbyaddr_r doesn't populate h_addrtype field of output hostent 
struct
---+-
 Reporter:  exarkun|  Owner:  dgoulet
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 The glibc implementation of gethostbyaddr_r will set h_addrtype to the
 address family that was passed in as an argument.  Some programs depend on
 this (CPython is the one I noticed) for correct operation.

 The current behavior leaves the field unchanged and likely provides an
 undefined value to the caller.  In the case of CPython, this results in
 `socket.gethostbyaddr` always raising EAFNOSUPPORT.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25584 [Applications/Tor Browser]: The -debug build is broken

[Tor Bug Tracker & Wiki]

#25584: The -debug build is broken
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, boklm201803,|  Actual Points:
  TorBrowserTeam201803   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 The build is working with commit 4e8ca92b2b6424a659f62e9cfdeca3ac107d021c,
 so it seems the error is caused by the binutils update from #16472.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25286 [Webpages/Website]: Relay Search has moved to the Metrics portal

[Tor Bug Tracker & Wiki]

#25286: Relay Search has moved to the Metrics portal
--+--
 Reporter:  irl   |  Owner:  irl
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #25283| Points:
 Reviewer:  hiro  |Sponsor:
--+--
Changes (by irl):

 * cc: hiro (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25569 [Webpages]: Add decoded:Legal's v3 onion service to NextGenOnions wiki

[Tor Bug Tracker & Wiki]

#25569: Add decoded:Legal's v3 onion service to NextGenOnions wiki
-+
 Reporter:  cypherpunks  |  Owner:  asn
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Webpages |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by asn):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 Added!

 Not sure why you guys want me to add more stuff to that wiki page; do
 people actually look there?

 But anyway, I don't mind adding more stuff there, so let's do it!
 Thanks! :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19910 [Applications/Tor Browser]: Rip out optimistic data socks handshake variant (#3875)

[Tor Bug Tracker & Wiki]

#19910: Rip out optimistic data socks handshake variant (#3875)
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201802R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:  TorBrowserTeam201802R, tbb-backport => TorBrowserTeam201802R


Comment:

 Please don't add random keywords, thanks.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #25239, #25558

[Tor Bug Tracker & Wiki]

Batch modification to #25239, #25558 by irl:


Action: resolve

Comment:
Merged.

--
Tickets URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #8288 [Applications/Tor Browser]: security, relability and repeatability issues in the TBB build process

[Tor Bug Tracker & Wiki]

#8288: security, relability and repeatability issues in the TBB build process
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tbb-security, tbb-rbm |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 This has been implemented with gitian/rbm.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #8525 [Applications/Tor bundles/installation]: ask build dependency maintainers to get HTTPS and GPG

[Tor Bug Tracker & Wiki]

#8525: ask build dependency maintainers to get HTTPS and GPG
-+-
 Reporter:  proper   |  Owner:  erinn
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  bundles/installation   |
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:  #8288| Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * keywords:  needs-triage =>
 * status:  reopened => closed
 * resolution:   => wontfix


Comment:

 We are downloading most dependencies using https and a gpg signature. When
 there is no signature we check the checksum.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25585 [Applications/Tor Browser]: Use https instead of http to fetch dependencies when possible

[Tor Bug Tracker & Wiki]

#25585: Use https instead of http to fetch dependencies when possible
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, boklm201803,|  Actual Points:
  TorBrowserTeam201803R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * status:  new => needs_review
 * keywords:  tbb-rbm, boklm201803 => tbb-rbm, boklm201803,
 TorBrowserTeam201803R


Comment:

 There is a patch for review in branch `bug_25585`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_25585=cd059a825f61d6ae514cfe823b3075819485f704

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19910 [Applications/Tor Browser]: Rip out optimistic data socks handshake variant (#3875)

[Tor Bug Tracker & Wiki]

#19910: Rip out optimistic data socks handshake variant (#3875)
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201802R, tbb-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * keywords:  ux-team, TorBrowserTeam201802R => TorBrowserTeam201802R, tbb-
 backport


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25585 [Applications/Tor Browser]: Use https instead of http to fetch dependencies when possible

[Tor Bug Tracker & Wiki]

#25585: Use https instead of http to fetch dependencies when possible
--+
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-rbm,
  |  boklm201803
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 There are a few dependencies that we fetch over http during the Tor
 Browser build process. Even if we check their signature or checksum, it
 would be better to use https when possible.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25584 [Applications/Tor Browser]: The -debug build is broken

[Tor Bug Tracker & Wiki]

#25584: The -debug build is broken
-+-
 Reporter:  boklm|  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm, boklm201803,
 Severity:  Normal   |  TorBrowserTeam201803
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 When running `make testbuild-linux-x86_64-debug` the build fails in the
 firefox part.

 The logs contain:
 {{{
 Executing /var/tmp/build/firefox-5756f46acaab/obj-x86_64-pc-linux-
 gnu/dist/bin/shlibsign -v -o ../../dist/firefox/libsoftokn3.chk -i
 ../../dist/firefox/libsoftokn3.so
 Library File: ../../dist/firefox/libsoftokn3.so 2047928 bytes
 Check File: ../../dist/firefox/libsoftokn3.chk
   hash: 32 bytes
 78 57 27 a6 7f 68 57 57 f1 2b
 1c c9 17 b3 89 2b 6e e5 76 89
 6f 47 0a d9 ac bd 1c c9 b4 13
 59 68
   signature: 64 bytes
 15 55 ff f3 3f 8c e1 4b 76 47
 01 9e 55 8a 07 63 79 c9 15 e4
 6c 26 79 03 86 a3 66 7a 25 e9
 d5 a3 05 31 ce e3 23 fa 09 3f
 84 6a 99 e5 fd 74 9c 12 ad 01
 f4 b6 e9 86 38 25 c8 71 9b 87
 01 0a 75 1f
 ASAN:SIGSEGV
 =
 ==25788==ERROR: AddressSanitizer: SEGV on unknown address 0x2ab47552d10c
 (pc 0x2ab4756a98a8 bp 0x3a45837f sp 0x7ffcd3f07458 T0)
 #0 0x2ab4756a98a7 in
 __sanitizer::StackDepotBase<__sanitizer::StackDepotNode, 1,
 20>::find(__sanitizer::StackDepotNode*, __sanitizer::StackTrace, unsigned
 int)
 ../../.././libsanitizer/sanitizer_common/sanitizer_stackdepotbase.h:62
 #1 0x2ab4756a9a38 in
 __sanitizer::StackDepotBase<__sanitizer::StackDepotNode, 1,
 20>::Put(__sanitizer::StackTrace, bool*)
 ../../.././libsanitizer/sanitizer_common/sanitizer_stackdepotbase.h:104
 #2 0x2ab4756a94e7 in
 __sanitizer::StackDepotPut(__sanitizer::StackTrace)
 ../../.././libsanitizer/sanitizer_common/sanitizer_stackdepot.cc:107
 #3 0x2ab4756206b9 in QuarantineChunk
 ../../.././libsanitizer/asan/asan_allocator2.cc:424
 #4 0x2ab4756206b9 in Deallocate
 ../../.././libsanitizer/asan/asan_allocator2.cc:462
 #5 0x2ab475692e15 in __interceptor_free
 ../../.././libsanitizer/asan/asan_malloc_linux.cc:48
 #6 0x2ab4753ed2ab  (/lib64/ld-linux-x86-64.so.2+0x132ab)
 #7 0x2ab4753ed99d  (/lib64/ld-linux-x86-64.so.2+0x1399d)
 #8 0x2ab4753e7ba5  (/lib64/ld-linux-x86-64.so.2+0xdba5)
 #9 0x2ab47678e2eb  (/lib/x86_64-linux-gnu/libdl.so.2+0x12eb)
 #10 0x2ab47678e00e in dlclose (/lib/x86_64-linux-
 gnu/libdl.so.2+0x100e)
 #11 0x2ab475635ab7 in __interceptor_dlclose
 ../../.././libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4638
 #12 0x2ab4754568f0 in pr_LoadLibraryByPathname /var/tmp/build/firefox-
 5756f46acaab/nsprpub/pr/src/linking/prlink.c:657
 #13 0x2ab4754568f0 in PR_LoadLibraryWithFlags /var/tmp/build/firefox-
 5756f46acaab/nsprpub/pr/src/linking/prlink.c:418
 #14 0x2ab4753c246f in main /var/tmp/build/firefox-
 5756f46acaab/security/nss/cmd/shlibsign/shlibsign.c:1323
 #15 0x2ab4769afeac in __libc_start_main (/lib/x86_64-linux-
 gnu/libc.so.6+0x1eeac)
 #16 0x2ab4753c25a0  (/var/tmp/build/firefox-5756f46acaab/obj-x86_64
 -pc-linux-gnu/security/nss/cmd/shlibsign/shlibsign+0x75a0)

 AddressSanitizer can not provide additional info.
 SUMMARY: AddressSanitizer: SEGV
 ../../.././libsanitizer/sanitizer_common/sanitizer_stackdepotbase.h:62
 __sanitizer::StackDepotBase<__sanitizer::StackDepotNode, 1,
 20>::find(__sanitizer::StackDepotNode*, __sanitizer::StackTrace, unsigned
 int)
 ==25788==ABORTING
 Traceback (most recent call last):
   File "/var/tmp/build/firefox-
 5756f46acaab/toolkit/mozapps/installer/packager.py", line 341, in 
 main()
   File "/var/tmp/build/firefox-
 5756f46acaab/toolkit/mozapps/installer/packager.py", line 337, in main
 copier.copy(args.destination)
   File "/var/tmp/build/firefox-
 5756f46acaab/python/mozbuild/mozpack/copier.py", line 399, in copy
 copy_results.append((destfile, f.copy(destfile, skip_if_older)))
   File "/var/tmp/build/firefox-
 5756f46acaab/toolkit/mozapps/installer/packager.py", line 124, in copy
 errors.fatal('Error while signing %s' % self.path)
   File "/var/tmp/build/firefox-
 5756f46acaab/python/mozbuild/mozpack/errors.py", line 103, in fatal
 self._handle(self.FATAL, msg)
   File "/var/tmp/build/firefox-
 5756f46acaab/python/mozbuild/mozpack/errors.py", line 98, in _handle
 raise ErrorMessage(msg)
 mozpack.errors.ErrorMessage: Error: Error while signing
 ../../dist/firefox/libsoftokn3.so
 make[3]: *** [stage-package] Error 1
 make[3]: Leaving directory 

[tor-bugs] #25583 [HTTPS Everywhere]: Wrong host in Booklooker.de.xml

[Tor Bug Tracker & Wiki]

#25583: Wrong host in Booklooker.de.xml
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  HTTPS Everywhere  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 booklooker.de does not use the host https://secure.booklooker.de anymore.

 All SSL connections use https://www.booklooker.de

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23780 [Obfuscation/Snowflake]: Tor repeatedly tells me that "Your Guard is failing an extremely large amount of circuits" when using snowflake

[Tor Bug Tracker & Wiki]

#23780: Tor repeatedly tells me that "Your Guard is failing an extremely large
amount of circuits" when using snowflake
---+--
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:  Tor: 0.3.2.9
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

 * status:  needs_information => closed
 * resolution:   => fixed


Comment:

 So this is what I did:

 1. Download and extract your build.
 2. Replace my older snowflake-client with the one in your build.
 3. Delete the state file.
 4. ./start-tor-browser --debug

 And I did no see those errors! So looks like it's been fixed. Also memory
 usage is much much better! Great job snowflake team! :D

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #17569 [Applications/Tor Browser]: Add uBlock Origin to the Tor Browser

[Tor Bug Tracker & Wiki]

#17569: Add uBlock Origin to the Tor Browser
-+-
 Reporter:  kernelcorn   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability tbb-security, tbb- |  Actual Points:
  performance|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 FWIW Firefox will also move to block some ads by default
 https://wiki.mozilla.org/Firefox/Roadmap

 > Last but not least, in 2018, Firefox will get more opinionated. People
 on the web deserve a browser that represents people first, a browser that
 isn't neutral when it comes to advertising, tracking and other dark
 patterns on the web.
 >
 > [...]
 >
 > Filter certain types of ads by default: Firefox will offer users a
 simple ad filtering option. We're in the early stages still, researching
 types of advertisements that should be blocked by default. (Q3)
 >
 > Block ad re-targeting: We are working on blocking cross-domain tracking.
 Details to follow. (Q3)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25408 [Applications/Tor Browser]: latin-1 supplement characters in filename results in zero-sized downloaded files

[Tor Bug Tracker & Wiki]

#25408: latin-1 supplement characters in filename results in zero-sized 
downloaded
files
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 apparently, all versions seem to download sucessfully, it's just that some
 versions say they've succeeded and others that they've failed, but all of
 them write at least two html files at a time, one with data, one empty,
 but any filename with a latin-1 supplement unicode block character in the
 title results in what is a bad encoding, this seems to be true in the
 current version at least all the way back to torbrowser 3.6

 browser indicates success
 tor-browser-linux64-4.5a4_en-US.tar.xz
 -rw-r--r-- 1 heir loom 176162 Mar 22 01:50 ''$'\242''.html'
 drwxr-xr-x 2 heir loom180 Mar 22 01:50 ''$'\242''_files'
 -rw-r--r-- 1 heir loom  0 Mar 22 01:50 ''$'\302\242''.html'

 browser indicates failure
 tor-browser-linux64-5.0_en-US.tar.xz
 -rw-r--r-- 1 heir loom 176162 Mar 22 01:56 ''$'\243''.html'
 drwxr-xr-x 2 heir loom180 Mar 22 01:56 ''$'\243''_files'
 -rw-r--r-- 1 heir loom  0 Mar 22 01:56 ''$'\302\243''.html'

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25408 [Applications/Tor Browser]: latin-1 supplement characters in filename results in zero-sized downloaded files

[Tor Bug Tracker & Wiki]

#25408: latin-1 supplement characters in filename results in zero-sized 
downloaded
files
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

 * Attachment "out.2.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25580 [Applications/Tor Browser]: Should Tor Browser auto update for me when it starts and it knows it's out of date?

[Tor Bug Tracker & Wiki]

#25580: Should Tor Browser auto update for me when it starts and it knows it's 
out
of date?
--+--
 Reporter:  arma  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:   => ux-team
 * cc: antonela, isabela (added)


Comment:

 Yes, we could improve that experience. In fact, it's already on our
 roadmap (A3.1 in the OTF UX grant is the magic task item as far as the
 design improvements are concerned at least)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25579 [Applications/Tor Browser]: Bump snowflake/go-webrtc again for trac 21312

[Tor Bug Tracker & Wiki]

#25579: Bump snowflake/go-webrtc again for trac 21312
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  snowflake, TorBrowserTeam201803R  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * status:  needs_review => closed
 * keywords:  snowflake => snowflake, TorBrowserTeam201803R
 * resolution:   => fixed


Comment:

 Applied to `master` (commit 0679737202b5a7343314e0ef7f3aa1fefa5cbd6d),
 thanks.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25578 [Applications/Tor Browser]: Package and distribute Tor Browser using Flatpak

[Tor Bug Tracker & Wiki]

#25578: Package and distribute Tor Browser using Flatpak
--+--
 Reporter:  mjog  |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 That's nothing we will spend time on in the foreseeable future. But if
 someone wants to try this out, feel free.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25582 [Core Tor/Tor]: Manual includes non-existant ExitPolicyDefault option

[Tor Bug Tracker & Wiki]

#25582: Manual includes non-existant ExitPolicyDefault option
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Minor |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Back in November I made a few manual fixes which included making its
 **ExitPolicyDefault** line visible...

 https://gitweb.torproject.org/tor.git/commit/?id=3563a2c

 On reflection the tor codebase doesn't look to include any such option. If
 it wasn't for a torrc option then I'm unsure what ExitPolicyDefault was in
 reference to...

 Most likely we should just drop it from the manual.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs