Re: [tor-bugs] #25773 [Applications/Tor Browser]: Disable Speculative Connect and Download

[Tor Bug Tracker & Wiki]

#25773: Disable Speculative Connect and Download
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Or maybe there is even a third thing involved: 3) The external helper app
 dialog is implying the download has not started yet while it indeed has
 (see: comment:2:ticket:18587). So, I agree with that one being confusing
 and we should come up with a better wording for what is happening.
 Historically, it has been a pain getting the message on that dialog right
 but I bet we can improve it further.

--
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] #25777 [Metrics/Ideas]: Create a new service to help relay operators debug their relay

[Tor Bug Tracker & Wiki]

#25777: Create a new service to help relay operators debug their relay
---+--
 Reporter:  irl|  Owner:  metrics-team
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Ideas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Onionoo takes a couple of hours to show new relays in the consensus. The
 #tor channel often sees operators asking if they've set up their relay
 correctly. If they haven't, and they never submit a relay descriptor or
 get included in a consensus, then Relay Search isn't very helpful to them
 at all.

 We can create a service like the automated SSL testers that will connect
 to an operator's relay, ensure that it is reachable, and then perform a
 few additional checks:

 * Get the relay's descriptor from the relay
 * If IPv6 is advertised, check it is reachable
 * Warn if the contact line is not set
 * Warn if family is not set or include relays that are not online

--
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] #25773 [Applications/Tor Browser]: Disable Speculative Connect and Download

[Tor Bug Tracker & Wiki]

#25773: Disable Speculative Connect and Download
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 One final remark for now: "speculative connections" you mentioned here
 have nothing to do with "speculative connections" mentioned in our design
 doc (see: "20. Speculative and prefetched connections"
 https://www.torproject.org/projects/torbrowser/design/#identifier-
 linkability), just to avoid confusion of terminology. For the former, see:
 https://bugzilla.mozilla.org/show_bug.cgi?id=729133.

--
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] #25743 [Applications/Tor Browser]: Orfox users are not able to open cloudflare protected sites (was: Orfox users are not able to open cloudfront protected sites)

[Tor Bug Tracker & Wiki]

#25743: Orfox users are not able to open cloudflare protected sites
--+--
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Old description:

> When an user using the Tor Network tries to access CloudFront protected
> websites such as laravel.com and upwork.com a captcha website opens
> however the captcha image doesn't render.

New description:

 When an user using the Tor Network tries to access CloudFlare protected
 websites such as laravel.com and upwork.com a captcha website opens
 however the captcha image doesn't render.

--

Comment (by gk):

 Changed cloudfront -> cloudflare (as I assume the latter is meant).

--
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] #25777 [Metrics/Ideas]: Create a new service to help relay operators debug their relay

[Tor Bug Tracker & Wiki]

#25777: Create a new service to help relay operators debug their relay
---+--
 Reporter:  irl|  Owner:  metrics-team
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Ideas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 Now that stem has ORPort support, we can connect to the relay's ORPort(s)
 and DirPort, and check they all return descriptors for the same relay.(One
 common misconfiguration is having one port reachable, and the others
 unreachable, and it's not always IPv6 that's unreachable.)

--
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] #25755 [Community/Outreach]: Choose name for new mailing list tor-lang-es

[Tor Bug Tracker & Wiki]

#25755: Choose name for new mailing list tor-lang-es
+
 Reporter:  ilv |  Owner:  alison
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by qbi):

 from https://lists.torproject.org/pipermail/tor-
 project/2018-April/001732.html
 > I'd propose ''tor-talk-es'', because tor-talk is our "main" list and
 attaching an ISO 639 code makes it clear that this is a list for spanish
 language. Furthermore this would allow to extend other lists (tor-dev-es,
 tor-relays-es, etc.) if there is enough interest.

--
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] #25773 [Applications/Tor Browser]: Disable Speculative Connect and Download

[Tor Bug Tracker & Wiki]

#25773: Disable Speculative Connect and Download
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 The final, final one now: see
 https://bugzilla.mozilla.org/show_bug.cgi?id=55690 for arguments why this
 got implemented the way it is.

--
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] #20302 [Obfuscation/FTE]: FTE compilation in our gitian setup is broken for Windows with GCC 6.2.0

[Tor Bug Tracker & Wiki]

#20302: FTE compilation in our gitian setup is broken for Windows with GCC 6.2.0
-+-
 Reporter:  gk   |  Owner:  kpdyer
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Obfuscation/FTE  |Version:
 Severity:  Blocker  | Resolution:  fixed
 Keywords:  tbb-rbm, boklm201804,|  Actual Points:
  TorBrowserTeam201804R  |
Parent ID:  #25420   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Looks good and applied to `master` (commit
 8e21b3462302b724aabae24f32b1a7329a32b06a).

--
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] #25420 [Applications/Tor Browser]: Update gcc to 6.4.0 (Windows)

[Tor Bug Tracker & Wiki]

#25420: Update gcc to 6.4.0 (Windows)
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, boklm201804,|  Actual Points:
  TorBrowserTeam201804R  |
Parent ID:  #24631   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Alright! The browser patches got applied to `tor-browser-52.7.3esr-8.0-1`
 (commits d463bad82114ae420b165f8c3f2a690b9d663a19,
 5a3775152eac3be01e3e947214748e33712bec68, and
 645b11df3349f9045779d1d6c82d6c3722b6b2b2). I merged the build related
 patch to `master` (commit dcce85b6d858d5438bdc68098e846c8ea73c5df6).

--
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] #25737 [Applications/Tor Browser]: Tor Browser's update check bypassed Tor once on macos, because of xpcproxy?

[Tor Bug Tracker & Wiki]

#25737: Tor Browser's update check bypassed Tor once on macos, because of 
xpcproxy?
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-proxy-bypass  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:   => tbb-proxy-bypass


Comment:

 Tentatively putting that into our proxy bypass category even though it
 remains obscure on what is happening.

--
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] #25746 [Applications/rbm]: git_submodule option doesn't work when a submodule is not in the root directory

[Tor Bug Tracker & Wiki]

#25746: git_submodule option doesn't work when a submodule is not in the root
directory
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/rbm |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201804R,  |  Actual Points:
  boklm201804|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Looks good. Applied to `rbm` (commit
 8adbc46dc9e8358abad75ac81faf4646d8165b9e) and incorporated into `tor-
 browser-build` (commit 80a65a334622562272af637b18afbce3d71e03da).

--
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] #25562 [Applications/Tor Browser]: Update Tor Browser Hacking page with Orfox instructions

[Tor Bug Tracker & Wiki]

#25562: Update Tor Browser Hacking page with Orfox instructions
--+
 Reporter:  sysrqb|  Owner:  sysrqb
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tbb-mobile, TorBrowserTeam201804  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * keywords:  tbb-mobile => tbb-mobile, TorBrowserTeam201804


--
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] #17457 [Applications/Tor Messenger]: Implement OMEMO

[Tor Bug Tracker & Wiki]

#17457: Implement OMEMO
+
 Reporter:  arlolra |  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by cypherpunks):

 * cc: cypherpunks (added)


Comment:

 ChatSecure has implemented this as well and it works quite nicely, just
 that mesages are not syncing to Tor Messenger as there's no OMEMO support
 :/

--
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] #13893 [Applications/Tor Browser]: Torbrowser crashes on start when using MS EMET 5.x

[Tor Bug Tracker & Wiki]

#13893: Torbrowser crashes on start when using MS EMET 5.x
-+-
 Reporter:  Diapolo  |  Owner:  gk
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  tbb-security, tbb-crash, tbb-|  Actual Points:
  usability-stoppoint-app, fuck-mingw-gcc,   |
  GeorgKoppen201609, TorBrowserTeam201610,   |
  ff52-esr   |
Parent ID:  #12820   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 We'll update the compiler to GCC 6.4.0 in the next alpha (8.0a6) which
 should fix this issue. Please, open a new one if there are still
 outstanding problems.

--
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] #21537 [Applications/Tor Browser]: Consider ignoring secure cookies for .onion addresses

[Tor Bug Tracker & Wiki]

#21537: Consider ignoring secure cookies for .onion addresses
-+-
 Reporter:  micah|  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability,   |  Actual Points:
  TorBrowserTeam201804R, GeorgKoppen201804   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: pospeselr, mcs, brade, arthuredelstein, sysrqb, igt0 (added)


Comment:

 Replying to [comment:12 pospeselr]:
 > Change looks good, only thing I'd suggest is moving the block at 3340 a
 couple lines up before the Telemetry::Accumulate call ( since the enum
 seems to be a question of cookie security, rather than http(s) ).
 >
 > I also verified the hostURI that's passed in is already normalized, so
 we don't have to worry about case insensitive string compare.

 Thanks. I added the suggested change in `bug_21537_v3`
 (https://gitweb.torproject.org/user/gk/tor-
 browser.git/log/?h=bug_21537_v3). Let me know if that still looks good.

--
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] #25705 [Core Tor/Tor]: Refactor circuit_build_failed to separate build vs path failures

[Tor Bug Tracker & Wiki]

#25705: Refactor circuit_build_failed to separate build vs path failures
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #25546| Points:
 Reviewer:  asn   |Sponsor:  SponsorV-can
--+
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 I don't think arma's concern above was correct. I just tested mike's
 branch (and master) with an offline network and made sure that the
 `MAX_CIRCUIT_FAILURES` spinning protection kicks in. That happens because
 this ticket does not report failures only in the case of '''path selection
 failures'''. In the case of an offline network, the failures are not path
 selection related (they are circuit build related), so the failed circuits
 are counted correctly.

 I took a second look at Mike's patch and looks good to me. Marking this as
 `merge_ready`.

--
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] #25778 [Core Tor]: Can't access anything using TOR

[Tor Bug Tracker & Wiki]

#25778: Can't access anything using TOR
--+--
 Reporter:  greatormesby  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:  connection reset
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36
 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

 Steps to reproduce:
 Version of TOR is 7.5.3

 Went into TOR, trying to go into anything (even test network settings,duck
 duck go or any site) and it wont
 I tried adding bridges (never needed before)
 works fine directly from Firefox or chrome or IE


 Actual results:

 The connection to the server was reset while the page was loading.

 The page you are trying to view cannot be shown because the
 authenticity of the received data could not be verified.
 Please contact the website owners to inform them of this problem.

 Learn more

--
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] #19460 [Core Tor/Tor]: Improve consensus handling of clients with skewed clocks

[Tor Bug Tracker & Wiki]

#19460: Improve consensus handling of clients with skewed clocks
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client timekeeping clock-skew|  Actual Points:
  consensus  |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 A side note:
 TBB (Tor 0.3.2.10) on a 1:40:00 lag machine says "Tor requires an accurate
 clock to work" for 4 hours, but then
 {{{
 Tor NOTICE: No circuits are opened. Relaxed timeout for circuit 4215 (a
 General-purpose client 1-hop circuit in state doing handshakes with
 channel state open) to 6ms. However, it appears the circuit has timed
 out anyway.
 Tor NOTICE: We now have enough directory information to build circuits.
 Tor NOTICE: Tor has successfully opened a circuit. Looks like client
 functionality is working.
 }}}
 Secure sites are working, but is it secure to use TBB in that state?

--
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] #25481 [Applications/Tor Browser]: Ship tor in Tor Browser nightly builds on Linux with Rust enabled

[Tor Bug Tracker & Wiki]

#25481: Ship tor in Tor Browser nightly builds on Linux with Rust enabled
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, GeorgKoppen201804,  |  Actual Points:
  boklm201804, TorBrowserTeam201804R |
Parent ID:  #25220   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-rbm, GeorgKoppen201804, boklm201804, TorBrowserTeam201804
 => tbb-rbm, GeorgKoppen201804, boklm201804, TorBrowserTeam201804R


Comment:

 `bug_25481_v2` (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_25481_v2&id=1f7c6f2ae24c9e79382bd1fdf380bbceac4e4d1c)
 has a patch for this bug up for review. Some notes might be in order,
 though:

 1) Rust needs CMake 3.4.3 at least + LLVM 3.9, and some compiler that
 supports C++-11. It turns out we want the first two anyway during the
 update of our macOS toolchain and g++4.7 is the minimum requirement
 outlined on the rust-lang website. So, we should be good, right? Alas, it
 turns our that's not the case. For one, not all parts we need to build are
 happy with g++ 4.7.2 which Wheezy ships, so we need our own compiler. But,
 two, even salvaging some of our LLVM build efforts are failing: using LLVM
 3.9 crashes the compiler during the cargo build step. See e.g.:
 {{{
   process didn't exit successfully:
 `/var/tmp/build/rustc-1.25.0-src/build/build/bootstrap/debug/rustc
 --crate-name lazycell vendor/lazycell/src/lib.rs --crate-type lib --emit
 =dep-info,link -C opt-level=2 -C metadata=1c971c2102b3dfa3 -C extra-
 filename=-1c971c2102b3dfa3 --out-dir
 /var/tmp/build/rustc-1.25.0-src/build/build/x86_64-unknown-linux-
 gnu/stage2-tools/x86_64-unknown-linux-gnu/release/deps --target x86_64
 -unknown-linux-gnu -L
 dependency=/var/tmp/build/rustc-1.25.0-src/build/build/x86_64-unknown-
 linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/deps -L
 dependency=/var/tmp/build/rustc-1.25.0-src/build/build/x86_64-unknown-
 linux-gnu/stage2-tools/release/deps --cap-lints allow` (signal: 11,
 SIGSEGV: invalid memory reference)
 }}}
 So, I worked around that by building LLVM during the rust compilation
 (which make the whole process taking significantly more time) using that
 version in turn.

 2) The current setup is building basically all the tools which come with
 the `rustc` source tarball. We might only need `rustc` and `cargo`, and
 one way to achieve that might be to split both and build them in separate
 projects. I am fine if we want to pursue this option later on after we got
 the basics working.

 3) There is a bunch of documentation that is getting built during normal
 compilation. I guess we can optimize that away later on and find other
 knobs to produce a smaller toolchain faster.

--
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] #25481 [Applications/Tor Browser]: Ship tor in Tor Browser nightly builds on Linux with Rust enabled

[Tor Bug Tracker & Wiki]

#25481: Ship tor in Tor Browser nightly builds on Linux with Rust enabled
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, GeorgKoppen201804,  |  Actual Points:
  boklm201804, TorBrowserTeam201804R |
Parent ID:  #25220   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  new => needs_review


--
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] #25779 [Applications/Tor Browser]: Ship tor in Tor Browser nightly builds for macOS with Rust enabled

[Tor Bug Tracker & Wiki]

#25779: Ship tor in Tor Browser nightly builds for macOS with Rust enabled
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm, ff60-esr,
 Severity:  Normal   |  boklm201804, TorBrowserTeam201804,
 |  GeorgKoppen201804
Actual Points:   |  Parent ID:  #25220
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Similar to #25481 we want to start shipping tor with Rust support enabled
 in our nightly builds for macOS.

--
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] #25778 [Core Tor]: Can't access anything using TOR

[Tor Bug Tracker & Wiki]

#25778: Can't access anything using TOR
--+--
 Reporter:  greatormesby  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  connection reset  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 > works fine directly from Firefox or chrome or IE

 What do you mean by this?


 >The page you are trying to view cannot be shown because the
 authenticity of the received data could not be verified.
 >Please contact the website owners to inform them of this problem.

 That's the crazy "Secure Connection Failed" warning, do you have Kaspersky
 or some other antivirus installed?

--
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] #25778 [Applications/Tor Browser]: Secure Connection Failed with the Tor Browser (was: Can't access anything using TOR)

[Tor Bug Tracker & Wiki]

#25778: Secure Connection Failed with the Tor Browser
--+--
 Reporter:  greatormesby  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * component:  Core Tor => Applications/Tor Browser
 * keywords:  connection reset =>
 * version:  Tor: unspecified =>
 * milestone:  Tor: unspecified =>
 * owner:  (none) => tbb-team


--
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] #25778 [Applications/Tor Browser]: Secure Connection Failed with the Tor Browser

[Tor Bug Tracker & Wiki]

#25778: Secure Connection Failed with the Tor Browser
--+---
 Reporter:  greatormesby  |  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):

 * status:  new => needs_information


--
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] #25778 [Applications/Tor Browser]: Secure Connection Failed with the Tor Browser

[Tor Bug Tracker & Wiki]

#25778: Secure Connection Failed with the Tor Browser
--+---
 Reporter:  greatormesby  |  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 greatormesby):

 What I meant was I can access websites with any of the browsers mentioned
 but not with TOR.
 I have tried with no anti virus software running and it is still the same
 What is a bit worrying is the first time I tried it in windows 10 (after
 problem occurred in windows 7) it was fine but as soon as I tried to go
 back in the problem started to appear there as well.
 Is this possibly something to do with Virgin Media blocking connection to
 TOR?
 Many thanks for reply

--
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] #25778 [Applications/Tor Browser]: Secure Connection Failed with the Tor Browser

[Tor Bug Tracker & Wiki]

#25778: Secure Connection Failed with the Tor Browser
--+---
 Reporter:  greatormesby  |  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):

 Replying to [comment:4 greatormesby]:
 > What I meant was I can access websites with any of the browsers
 mentioned but not with TOR.
 > I have tried with no anti virus software running and it is still the
 same
 But which one is it? (Usually exiting them isn't enough)

 > Is this possibly something to do with Virgin Media blocking connection
 to TOR?
 You mean https://www.virginmedia.com/? It's working for me with Tor.

 > Many thanks for reply
 You're welcome!

--
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] #25763 [Webpages/Styleguide]: Design a .onion icon

[Tor Bug Tracker & Wiki]

#25763: Design a .onion icon
-+--
 Reporter:  antonela |  Owner:  < antonela >
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Webpages/Styleguide  |Version:
 Severity:  Major| Resolution:
 Keywords:  ux-team  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by elioqoshi):

 I like the 2nd exploration Antonela! They seem like material for GUI
 elements as status indicators. Maybe we can design a proper onion and have
 more abstract shapes like these to indicate onion services?

 These are the onions I designed from scratch.
 https://presentator.ura.design/en/iZZBur31 (you can comment on there like
 in InVision)

 It includes also a potential refresh of the Tor logo to this exact onion.
 The onion body is symmetrical and I was careful that the shape have a
 minimum thickness consistently, so it looks okay also on very small sizes.
 Something we need to keep it mind is that the onion should be as short as
 possible, as icons would ideally fit well into a square (1:1 proportions),
 yet it still need to look like an onion. I shortened the leaves a bit to
 accommodate for that.

 Feedback is welcome

--
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] #25780 [Internal Services/Service - trac]: Move Tor Messenger from Applications/ to Archived/ component

[Tor Bug Tracker & Wiki]

#25780: Move Tor Messenger from Applications/ to Archived/ component
--+-
 Reporter:  arlolra   |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   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] #25778 [Applications/Tor Browser]: Secure Connection Failed with the Tor Browser

[Tor Bug Tracker & Wiki]

#25778: Secure Connection Failed with the Tor Browser
--+---
 Reporter:  greatormesby  |  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 greatormesby):

 It's Kaspersky I normally use.
 As for V.M. they are my ISP and I thought maybe they had started to block
 access to TOR because of the new government initiatives to try and stop
 illegal activities.
 I just find it strange that I have used TOR for several years with no
 problems and now I suddenly get this.

--
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] #25273 [Applications/Tor Browser]: tor browser 7.5 fails to download due to silent filename-too-long errors

[Tor Bug Tracker & Wiki]

#25273: tor browser 7.5 fails to download due to silent filename-too-long errors
--+---
 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):

 just found out it also applies to the applicable %s_files directory
 exceeding 256 chars

--
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] #25691 [Core Tor/Tor]: Bridges don't work: Non-fatal assertion !(exit_ei == NULL) failed in onion_pick_cpath_exit

[Tor Bug Tracker & Wiki]

#25691: Bridges don't work: Non-fatal assertion !(exit_ei == NULL) failed in
onion_pick_cpath_exit
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, 034-must 033-backport|  Actual Points:
  033-maybe-must |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  regression, 034-must => regression, 034-must 033-backport 033
 -maybe-must


--
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] #25692 [Core Tor/Tor]: onion_extend_cpath: Non-fatal assertion info || client failed.

[Tor Bug Tracker & Wiki]

#25692: onion_extend_cpath: Non-fatal assertion info || client failed.
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-must 033-backport regression |  Actual Points:
  chutney 034-included-20180403 033-maybe-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  034-must 033-backport regression chutney 034-included-20180403
 =>
 034-must 033-backport regression chutney 034-included-20180403 033
 -maybe-must


--
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] #25778 [Applications/Tor Browser]: Secure Connection Failed with the Tor Browser

[Tor Bug Tracker & Wiki]

#25778: Secure Connection Failed with the Tor Browser
--+---
 Reporter:  greatormesby  |  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 greatormesby):

 just retried and copied following two logs if they are any help.
 first with bridges
 4/11/2018 15:38:36 PM.000 [NOTICE] DisableNetwork is set. Tor will not
 make or accept non-control network connections. Shutting down all existing
 connections.
 4/11/2018 15:38:36 PM.000 [NOTICE] Opening Socks listener on
 127.0.0.1:9150
 4/11/2018 15:38:41 PM.200 [NOTICE] Bootstrapped 80%: Connecting to the Tor
 network
 4/11/2018 15:38:41 PM.200 [NOTICE] Bootstrapped 85%: Finishing handshake
 with first hop
 4/11/2018 15:38:44 PM.500 [NOTICE] Our directory information is no longer
 up-to-date enough to build circuits: We need more microdescriptors: we
 have 5535/6385, and can only build 59% of likely paths. (We have 85% of
 guards bw, 83% of midpoint bw, and 83% of exit bw = 59% of path bw.)
 4/11/2018 15:38:44 PM.500 [NOTICE] I learned some more directory
 information, but not enough to build a circuit: We need more
 microdescriptors: we have 5535/6385, and can only build 59% of likely
 paths. (We have 85% of guards bw, 83% of midpoint bw, and 83% of exit bw =
 59% of path bw.)
 4/11/2018 15:38:44 PM.500 [NOTICE] We now have enough directory
 information to build circuits.
 4/11/2018 15:38:45 PM.500 [NOTICE] Bootstrapped 90%: Establishing a Tor
 circuit
 4/11/2018 15:38:46 PM.000 [NOTICE] Tor has successfully opened a circuit.
 Looks like client functionality is working.
 4/11/2018 15:38:46 PM.000 [NOTICE] Bootstrapped 100%: Done
 4/11/2018 15:38:47 PM.200 [NOTICE] New control connection opened from
 127.0.0.1.
 4/11/2018 15:38:47 PM.400 [NOTICE] New control connection opened from
 127.0.0.1.
 and then without bridges
 4/11/2018 15:38:36 PM.000 [NOTICE] DisableNetwork is set. Tor will not
 make or accept non-control network connections. Shutting down all existing
 connections.
 4/11/2018 15:38:36 PM.000 [NOTICE] Opening Socks listener on
 127.0.0.1:9150
 4/11/2018 15:38:41 PM.200 [NOTICE] Bootstrapped 80%: Connecting to the Tor
 network
 4/11/2018 15:38:41 PM.200 [NOTICE] Bootstrapped 85%: Finishing handshake
 with first hop
 4/11/2018 15:38:44 PM.500 [NOTICE] Our directory information is no longer
 up-to-date enough to build circuits: We need more microdescriptors: we
 have 5535/6385, and can only build 59% of likely paths. (We have 85% of
 guards bw, 83% of midpoint bw, and 83% of exit bw = 59% of path bw.)
 4/11/2018 15:38:44 PM.500 [NOTICE] I learned some more directory
 information, but not enough to build a circuit: We need more
 microdescriptors: we have 5535/6385, and can only build 59% of likely
 paths. (We have 85% of guards bw, 83% of midpoint bw, and 83% of exit bw =
 59% of path bw.)
 4/11/2018 15:38:44 PM.500 [NOTICE] We now have enough directory
 information to build circuits.
 4/11/2018 15:38:45 PM.500 [NOTICE] Bootstrapped 90%: Establishing a Tor
 circuit
 4/11/2018 15:38:46 PM.000 [NOTICE] Tor has successfully opened a circuit.
 Looks like client functionality is working.
 4/11/2018 15:38:46 PM.000 [NOTICE] Bootstrapped 100%: Done
 4/11/2018 15:38:47 PM.200 [NOTICE] New control connection opened from
 127.0.0.1.
 4/11/2018 15:38:47 PM.400 [NOTICE] New control connection opened from
 127.0.0.1.
 4/11/2018 15:45:26 PM.300 [NOTICE] Switching to guard context "default"
 (was using "bridges")

--
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] #24989 [Core Tor/Tor]: Count hsdir requests against maxcircuitspending

[Tor Bug Tracker & Wiki]

#24989: Count hsdir requests against maxcircuitspending
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  review-group-34, |  Actual Points:
  034-triage-20180328|
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Squashed and merging to 0.3.3 and forward!

--
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] #25333 [Applications/Tor Browser]: NOT SECURE CONECTION please help

[Tor Bug Tracker & Wiki]

#25333: NOT SECURE CONECTION please help
--+---
 Reporter:  kiokawasaki1998   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 #25778 is a 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] #25778 [Applications/Tor Browser]: Secure Connection Failed with the Tor Browser

[Tor Bug Tracker & Wiki]

#25778: Secure Connection Failed with the Tor Browser
--+---
 Reporter:  greatormesby  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

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


Comment:

 Replying to [comment:6 greatormesby]:
 > It's Kaspersky I normally use.
 Thanks, this confirms that it's due to Kaspersky as you can find a
 solution in the other ticket #25333 where a lot of people had the same
 problem.

--
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] #25511 [Core Tor/Tor]: Expose TZ info on control port for better debugging of time errors

[Tor Bug Tracker & Wiki]

#25511: Expose TZ info on control port for better debugging of time errors
-+-
 Reporter:  nickm|  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  roadmap, controller, 034-roadmap-|  Actual Points:
  master, 034-triage-20180328,   |
  034-included-20180328, s8-errors   |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8
-+-
Changes (by nickm):

 * status:  needs_revision => needs_review


--
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] #23617 [Internal Services/Service - trac]: Connectivity issues with trac.torproject.org

[Tor Bug Tracker & Wiki]

#23617: Connectivity issues with trac.torproject.org
--+
 Reporter:  hellais   |  Owner:  qbi
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by hellais):

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


Comment:

 Ah yeah this can be closed.

--
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] #25778 [Applications/Tor Browser]: Secure Connection Failed with the Tor Browser

[Tor Bug Tracker & Wiki]

#25778: Secure Connection Failed with the Tor Browser
--+---
 Reporter:  greatormesby  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 gk, don't you want to add this almost malicious dll to
 WindowsDllBlocklist?

--
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] #25781 [Webpages/Website]: Add press clips to website

[Tor Bug Tracker & Wiki]

#25781: Add press clips to website
--+
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 https://www.torproject.org/press/press.html.en

--
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] #25781 [Webpages/Website]: Add press clips to website

[Tor Bug Tracker & Wiki]

#25781: Add press clips to website
--+
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by steph):

 * Attachment "Press clips for website - 2017 - 2018 - new-1.csv" 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] #25778 [Applications/Tor Browser]: Secure Connection Failed with the Tor Browser

[Tor Bug Tracker & Wiki]

#25778: Secure Connection Failed with the Tor Browser
--+---
 Reporter:  greatormesby  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by greatormesby):

 Did not find that ticket when I looked so I apologise for that and once
 again many thanks for help
 BTW I will use workaround while using TOR and then put settings back but
 will also ask Kaspersky if they have better solution

--
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] #24544 [Core Tor/Tor]: Fix more prop224 spec inconsistencies

[Tor Bug Tracker & Wiki]

#24544: Fix more prop224 spec inconsistencies
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, prop224,   |  Actual Points:
  033-triage-20180320, fast-fix, |
  033-included-20180326, post-stable |
Parent ID:   | Points:  0.3
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by asn):

 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.4.x-final


Comment:

 Triaging this to 0.3.4.

--
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] #25740 [Metrics/Onionoo]: Provide utf8 character instead of escape sequence

[Tor Bug Tracker & Wiki]

#25740: Provide utf8 character instead of escape sequence
-+--
 Reporter:  cypherpunks  |  Owner:  iwakeh
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * status:  accepted => needs_review


Comment:

 Thanks for reporting this issue immediately!

 This wasn't really a regression, but rather a step missing, i.e., valid
 utf escape sequences should be turned into utf characters in addition.
 Please review
 [https://gitweb.torproject.org/user/iwakeh/onionoo.git/commit/?h=task-25740
 this patch 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

Re: [tor-bugs] #23247 [Applications/Tor Browser]: Communicating security expectations for .onion: what to say about different padlock states for .onion services

[Tor Bug Tracker & Wiki]

#23247: Communicating security expectations for .onion: what to say about 
different
padlock states for .onion services
---+--
 Reporter:  isabela|  Owner:  tbb-team
 Type:  project| Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201804  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by brade):

 Replying to [comment:31 isabela]:
 > Cleaned up and updated all stated with icon and copy:
 >
 > https://docs.google.com/document/d/1bPrNLIl7Qy-
 sA7aTfElu80Xk2eXzTfH_5BGTOUDK8XU/edit#

 In looking over the above document, the only scenario that surprised me
 was "HTTPS Site with HTTPS Self-Signed Onion Subresources" which has an
 onion icon (I expected a padlock).

--
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] #25773 [Applications/Tor Browser]: Disable Speculative Connect and Download

[Tor Bug Tracker & Wiki]

#25773: Disable Speculative Connect and Download
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 Replying to [comment:4 gk]:
 > Replying to [ticket:25773 sysrqb]:
 > > As a follow up to #25770, it turns out Tor Browser actually begins
 (and sometimes completes) the download before the user can confirm they
 actually want the-thing. This manifests in #7449 and #11254 as the file
 being downloaded in /tmp (on Unix, or similar on other platforms) and then
 it is moved into the correct directory.
 >
 > I think there are two things that we need to keep separate:
 >
 > 1) The download starting early
 > 2) Using /tmp for saving parts of the download before it is finally
 transferred to the location it should be in.
 >
 > 2) Is a bug and you cited some tickets for it. I am not sure whether 1)
 is a bug, though: the users clicked on the resource indicating that they
 want to have it, no?

 I agree this isn't strictly a bug, but I classify this as a Firefox
 feature that we don't want. I understand why Firefox begins downloading
 the file when a user clicks on the link/button. However, if a users opens
 the context menu of a link and selects "Save Link As...", then I do not
 believe users expect Firefox begins downloading the file until they select
 the destination directory/filename and click "Save".

 The issue with saving files in /tmp is a complete mess, and after reading
 that moz bug I don't know what we should do when a user clicks a link and
 Firefox cannot handle it internally (opening a pdf using pdfjs, show a
 plaintext file directly, etc). We should leave this question for the other
 open /tmp tickets.

 Replying to [comment:5 gk]:
 > Or maybe there is even a third thing involved: 3) The external helper
 app dialog is implying the download has not started yet while it indeed
 has (see: comment:2:ticket:18587). So, I agree with that one being
 confusing and we should come up with a better wording for what is
 happening. Historically, it has been a pain getting the message on that
 dialog right but I bet we can improve it further.

 I originally thought this was worse because the downloading begins before
 the "External App Blocker" is shown, but after I thought about this more I
 didn't think the timing makes a difference. That warning/popup is
 specifically about opening the file, it doesn't say anything about
 downloading. Considering previous pain related to this, I expect showing
 the message earlier will not be easy.

 Replying to [comment:6 gk]:
 > One final remark for now: "speculative connections" you mentioned here
 have nothing to do with "speculative connections" mentioned in our design
 doc (see: "20. Speculative and prefetched connections"
 https://www.torproject.org/projects/torbrowser/design/#identifier-
 linkability), just to avoid confusion of terminology. For the former, see:
 https://bugzilla.mozilla.org/show_bug.cgi?id=729133.

 Oh, interesting, I didn't remember this section. Indeed, these are two
 different features, but maybe they should be treated the same (do not open
 speculative connections when a proxy is configured). (Thanks for
 clarifying that difference before anyone else became confused)

 Replying to [comment:7 gk]:
 > The final, final one now: see
 https://bugzilla.mozilla.org/show_bug.cgi?id=55690 for arguments why this
 got implemented the way it is.

 Right, Mozilla have a couple long bugs and reading them is painful - and
 they're filled with comments about modem lights blinking, T-DSL, and 500MB
 exceeding available memory.

 The reason I opened this bug is because Tor Browser should not begin
 downloading a file unless the user explicitly confirms they want the file
 downloaded and where they want it saved. If clicking "Save Link As..."
 starts any network transactions before the users clicks "Save" within the
 file-chooser dialog box, then Tor Browser should make this obvious. I
 believe Tor Browser should treat the two scenarios differently:

   1) I click on the link and Firefox doesn't know what to do, so it asked
 me where to save the file
   2) I click on "Save Link As..." and specify where I want the file saved
 (or I click cancel)

 Within scenario (1), Firefox cannot know what it should do without
 beginning the download. That's okay. With scenario (2), that is completely
 against what the user requested. This is almost certainly a Firefox bug,
 unfortunately it seems Firefox handles (1) and (2) 

Re: [tor-bugs] #25481 [Applications/Tor Browser]: Ship tor in Tor Browser nightly builds on Linux with Rust enabled

[Tor Bug Tracker & Wiki]

#25481: Ship tor in Tor Browser nightly builds on Linux with Rust enabled
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, GeorgKoppen201804,  |  Actual Points:
  boklm201804, TorBrowserTeam201804R |
Parent ID:  #25220   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Maybe, it's time to get rid of Wheezy as its EOL is May 2018.

--
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:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  regression, 033-must,|  Actual Points:
  033-triage-20180326, 033-included-20180326 |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:15 nickm]:
 > I've done story 2 version as `bug25581_033_v2`.  There's an updated
 version of the story 1 version as `bug25581_033` with some cases I missed.

 `bug25581_033_v2` looks good but the changes file still specifies double
 undescore format.
 If this is fixed, this is good to merge. I can fix this tomorrow!

--
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] #25770 [Applications/Tor Browser]: Connection established before External App Blocker prompt

[Tor Bug Tracker & Wiki]

#25770: Connection established before External App Blocker prompt
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

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


Comment:

 Replying to [comment:1 gk]:
 > Well, how should the external app blocker kick in *without* a connection
 being established first and some indication about what kind of file it is
 that is being requested? That's important, because, as the name says this
 component is only responsible for blocking external apps from kicking in
 and handling file types the browser can't handle itself.

 Okay, this description was not well worded. I now realize this is a little
 complex, after reading the bugs related to #25773. I am most worried about
 the "Save Link As..." situation. I think I'll close this bug as WONTFIX
 because this isn't really the problem.

--
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] #23846 [Core Tor/Tor]: Use libtool for building shared library

[Tor Bug Tracker & Wiki]

#23846: Use libtool for building shared library
-+-
 Reporter:  hellais  |  Owner:  sbs
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api,  |  Actual Points:
  034-triage-20180328 034-included-20180402 034  |
  -roadmap-subtask   |
Parent ID:  #25510   | Points:
 Reviewer:  ahf  |Sponsor:
 |  Sponsor8
-+-

Comment (by ahf):

 I think it would be interesting to hear from sbs if the current code works
 for what you need to use it for?

 Is there a reason in our .gitignore file that we explicitly list the
 `*.lib` and `*.la` files and don't glob them like we do with `*.o` and
 `*.lo`?

 I think overall the patches in Nick's `libtool_hack` branch looks good.
 The above questions are the only ones I have so far.

--
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] #25770 [Applications/Tor Browser]: Connection established before External App Blocker prompt

[Tor Bug Tracker & Wiki]

#25770: Connection established before External App Blocker prompt
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 Replying to [comment:2 gk]:
 > Another important thing to mention here although, looking at your log
 snippet, I am not sure whether it fits: the Torbutton log output is not
 necessarily saying the truth about whether actual connections got made. In
 particular if it is indicating that speculative connections are made
 chances are pretty high that this did not happen. For an analysis see:
 comment:3:ticket:18762 which was affecting a bunch of bugs (e.g. #16324).

 And just as a follow up on this, it is possible the OCSP request is not
 actually happening. I didn't confirm this with tcpdump, however the
 speculative connection and download is happening and I confirmed  with
 tcpdump and server-side logs before opening #25773.

--
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] #23247 [Applications/Tor Browser]: Communicating security expectations for .onion: what to say about different padlock states for .onion services

[Tor Bug Tracker & Wiki]

#23247: Communicating security expectations for .onion: what to say about 
different
padlock states for .onion services
---+--
 Reporter:  isabela|  Owner:  tbb-team
 Type:  project| Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201804  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 Replying to [comment:32 brade]:
 > Replying to [comment:31 isabela]:
 > > Cleaned up and updated all stated with icon and copy:
 > >
 > > https://docs.google.com/document/d/1bPrNLIl7Qy-
 sA7aTfElu80Xk2eXzTfH_5BGTOUDK8XU/edit#
 >
 > In looking over the above document, the only scenario that surprised me
 was "HTTPS Site with HTTPS Self-Signed Onion Subresources" which has an
 onion icon (I expected a padlock).
 Padlock downgrades to onion icon to reflect "Self-Signed Onion" trick.

--
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] #25773 [Applications/Tor Browser]: Disable Speculative Connect and Download

[Tor Bug Tracker & Wiki]

#25773: Disable Speculative Connect and Download
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 Replying to [comment:8 sysrqb]:
 > Within scenario (1), Firefox cannot know what it should do without
 beginning the download. That's okay. With scenario (2), that is completely
 against what the user requested. This is almost certainly a Firefox bug,
 unfortunately it seems Firefox handles (1) and (2) using the same logic.

 Hrm, and this is related to #22649 (coming from #25672). But, to clarify,
 it may be that #22649 is resolved if "Save Link As..." does not use a
 speculative connection. If it uses a connection created within the context
 of the current first party domain, then maybe the download will use the
 correct circuit.

--
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] #25737 [Applications/Tor Browser]: Tor Browser's update check bypassed Tor once on macos, because of xpcproxy?

[Tor Bug Tracker & Wiki]

#25737: Tor Browser's update check bypassed Tor once on macos, because of 
xpcproxy?
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-proxy-bypass  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 I'm the OP, someone else is using the cypherpunks account: such as in 1,
 6, 8, 13 and 15. Just to clarify.

 > Yet another reason for using Tails/Subgraph/Whonix.

 Unfortunately we need to work with Macs, using a separate workstation for
 browsing is too uncomfortable. We tried these days and it didn't worked
 out well. But Tor is part of our security posture, in the past we have
 been targeted and suffered a number of minor data breaches.

 > Logs and cache of what? The application firewall?

 The logs and cache of the dns resolver. Which means the process did a DNS
 lookup on that name, around that time.

 We are sure no outgoing connection has ever been made, because the
 firewall and the transparent proxy never logged any attempted bypass. I
 called it an isolating proxy because it inspects the traffic and blocks
 everything, except done for the connections to Apple, the bridge and our
 own IPs, redirecting each kind of traffic on a different route.

 > Oh, another thing that might be interesting the next time is seeing the
 process hierarchy by clicking on the respective LuLu icon on the alert
 window.

 Did this: `launchd` -> `/usr/libexec/xpcproxy`. But I can not remember
 anything more specific than this now.

 > At some point in the past, the default browser proxy preferences were
 modified.

 No preferences were modified: after the bundle installation, I inserted
 the bridge, closed the browser, opened ~/Library/Application Support
 /TorBrowser-Data/Tor/torrc and added `UseBridges 1`. Only usual browsing
 activity from thereon.

 > I'm not sure I have anything to suggest besides using
 dtrace/lldb/something to capture the full stacktrace from XPCproxy when it
 makes the DNS lookup.

 > So instructing the user to run "ps -ef|grep xpcproxy" might give us the
 arguments to xpcproxy at the time. Since it's basically a launcher, we
 want to know what it's launching that is doing the https requests.

 Will do it if it happens again.

 > If you're using LittleSnitch as your application firewall, it sometimes
 logs connections against the wrong process.

 Denying the outgoing connection blocked the progress of the launcher and
 the browser window never popped up. So, I find this unlikely. But maybe
 I'm missing something here?

--
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] #23247 [Applications/Tor Browser]: Communicating security expectations for .onion: what to say about different padlock states for .onion services

[Tor Bug Tracker & Wiki]

#23247: Communicating security expectations for .onion: what to say about 
different
padlock states for .onion services
---+--
 Reporter:  isabela|  Owner:  tbb-team
 Type:  project| Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201804  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by tom):

 Replying to [comment:32 brade]:
 > Replying to [comment:31 isabela]:
 > > Cleaned up and updated all stated with icon and copy:
 > >
 > > https://docs.google.com/document/d/1bPrNLIl7Qy-
 sA7aTfElu80Xk2eXzTfH_5BGTOUDK8XU/edit#
 >
 > In looking over the above document, the only scenario that surprised me
 was "HTTPS Site with HTTPS Self-Signed Onion Subresources" which has an
 onion icon (I expected a padlock).

 Yes, I think it should have a padlock. I think isa may have missed this
 case when e updated the other ones in this section?

--
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] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201804  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by mcs):

 I like the idea of moving the UI for changing the security level into
 about:preferences.  However, nearly everything in about:preferences is
 "instant apply" (changes take effect immediately) which may make it more
 difficult for people to learn about the different security levels before
 they decide to change their level.

 In the existing dialog-based UI users can learn what the different levels
 do via two methods: (1) tooltips and (2) they can move the slider to the
 different positions to reveal descriptive text (since the actual security
 level is not changed until they dismiss the dialog). We could use tooltips
 in about:preferences, but maybe we can also come up with a more obvious
 way for people to learn about the different security level choices. For
 example, if we use three radio buttons instead of a slider control we
 might be able to simply include the descriptive text nearby (that might be
 crowded 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

[tor-bugs] #25782 [Metrics/Consensus Health]: Bump stem for depictor

[Tor Bug Tracker & Wiki]

#25782: Bump stem for depictor
--+-
 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:|
--+-
 {{{
 11:10:15 A<+atagar> tjr: You'll find that depictor will have timeouts too
 when you update Stem. Stem now drops the '.z' suffix and replaces it with
 an Accept-Encoding header...
 11:10:18 A<+atagar>
 https://gitweb.torproject.org/stem.git/commit/?id=079b481
 11:10:38 A<+atagar> To cut down on noise DocTor no longer downloads from
 tor26.
 11:11:00 T<+tjr> Hm... I don't think that's going to be an option for
 me...
 11:11:26 A<+atagar> Why?
 11:11:56 A<+atagar> I did a similar thing for turtles back in the day.
 Certainly understandable though if it's a no-go. :)
 11:12:04 A<+atagar> I suppose we might be able to hack around it.
 11:12:36 T<+tjr> Well, I suppose I could get the vote from another
 DirAuth.  But not downloading would mean they would fall off (or have bad
 data) for the download times table
 11:12:46 T<+tjr> Not that that table is terribly accurate today but
 11:13:18 A<+atagar> Gotcha. For DocTor the hack I did was to simply stop
 treating tor26 as a dirauth.
 11:13:44 A<+atagar> Ah, I've got an idea.
 11:14:17 A<+atagar> The DescriptorDownloader should return you a query
 object. You can overwrite the resource attribute to add back the '.z'
 before making the request.
 11:14:45 A<+atagar> Since the stripping happens in the constructor...
 11:14:46 A<+atagar>
 https://gitweb.torproject.org/stem.git/tree/stem/descriptor/remote.py#n370
 11:16:01 A<+atagar> Note that you'll want to include 'start = False' in
 your call so the request isn't made until you change the resource.
 }}}

--
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] #20224 [Metrics/CollecTor]: Fix `BridgeDescriptorMappingsLimit` config option

[Tor Bug Tracker & Wiki]

#20224: Fix `BridgeDescriptorMappingsLimit` config option
---+--
 Reporter:  karsten|  Owner:  iwakeh
 Type:  defect | Status:  needs_review
 Priority:  Low|  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-2018   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by iwakeh):

 * status:  accepted => needs_review


Comment:

 Please review
 [https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-20224
 this patch commit].

--
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: #20224, #20351

[Tor Bug Tracker & Wiki]

Batch modification to #20224, #20351 by iwakeh:
milestone to CollecTor 1.6.0

--
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] #25773 [Applications/Tor Browser]: Disable Speculative Connect and Download

[Tor Bug Tracker & Wiki]

#25773: Disable Speculative Connect and Download
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 Replying to [comment:8 sysrqb]:
 > Within scenario (1), Firefox cannot know what it should do without
 beginning the download. That's okay. With scenario (2), that is completely
 against what the user requested. This is almost certainly a Firefox bug,
 unfortunately it seems Firefox handles (1) and (2) using the same logic.

 Of course, Firefox wants to handle (2) in a smart way:

 {{{
 // an object to proxy the data through to
 // nsIExternalHelperAppService.doContent, which will wait for the
 // appropriate MIME-type headers and then prompt the user with a
 // file picker
 }}}
 https://gitweb.torproject.org/tor-
 browser.git/tree/browser/base/content/nsContextMenu.js?h=tor-
 browser-52.7.3esr-7.5-1-build1#n1265

 I wonder if we can simply use the timeout case instead, and skip the async
 fetch (?):
 {{{
   onStopRequest: function saveLinkAs_onStopRequest(aRequest, aContext,
aStatusCode) {
 if (aStatusCode == NS_ERROR_SAVE_LINK_AS_TIMEOUT) {
   // do it the old fashioned way, which will pick the best
 filename
   // it can without waiting.
   saveURL(linkURL, linkText, dialogTitle, bypassCache, false,
 docURI,
   doc);
 }
 }}}
 https://gitweb.torproject.org/tor-
 browser.git/tree/browser/base/content/nsContextMenu.js?h=tor-
 browser-52.7.3esr-7.5-1-build1#n1319

--
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] #24797 [Core Tor/Tor]: Add an option that makes Tor use fewer connections

[Tor Bug Tracker & Wiki]

#24797: Add an option that makes Tor use fewer connections
-+-
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

 * status:  new => assigned
 * cc: neel@… (added)
 * owner:  (none) => neel


--
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] #25695 [Applications/Tor Browser]: Activity 5.1: Redesign Tor Browser homepage ("about:tor") - create an user onboard

[Tor Bug Tracker & Wiki]

#25695: Activity 5.1: Redesign Tor Browser homepage ("about:tor") - create an 
user
onboard
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201804  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by antonela):

 Replying to [comment:3 cypherpunks]:

 > If you want to test it in its Mozilla form download nightly and enable
 it using https://searchfox.org/mozilla-
 central/source/browser/extensions/onboarding/README.md#how-to-show-the-
 onboarding-tour

 Thanks! So useful :)

--
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] #25783 [Core Tor/Tor]: Circuit creation loop when primary guards are unreachable

[Tor Bug Tracker & Wiki]

#25783: Circuit creation loop when primary guards are unreachable
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.10
 Severity:  Normal|   Keywords:  tor-guard
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  SponsorV-can  |
--+
 I was offline for a few hours today while Tor was running. At some point I
 went back online but I noticed that Tor was stuck on a circuit creation
 loop which it did not exit until it marked one of its primary guards as
 retriable (which can take lots of time). While in the loop, Tor made one
 circuit per second.

 I spent a good part of today debugging this. I think the issue is that our
 guard algorithm changes the circuit state of circuits that don't use
 primary guards to `CIRCUIT_STATE_GUARD_WAIT` in
 `circuit_build_no_more_hops()`. Then in `circuit_expire_building()` we
 consider those waiting circuits as not `CIRCUIT_STATE_OPEN` and expire
 them quickly with the 2s build timeout. Then we make more, and then expire
 them, ad infinitum, until a primary guards becomes retriable and breaks
 the circle.

 Here is the loop

 

 Tor thinks it needs a pre-emptive circuit:
 {{{
 Apr 11 14:47:21.000 [info] circuit_build_times_set_timeout(): Set circuit
 build timeout to 2s (1500.00ms, 6.00ms, Xm: 525, a: 2.177536,
 r: 0.121588) based on 403 circuit times
 Apr 11 14:47:21.000 [info] circuit_predict_and_launch_new(): Have 4 clean
 circs (3 internal), need another exit circ.
 Apr 11 14:47:21.000 [info] origin_circuit_new(): Circuit 139 chose an idle
 timeout of 2967 based on 2875 seconds of predictive building remaining.
 }}}
 Tor picks guard, picks timeouts and connects to it:
 {{{
 Apr 11 14:47:21.000 [warn] No primary guards available. Selected confirmed
 guard ENiGMA ($42B4F52C5B11E4D39855F654955425B0D5A0598B) for circuit. Will
 try other guards before using this circuit.
 Apr 11 14:47:22.000 [warn] Recorded success for confirmed guard ENiGMA
 ($42B4F52C5B11E4D39855F654955425B0D5A0598B)
 Apr 11 14:47:22.000 [info] circuit_build_no_more_hops(): circuit built!
 }}}
 Tor marks the circuit as timeout by calling
 `circuit_build_times_mark_circ_as_measurement_only()` in
 `circuit_expire_building()` and starts making a new predictive circuit
 (loop!):
 {{{
 Apr 11 14:47:23.000 [info] circuit_expire_building(): Deciding to count
 the timeout for circuit 139
 Apr 11 14:47:23.000 [info] circuit_predict_and_launch_new(): Have 4 clean
 circs (3 internal), need another exit circ.
 }}}
 after a minute finally Tor ditches circuit which has been repurposed as
 `CIRCUIT_PURPOSE_C_MEASURE_TIMEOUT`:
 {{{
 Apr 11 14:48:22.000 [info] circuit_expire_building(): Deciding to count
 the timeout for circuit 139
 Apr 11 14:48:22.000 [info] circuit_expire_building(): Abandoning circ 139
 5.9.121.207:443:2179853168 (state 0,3:waiting to see how other guards
 perform, purpose 14, len 3)
 Apr 11 14:48:22.000 [info] pathbias_check_close(): Circuit 139 remote-
 closed without successful use for reason -3. Circuit purpose 14 currently
 0,waiting to see how other guards perform. Len 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] #25754 [Core Tor/Tor]: Make Prop#291 choices

[Tor Bug Tracker & Wiki]

#25754: Make Prop#291 choices
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-roadmap-subtask, tor-guard,  |  Actual Points:
  guard-discovery|
Parent ID:  #25546   | Points:
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-

Comment (by asn):

 Example of bug that might become more prevalent if we reduce the size of
 primary guards: #25783

--
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] #25695 [Applications/Tor Browser]: Activity 5.1: Redesign Tor Browser homepage ("about:tor") - create an user onboard

[Tor Bug Tracker & Wiki]

#25695: Activity 5.1: Redesign Tor Browser homepage ("about:tor") - create an 
user
onboard
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201804  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---
Changes (by antonela):

 * Attachment "25695.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] #25695 [Applications/Tor Browser]: Activity 5.1: Redesign Tor Browser homepage ("about:tor") - create an user onboard

[Tor Bug Tracker & Wiki]

#25695: Activity 5.1: Redesign Tor Browser homepage ("about:tor") - create an 
user
onboard
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201804  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by antonela):

 Hi! I put together the first approach for this task. I'm trying to get
 into consideration all the suggestions made by the previously mentioned
 tickets.

 https://trac.torproject.org/projects/tor/attachment/ticket/25695/25695.png

 I'd like to be on the same page with devs about the different use cases.

 Using F60 onboarding is a great idea! I think we can use it.

 Copy is up to creation/review.

--
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] #25783 [Core Tor/Tor]: Circuit creation loop when primary guards are unreachable

[Tor Bug Tracker & Wiki]

#25783: Circuit creation loop when primary guards are unreachable
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.10
 Severity:  Normal| Resolution:
 Keywords:  tor-guard |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  SponsorV-can
--+

Comment (by cypherpunks):

 Maybe this is the issue underlying #25600

--
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:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  regression, 033-must,|  Actual Points:
  033-triage-20180326, 033-included-20180326 |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

 * status:  needs_revision => merge_ready


Comment:

 Pushed `bug25581_033_v2` in my repo with a fix for the changes file above.
 Feel free to merge directly.

--
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] #24796 [Applications/Tor Browser]: Review all requested and required Android permissions

[Tor Bug Tracker & Wiki]

#24796: Review all requested and required Android permissions
--+---
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  task  | Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:  #5709 | Points:
 Reviewer:|Sponsor:
--+---
Changes (by sysrqb):

 * status:  new => needs_information


Comment:

 Fennec currently requests/requires a large set of permissions. We should
 be able to reduce this. If we include the permissions requested by Fennec
 (base) and GeckoView, they are:

 {{{
 android.hardware.camera
 android.hardware.camera.autofocus
 android.hardware.location
 android.hardware.location.gps
 android.hardware.touchscreen
 android.permission.ACCESS_COARSE_LOCATION
 android.permission.ACCESS_FINE_LOCATION
 android.permission.ACCESS_NETWORK_STATE
 android.permission.ACCESS_WIFI_STATE
 android.permission.AUTHENTICATE_ACCOUNTS
 android.permission.CAMERA
 android.permission.CHANGE_WIFI_STATE
 android.permission.GET_ACCOUNTS
 android.permission.INTERNET
 android.permission.MANAGE_ACCOUNTS
 android.permission.READ_EXTERNAL_STORAGE
 android.permission.READ_SYNC_SETTINGS
 android.permission.READ_SYNC_STATS
 android.permission.RECEIVE_BOOT_COMPLETED
 android.permission.SYSTEM_ALERT_WINDOW
 android.permission.USE_CREDENTIALS
 android.permission.VIBRATE
 android.permission.WAKE_LOCK
 android.permission.WRITE_EXTERNAL_STORAGE
 android.permission.WRITE_SETTINGS
 android.permission.WRITE_SYNC_SETTINGS
 com.android.browser.permission.READ_HISTORY_BOOKMARKS
 com.android.launcher.permission.INSTALL_SHORTCUT
 com.android.launcher.permission.UNINSTALL_SHORTCUT
 }}}

 This includes permissions and features. Orfox already excludes some of the
 above (via compile-time pre-processor guards):
 {{{
 android.permission.CHANGE_WIFI_STATE
 android.permission.ACCESS_WIFI_STATE
 android.permission.ACCESS_FINE_LOCATION
 android.hardware.location
 android.hardware.location.gps
 android.permission.CAMERA
 android.hardware.camera
 android.hardware.camera.autofocus
 android.permission.GET_ACCOUNTS
 android.permission.ACCESS_NETWORK_STATE
 android.permission.MANAGE_ACCOUNTS
 }}}

 I think we can inherit this during the #25741 rebase, and audit the
 remaining perms after (or in parallel).

--
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] #24796 [Applications/Tor Browser]: Review all requested and required Android permissions

[Tor Bug Tracker & Wiki]

#24796: Review all requested and required Android permissions
--+---
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  task  | Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:  #5709 | Points:
 Reviewer:|Sponsor:
--+---

Comment (by sysrqb):

 Replying to [comment:5 sysrqb]:
 > Fennec currently requests/requires a large set of permissions. We should
 be able to reduce this. If we include the permissions requested by Fennec
 (base) and GeckoView, they are:
 >
 Plus GCM (Google Cloud Messaging), and Orfox already excludes these, too:

 {{{
 com.google.android.c2dm.permission.RECEIVE
 }}}

 There are other GCM permissions requested when MOZ_ANDROID_GCM is defined,
 but we don't define it, so I'm not including them in this list (see
 `GcmAndroidManifest_services.xml.in`).

--
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] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201804  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---
Changes (by antonela):

 * Attachment "25658 - Settings Radio.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] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201804  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by antonela):

 Thanks for the comment @mcs!

 Replying to [comment:10 mcs]:
 > I like the idea of moving the UI for changing the security level into
 about:preferences.  However, nearly everything in about:preferences is
 "instant apply" (changes take effect immediately) which may make it more
 difficult for people to learn about the different security levels before
 they decide to change their level.
 >

 Yes, indeed.

 > In the existing dialog-based UI users can learn what the different
 levels do via two methods: (1) tooltips and (2) they can move the slider
 to the different positions to reveal descriptive text (since the actual
 security level is not changed until they dismiss the dialog). We could use
 tooltips in about:preferences, but maybe we can also come up with a more
 obvious way for people to learn about the different security level
 choices. For example, if we use three radio buttons instead of a slider
 control we might be able to simply include the descriptive text nearby
 (that might be crowded though).


 To be honest, and as I said before, I think the slider is not the best
 solution for this UX at the moment. But, I know that people have been
 calling this feature security-slider for a while and I'm not sure about
 how hard could be this change for them.

 That said, I love the idea about to have three simply radio buttons with
 each description. In that case, we will continue having the confirmation
 step before seeing the changes.

 I made a mockup to see how it looks :) See here

 
https://trac.torproject.org/projects/tor/attachment/ticket/25658/25658%20-%20Settings%20Radio.png

--
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] #24797 [Core Tor/Tor]: Add an option that makes Tor use fewer connections

[Tor Bug Tracker & Wiki]

#24797: Add an option that makes Tor use fewer connections
-+-
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by neel):

 So, should I implement an option which sets the maximum number of
 connections (meaning Tor can't go over this)?

--
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] #24797 [Core Tor/Tor]: Add an option that makes Tor use fewer connections

[Tor Bug Tracker & Wiki]

#24797: Add an option that makes Tor use fewer connections
-+-
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 This one is tricky, because if we have such an option, and a Tor relay
 sets it and hits the limit, then the relay will start behaving badly.

 We really need our relays to never hit their limit. Anything else is bad.

--
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] #25061 [Core Tor/Tor]: Relays consider it a bootstrapping failure if they can't extend for somebody else's circuit

[Tor Bug Tracker & Wiki]

#25061: Relays consider it a bootstrapping failure if they can't extend for
somebody else's circuit
-+-
 Reporter:  arma |  Owner:
 |  catalyst
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  backport-032, 033-must, stability,   |  Actual Points:
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by catalyst):

 Replying to [comment:8 arma]:
 > You'll notice that somewhere along the line we wrapped those calls with
 > {{{
 >if (!authdir_mode_tests_reachability(options)
 > }}}
 >
 > Commit d37fae2f is the commit from ancient history to skim, and commit
 818332e7 is the more recent commit in this area that should give you some
 more context.
 It looks like commit c6a94718cd was the one that introduced the silencing
 of connection problems for dirauths.

 Also some of the calls to `authdir_mode_tests_reachability()` are indirect
 through `connection_or_connect_failed()`.

--
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] #25764 [Applications/Tor Browser]: TBA - Activity 4.1: Improve how circuits are displayed to the user

[Tor Bug Tracker & Wiki]

#25764: TBA - Activity 4.1: Improve how circuits are displayed to the user
---+--
 Reporter:  antonela   |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201804  |  Actual Points:
Parent ID:  #24309 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by mcs):

 * Attachment "FF60-site-info-tablet-portrait.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] #25764 [Applications/Tor Browser]: TBA - Activity 4.1: Improve how circuits are displayed to the user

[Tor Bug Tracker & Wiki]

#25764: TBA - Activity 4.1: Improve how circuits are displayed to the user
---+--
 Reporter:  antonela   |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201804  |  Actual Points:
Parent ID:  #24309 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by mcs):

 * Attachment "FF60-site-info-tablet-landscape.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] #25735 [Applications/Tor Browser]: Tor Browser stalls while loading Facebook login page (Waiting for static.xx.fbcdn.net)

[Tor Bug Tracker & Wiki]

#25735: Tor Browser stalls while loading Facebook login page (Waiting for
static.xx.fbcdn.net)
--+---
 Reporter:  uzi   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by uzi):

 Tried on a third machine, Win 7, another internet connection, antivirus
 uninstalled, no firewall - same behavior.

 Am I really the only one who experiences this?

--
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] #25764 [Applications/Tor Browser]: TBA - Activity 4.1: Improve how circuits are displayed to the user

[Tor Bug Tracker & Wiki]

#25764: TBA - Activity 4.1: Improve how circuits are displayed to the user
---+--
 Reporter:  antonela   |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201804  |  Actual Points:
Parent ID:  #24309 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by mcs):

 We talked a little about possible differences btw. small devices and
 tablets. I attached some screenshots from Firefox 60 beta running on my
 (admittedly, old) 7" Android tablet.

--
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:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:  fixed
 Keywords:  regression, 033-must,|  Actual Points:
  033-triage-20180326, 033-included-20180326 |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Merging!

--
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] #25735 [Applications/Tor Browser]: Tor Browser stalls while loading Facebook login page (Waiting for static.xx.fbcdn.net)

[Tor Bug Tracker & Wiki]

#25735: Tor Browser stalls while loading Facebook login page (Waiting for
static.xx.fbcdn.net)
--+---
 Reporter:  uzi   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 Replying to [comment:5 uzi]:
 > Tried on a third machine, Win 7, another internet connection, antivirus
 uninstalled, no firewall - same behavior.
 Did you try with `https://facebookcorewwwi.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] #25735 [Applications/Tor Browser]: Tor Browser stalls while loading Facebook login page (Waiting for static.xx.fbcdn.net)

[Tor Bug Tracker & Wiki]

#25735: Tor Browser stalls while loading Facebook login page (Waiting for
static.xx.fbcdn.net)
--+---
 Reporter:  uzi   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by uzi):

 https://facebookcorewwwi.onion/ works 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

Re: [tor-bugs] #24797 [Core Tor/Tor]: Add an option that makes Tor use fewer connections

[Tor Bug Tracker & Wiki]

#24797: Add an option that makes Tor use fewer connections
-+-
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by neel):

 Replying to [comment:8 arma]:


 > This one is tricky, because if we have such an option, and a Tor relay
 sets it and hits the limit, then the relay will start behaving badly.
 >
 > We really need our relays to never hit their limit. Anything else is
 bad.

 Thank You.

 I noticed this function in `src/common/compat.c`:

 {{{
 int set_max_file_descriptors(rlim_t limit, int *max_out)
 }}}

 Should I be working with the function above? I am thinking about an
 argument to this function with the total maximum number of connections Tor
 will take (and using that value as an alternative to the maximum number of
 file descriptors) which will in turn be used to set `max_sockets` in
 `src/common/compat.c` and the `ConnLimit_` option from the call to
 `set_max_file_descriptors()` in `config.c`. The argument will be based on
 an option I will add (if I work on this patch). If this option is `0` or
 left unset, it will default to using the number of file descriptors like
 Tor does right 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

Re: [tor-bugs] #21537 [Applications/Tor Browser]: Consider ignoring secure cookies for .onion addresses

[Tor Bug Tracker & Wiki]

#21537: Consider ignoring secure cookies for .onion addresses
-+-
 Reporter:  micah|  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability,   |  Actual Points:
  TorBrowserTeam201804R, GeorgKoppen201804   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Replying to [comment:13 gk]:
 > Replying to [comment:12 pospeselr]:
 > > Change looks good, only thing I'd suggest is moving the block at 3340
 a couple lines up before the Telemetry::Accumulate call ( since the enum
 seems to be a question of cookie security, rather than http(s) ).
 > >
 > > I also verified the hostURI that's passed in is already normalized, so
 we don't have to worry about case insensitive string compare.
 >
 > Thanks. I added the suggested change in `bug_21537_v3`
 (https://gitweb.torproject.org/user/gk/tor-
 browser.git/log/?h=bug_21537_v3). Let me know if that still looks good.

 The code looks good to me, but I would suggest factoring out the repeated
 security checks by creating a static function like:
 `bool IsSecureHost(nsIURI *aHostURI)`
 that returns true for both https and .onion URIs.

--
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] #25731 [Applications/Tor Browser]: windows hidden service bug

[Tor Bug Tracker & Wiki]

#25731: windows hidden service bug
--+---
 Reporter:  Ga15  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by Ga15):

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


Comment:

 Okay got back to version where I know it worked so not a bug. I will try
 to post results when I found what is wrong.

--
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] #24797 [Core Tor/Tor]: Add an option that makes Tor use fewer connections

[Tor Bug Tracker & Wiki]

#24797: Add an option that makes Tor use fewer connections
-+-
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Careful here! That function is about trying to move us to the highest
 maximum we can get from the system. It is not about having Tor limit the
 number that it will use. I think.

--
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] #25511 [Core Tor/Tor]: Expose TZ info on control port for better debugging of time errors

[Tor Bug Tracker & Wiki]

#25511: Expose TZ info on control port for better debugging of time errors
-+-
 Reporter:  nickm|  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  roadmap, controller, 034-roadmap-|  Actual Points:
  master, 034-triage-20180328,   |
  034-included-20180328, s8-errors   |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8
-+-
Description changed by catalyst:

Old description:

> When we tell people that their clocks are wrong, it's frequently because
> they've set up their systems with the wrong time zone.  It would be
> helpful to tell torbrowser (or some other controller) about this
> information, so that it can give more useful error messages on time-
> related bootstrapping failures.
>
> One complication here is (IIUC) TB runs, and runs tor, with its TZ set to
> UTC.

New description:

 When we tell people that their clocks are wrong, it's frequently because
 they've set up their systems with the wrong time zone.  It would be
 helpful to tell torbrowser (or some other controller) about this
 information, so that it can give more useful error messages on time-
 related bootstrapping failures.

 ~~One complication here is (IIUC) TB runs, and runs tor, with its TZ set
 to UTC.~~

 Further investigation suggests that TB might not set `TZ` for the first
 time it starts 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] #25735 [Applications/Tor Browser]: Tor Browser stalls while loading Facebook login page (Waiting for static.xx.fbcdn.net)

[Tor Bug Tracker & Wiki]

#25735: Tor Browser stalls while loading Facebook login page (Waiting for
static.xx.fbcdn.net)
--+--
 Reporter:  uzi   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  needs_information => new


Comment:

 > Reproducibility: nearly 100%
 And thanks for the detailed description. It's up to developers now to find
 out what's up.

--
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] #25735 [Applications/Tor Browser]: Tor Browser stalls while loading Facebook login page (Waiting for static.xx.fbcdn.net)

[Tor Bug Tracker & Wiki]

#25735: Tor Browser stalls while loading Facebook login page (Waiting for
static.xx.fbcdn.net)
--+--
 Reporter:  uzi   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 I wonder whether this is a duplicate of/related to #21924, gk says there:

 > **This change e.g. if I go to Trac in a new tab. Suddenly the icon on
 the former tab stops spinning and all is fine.** This happens at least
 with a 64bit Linux.
 >
 > (Sorry for the vague bug report :) )

 Which seems to be the same case here (except the bug report is more
 precise :) ).

--
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] #25735 [Applications/Tor Browser]: Tor Browser stalls while loading Facebook login page (Waiting for static.xx.fbcdn.net)

[Tor Bug Tracker & Wiki]

#25735: Tor Browser stalls while loading Facebook login page (Waiting for
static.xx.fbcdn.net)
--+--
 Reporter:  uzi   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Maybe bugs like these can be simulated with a `firejail
 --bandwidth=torbrowser set eth0 5 6` or worse, I don't know, but it seems
 like this is due to static.xx.fbcdn.net being overloaded by exits, and it
 took time to load up and something weird happened. If I recall trac.tp.o
 had also some overloading issues at the time, maybe that's why gk was
 experiencing a similar bug at the time.

--
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] #24797 [Core Tor/Tor]: Add an option that makes Tor use fewer connections

[Tor Bug Tracker & Wiki]

#24797: Add an option that makes Tor use fewer connections
-+-
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Don't change set_max_file_descriptors(), it works well, and does exactly
 what arma says: gets the most file descriptors from the system.

 Instead, look at the out of socket check code. It is enabled by
 "DisableOOSCheck 0". It uses the socket limit that
 set_max_file_descriptors() discovers from the system. But you could add a
 torrc option that allows the user to set a lower limit for the out of
 socket check. It would only work if the out of socket check was enabled.

 Then the tor process could have the maximum number of sockets available,
 but choose not to use them. (For example, during the extra client load, I
 would have set the socket limit to half the number of file descriptors, so
 that the connection closing logic ran less frequently.)

 Since I opened this ticket, we also added DoSConnectionMaxConcurrentCount.
 Maybe that makes this ticket less important?
 But it would still be good for operators who run all their tor instances
 under the same user.

--
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:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-sandboxing,  |  Actual Points:
  TorBrowserTeam201804R  |
Parent ID:  #20773   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 Audited all the remaining syscalls (was only catch'ing open and openat
 before) and discovered three more things which don't seem to be an issue
 for us.  Here's the full list of what we're working with (on x64 Linux)
 roughly in order of invocation for future reference (open here covers both
 open and openat, didn't save that data unfortunately):

 ||= Caller =||= syscall =||= Requested Path =||= Relevant Source ||
 || mozilla::HasUserNamespaceSupport() || access || "/proc/self/ns/user" ||
 /security/sandbox/linux/SandboxInfo.cpp ||
  Failure here 'just' disables 'User Namespaces' (as shown under
 the Sandbox section of about:support), not sure what the security
 consequences of this is but tor browser boots and runs fine ||
 || selinuxfs_exists() || open ||"/proc/filessytems" ||  ||
  This call happens down in dlopen when opening libxul.so. Failure
 to open this file will result in selinxufs_exists() always reporting
 selinuxfs exists ( see
 
[https://github.com/SELinuxProject/selinux/blob/64afa1aff1cd610d2493f780e2a44b551f668b84/libselinux/src/init.c#L56
 selinuxfs_exists(void)] but everything seems to go along even if it is a
 false positive) ||
 || mozilla::(anonymous namespace)::IsSingleThreaded () || xstat ||
 "/proc/self/task" || /security/sandbox/linux/SandboxInfo.cpp ||
  Failure to read and count number of files under this directory
 causes tor browser to guess and indicate that it is not single threaded ||
 || mozilla::ComputeProcessUptimeThread(void*) || open ||
 "/proc/self/task/$tid/stat", "/proc/self/stat" ||
 /mozglue/misc/TimeStamp_posix.cpp ||
  This code fails gracefully and sets uptime to 0 ||
 || nsNotifyAddrListener::calculateNetworkId() || open ||
 "/proc/net/route", "/proc/net/arp" ||
 /netwerk/system/linux/nsNotifyAddrListener_Linux.cpp ||
  This code fails gracefully, network id is only used once for
 telemetry, otherwise this is dead code ||
 || js::GetNativeStackBaseImpl() || open || "/proc/self/maps" ||
 /js/src/jsnativestack.cpp ||
  This code gets an address at the top of the usable stack,
 required for internal JS stuff or else bad things happen. Attached patch
 fixes this issue using !__libc_stack_end ||
 || mozilla::ThreadStackHelper::GetThreadStackBase() || open ||
 "/proc/self/maps" || /xpcom/threads/ThreadStackHelper.cpp ||
  Similar to js::GetNativeStackBaseImpl() except the implementation
 isn't there for all platforms and the saved value isn't used for anything,
 fails gracefully ||
 || nsSystemInfo::Init() || open || "/proc/cpuino" ||
 /xpcom/base/nsSystemInfo.cpp ||
  Fails gracefully, otherwise scrapes all your CPU info and stores
 it in the nsISystemInfo property bag for god knows what reasons ||
 || gfxFcPlatformFontList::FindGenericFamilies() || readlink ||
 "/proc/self/exe" || /gfx/thebes/gfxFcPlatformFontList.cpp ||
  Fails gracefully when intercepting this syscall and returning
 error (-1) ||
 || nsLocalFile::GetDiskSpaceAvailable() || open || "/proc/self/mountinfo"
 || /xpcom/io/nsLocalFileUnix.cpp ||
  Fails gracefully when given file isn't found and a simpler
 estimate is used instead ||

--
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] #24660 [Core Tor/Tor]: Wrap our PRNG interface(s) in Rust with appropriate traits

[Tor Bug Tracker & Wiki]

#24660: Wrap our PRNG interface(s) in Rust with appropriate traits
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-crypto, rng, roadmap, 034  |  Actual Points:
  -roadmap-master, 034-triage-20180328,  |
  034-included-20180328  |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-
Changes (by isis):

 * status:  accepted => needs_review


Comment:

 There's an implementation in my `bug24660`
 [https://gitweb.torproject.org/user/isis/tor.git/log/?h=bug24660 branch]
 ([https://travis-ci.org/isislovecruft/tor/builds/365348704 Travis mostly
 passes], just not the cargo offline mode). The added dependency for
 rand_core is in the `master` branch of my tor-rust-dependencies
 [https://github.com/isislovecruft/tor-rust-dependencies repo], but from
 https://github.com/rust-lang-
 nursery/rand/issues/386#issuecomment-380489759 it looks like we should
 wait a few days to vendor rand_core-0.1.0.

--
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] #21537 [Applications/Tor Browser]: Consider ignoring secure cookies for .onion addresses

[Tor Bug Tracker & Wiki]

#21537: Consider ignoring secure cookies for .onion addresses
-+-
 Reporter:  micah|  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability,   |  Actual Points:
  TorBrowserTeam201804R, GeorgKoppen201804   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 Replying to [comment:14 arthuredelstein]:
 > Replying to [comment:13 gk]:
 > > Replying to [comment:12 pospeselr]:
 > > > Change looks good, only thing I'd suggest is moving the block at
 3340 a couple lines up before the Telemetry::Accumulate call ( since the
 enum seems to be a question of cookie security, rather than http(s) ).
 > > >
 > > > I also verified the hostURI that's passed in is already normalized,
 so we don't have to worry about case insensitive string compare.
 > >
 > > Thanks. I added the suggested change in `bug_21537_v3`
 (https://gitweb.torproject.org/user/gk/tor-
 browser.git/log/?h=bug_21537_v3). Let me know if that still looks good.
 >
 > The code looks good to me, but I would suggest factoring out the
 security checks (which are repeated in three places) by creating a static
 function like:
 > `bool IsSecureHost(nsIURI *aHostURI)`
 > that returns true for both https and .onion URIs.

 Yeah I'd agree with this.

--
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] #25784 [Core Tor/Tor]: Misleading error message when asking for IPv6 in a network with no IPv6-capable exits

[Tor Bug Tracker & Wiki]

#25784: Misleading error message when asking for IPv6 in a network with no
IPv6-capable exits
--+
 Reporter:  pastly|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.10
 Severity:  Minor |   Keywords:  easy, ipv6
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I created a small test Tor network. 3 authorities, 7 relays, 3 exits.
 Great.

 I didn't set `IPv6Exit 1` on any of the exits.

 I had a client try to request `::1` over this Tor network on a hand
 crafted circuit (it makes sense to ask an exit to connect to localhost
 when this is all local ... trust me). I got the following confusing error
 message on the client.

 > [warn] I'm about to ask a node for a connection that I am telling it to
 fulfil with neither IPv4 nor IPv6. That's not going to work. Did you
 perhaps ask for an IPv6 address on an IPv4Only port, or vice versa?

 I think it's important to point out (again) that I was hand crafting these
 circuits and was not considering IPv6 support. That said, I don't know
 what Tor would do if I let it make the circuit for me and it couldn't find
 an IPv6-supporting exit.

 As you can see, I'm talking myself out of this being a bug and it just
 being me screwing things up for myself. I was encouraged to make a ticket
 though, so here we are.

 If rewriting the error message is the solution, maybe after fixing the
 "fulfil" typo, we should add "It's also possible we couldn't find any
 exits supporting the IP version you want to use"

 I'm picking 0.3.5.x-final just because I've been told you have to pick a
 milestone or else your tickets generally fall through the cracks. :)

--
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] #25784 [Core Tor/Tor]: Misleading error message when asking for IPv6 in a network with no IPv6-capable exits

[Tor Bug Tracker & Wiki]

#25784: Misleading error message when asking for IPv6 in a network with no
IPv6-capable exits
--+
 Reporter:  pastly|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.1-alpha
 Severity:  Minor | Resolution:
 Keywords:  easy, ipv6|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * version:  Tor: 0.3.2.10 => Tor: 0.2.9.1-alpha
 * milestone:  Tor: 0.3.5.x-final => Tor: unspecified


Comment:

 Replying to [ticket:25784 pastly]:
 > As you can see, I'm talking myself out of this being a bug and it just
 being me screwing things up for myself. I was encouraged to make a ticket
 though, so here we are.

 We should fix this error message eventually.

 I think it was introduced back in 0.2.8 or 0.2.9 with IPv6Only and
 OnionTrafficOnly.

 > If rewriting the error message is the solution, maybe after fixing the
 "fulfil" typo

 It's a variant spelling, which we tolerate in Tor. You can thank the
 British Empire for your confusion. Or people who insist there is one right
 way to spell.

 > we should add "It's also possible we couldn't find any exits supporting
 the IP version you want to use"

 +1

 > I'm picking 0.3.5.x-final just because I've been told you have to pick a
 milestone or else your tickets generally fall through the cracks. :)

 The new rule is that everything goes in "Tor: unspecified".

 If you want to rescue a ticket from "Tor: unspecified", take ownership of
 it, do it, and assign it to the current release.

 (Paid staff don't spend more than half a day on things until we all agree
 it's on the roadmap. But volunteers can do whatever we 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

Re: [tor-bugs] #25572 [Applications/Tor Browser]: Update NoScript to 5.1.8.5

[Tor Bug Tracker & Wiki]

#25572: Update NoScript to 5.1.8.5
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201804  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Okay, pushed this to `master` with commit
 36cfa493d65da45022aad17c6d7b21ee0a9b2fae so that we can test the update in
 the upcoming alpha.

 I diffed 5.1.8.4 and 5.1.8.5 and it looks mostly good. Turns out I
 discovered a packaging error as a Perl script is included, too, in the
 .xpi. It's not used, though, so there is not much harm done.

--
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] #25773 [Applications/Tor Browser]: Disable Speculative Connect and Download

[Tor Bug Tracker & Wiki]

#25773: Disable Speculative Connect and Download
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| 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:8 sysrqb]:
 > The reason I opened this bug is because Tor Browser should not begin
 downloading a file unless the user explicitly confirms they want the file
 downloaded and where they want it saved. If clicking "Save Link As..."
 starts any network transactions before the users clicks "Save" within the
 file-chooser dialog box, then Tor Browser should make this obvious. I
 believe Tor Browser should treat the two scenarios differently:
 >
 >   1) I click on the link and Firefox doesn't know what to do, so it
 asked me where to save the file
 >   2) I click on "Save Link As..." and specify where I want the file
 saved (or I click cancel)
 >
 > Within scenario (1), Firefox cannot know what it should do without
 beginning the download. That's okay. With scenario (2), that is completely
 against what the user requested. This is almost certainly a Firefox bug,
 unfortunately it seems Firefox handles (1) and (2) using the same logic.

 Why is (2) against what the user requested? The user said: "I want to have
 that thing AND want to specify where it will be after the download
 finished." And they get both. Note that the "Save Link" part already means
 "Yes, I want to have it!1!!" (unrelated to the "As") even if they might
 not know yet where to put the result or how to name it, or want to select
 the place themselves with a GUI . Thus, starting the download in the
 meantime while they are selecting the place where it should land sounds
 reasonable to me. Sure, if they decided "Nah, I actually don't really want
 it" (i.e. clicking the Cancel button) it gets discarded, no damage done.

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