date:20170302

Re: [tor-bugs] #21622 [Core Tor/Tor]: Log a message when a hidden service delays new introduction point circuits

2017-03-02 Thread Tor Bug Tracker & Wiki

#21622: Log a message when a hidden service delays new introduction point 
circuits
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:  #21446| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * owner:   => teor
 * status:  new => assigned


--
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] #21622 [Core Tor/Tor]: Log a message when a hidden service delays new introduction point circuits

2017-03-02 Thread Tor Bug Tracker & Wiki

#21622: Log a message when a hidden service delays new introduction point 
circuits
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs
Actual Points:|  Parent ID:  #21446
   Points:  0.2   |   Reviewer:
  Sponsor:|
--+
 When a hidden service stops making new introduction point circuits, it
 would be useful to log a message saying:
 * how many connections it has made so far,
 * how long it took it to make those connections,
 * what the connection limit is,
 * in what time that many connections can be made, and
 * a list of the current intro point connections.

 This is a follow-up to #21599.

--
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] #21598 [Core Tor/Tor]: Log a message when a hidden service has fewer introduction points than expected

2017-03-02 Thread Tor Bug Tracker & Wiki

#21598: Log a message when a hidden service has fewer introduction points than
expected
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:  0.1
Parent ID:  #21446| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_information => merge_ready


Comment:

 Ok, I pushed a fixup including dgoulet's suggested changes to
 feature21598.

--
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] #21594 [Core Tor/Tor]: Hidden Services with many intro points delay checking circuits on startup

2017-03-02 Thread Tor Bug Tracker & Wiki

#21594: Hidden Services with many intro points delay checking circuits on 
startup
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.3.9-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:  0.2
Parent ID:  #21446| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_information => needs_review


Comment:

 Replying to [comment:2 dgoulet]:
 > Oh wow, that is a good find! So 10 was the maximum before and I bet it
 was considered to be that value because of "3" intro points. Which means,
 we would allow two rounds of intro point circuit connection because 3 + 2
 (extra for performance).
 >
 > Following that, I think it would be wise to do something like that which
 is at the very least do a retry if all 10 circs. fail. Now that makes it a
 bit more "involving" because it would be a dynamic maximum depending on
 how many intro points.
 >
 > So two choices, doing that dynamic thingy (not that crazy, there is one
 callsite I believe checking that maximum) or we just say (10 + 2) * 2 is
 our new max per period.
 >
 > Thoughts?

 Do the dynamic maximum - that means we tolerate almost all our connections
 failing in the first 5 minutes, but if they all fail, we wait.

 I pushed two fixups to the branch bug21594_030, which replace the macro
 with a static function.

--
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] #21034 [Applications/Tor Browser]: Per site security settings?

2017-03-02 Thread Tor Bug Tracker & Wiki

#21034: Per site security settings?
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #20843| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Replying to [comment:5 jonathanfemideer]:
 > N.B. I have not yet encountered any websites that require the security
 level to be set to Low, but perhaps such websites do exist. If so, then
 please consider my request to extend to allowing a per-site setting of Low
 for those websites.

 HTTPS sites that use JavaScript.

--
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] #21444 [Applications/Tor Browser]: Webcam light flashes when I open NoScript menu

2017-03-02 Thread Tor Bug Tracker & Wiki

#21444: Webcam light flashes when I open NoScript menu
--+---
 Reporter:  ChatTor   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by ChatTor):

 Sorry for the delay, IRL can be busy. It doesn't seem to happen with
 Firefox 45.7, and my webcam is USB, so I don't need tape personally.

 It doesn't make much sense to me either, but, after playing with it more,
 it seems that the light flickers any time a menu resembling the right-
 click menu is drawn (Click the NoScript icon, click the HTTPS Anywhere
 icon, right-clicking, hovering over the NoScript option in the right-click
 menu), but not for fancy menus (like when you click the 3 lines to get
 into Firefox's settings  or when you click the gear icon in a new tab).
 Perhaps the bug is tied to the menu draw function of Firefox somehow? I'm
 not familiar with the source of Firefox, so I (unfortunately) can't be
 more helpful here.

 Also worth mentioning, I tried removing all add-ons and restarting the
 browser, and the light still flashes when I right-click and the right-
 click menu opens. This occurs both in the body of the browser as well as
 the address bar part of the browser, but not when I right-click the window
 title area drawn by X and get my system options for things such as "Move
 to desktop".

--
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] #21367 [Metrics/Atlas]: mark platform string red (or in some other obvious way) if recommended_version field is not true

2017-03-02 Thread Tor Bug Tracker & Wiki

#21367: mark platform string red (or in some other obvious way) if
recommended_version field is not true
---+--
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 Replying to [comment:14 irl]:
 > Ok, how about this?
 >
 >
 
https://gitweb.torproject.org/user/irl/atlas.git/patch/?id=d2ff11c76cde78c6aea2b6c132a818ee5e465529
 >
 > Removing the psuedoflag and instead adding the warning next to the
 platform string.

 I actually found the pseudoflag really useful, because it shows up in the
 relay table, so I can search all my relays at once and check if any are
 out of date.

--
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] #21415 [Core Tor/Tor]: tor_bug_occurred_: Bug: src/or/entrynodes.c:1845: select_entry_guard_for_circuit: Non-fatal assertion !(!guard_has_descriptor(guard)) failed.

2017-03-02 Thread Tor Bug Tracker & Wiki

#21415: tor_bug_occurred_: Bug: src/or/entrynodes.c:1845:
select_entry_guard_for_circuit: Non-fatal assertion
!(!guard_has_descriptor(guard)) failed.
-+
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.0.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  review-group-16  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+

Comment (by teor):

 Replying to [comment:22 asn]:
 > c) If the test is ipv6-only and the bridge is only configured as ipv6,
 why does the client prefer the ipv4 address of the bridge? That's
 regarding `[notice] Bridge 'test003br' has both an IPv4 and an IPv6
 address.  Will prefer using its IPv4 address (127.0.0.1:5003) based on the
 configured Bridge address.`

 Sorry, this chutney test was never intended to be *that* evil.

--
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] #21367 [Metrics/Atlas]: mark platform string red (or in some other obvious way) if recommended_version field is not true

2017-03-02 Thread Tor Bug Tracker & Wiki

#21367: mark platform string red (or in some other obvious way) if
recommended_version field is not true
---+--
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by irl):

 * status:  reopened => needs_review


Comment:

 Ok, how about this?

 
https://gitweb.torproject.org/user/irl/atlas.git/patch/?id=d2ff11c76cde78c6aea2b6c132a818ee5e465529

 Removing the psuedoflag and instead adding the warning next to the
 platform string.

--
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] #21621 [Core Tor/Tor]: Intro points can get stuck in CIRCUIT_PURPOSE_S_ESTABLISH_INTRO

2017-03-02 Thread Tor Bug Tracker & Wiki

#21621: Intro points can get stuck in CIRCUIT_PURPOSE_S_ESTABLISH_INTRO
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:  #21446| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * parent:   => #21446


Comment:

 This is more cleanup after #21599: covering another edge case where
 circuits could get stuck.

--
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] #21621 [Core Tor/Tor]: Intro points can get stuck in CIRCUIT_PURPOSE_S_ESTABLISH_INTRO

2017-03-02 Thread Tor Bug Tracker & Wiki

#21621: Intro points can get stuck in CIRCUIT_PURPOSE_S_ESTABLISH_INTRO
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.2-alpha
 Severity:  Normal|   Keywords:  tor-hs
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 When a hidden service opens an introduction point circuit, there's nothing
 that checks that it actually receive an INTRO_ESTABLISHED cell within a
 reasonable timeout.

 So in remove_invalid_intro_points(), we should close circuits that have
 been in CIRCUIT_PURPOSE_S_ESTABLISH_INTRO for too long (60 seconds? 5
 minutes? Some dynamic interval?).

--
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] #21600 [Core Tor/Tor]: Hidden service introduction point retries occur at 1 second intervals

2017-03-02 Thread Tor Bug Tracker & Wiki

#21600: Hidden service introduction point retries occur at 1 second intervals
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, single-onion  |  Actual Points:
Parent ID:  #21446| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_information => assigned


--
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] #21600 [Core Tor/Tor]: Hidden service introduction point retries occur at 1 second intervals

2017-03-02 Thread Tor Bug Tracker & Wiki

#21600: Hidden service introduction point retries occur at 1 second intervals
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, single-onion  |  Actual Points:
Parent ID:  #21446| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:1 dgoulet]:
 > Hrm... failing 3 times in 3 seconds means that every circuit creation
 failed right away? In that case, "tor" might have more problems... But I
 think the behavior here should be that we open a circuit and then if it
 fails like in 10 seconds after, we note down the try and retry a second
 later. That sounds reasonable to me?

 Let's reword it to be something like:

 When a circuit fails, we retry 10 seconds after we first detect the
 failure.

 Then it's dynamic based on circuit failure 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] #20820 [Applications/Tor Browser]: Add font support for Shift-JIS

2017-03-02 Thread Tor Bug Tracker & Wiki

#20820: Add font support for Shift-JIS
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-fonts, tbb-   |  Actual Points:
  usability-website  |
Parent ID:  #18097   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #18379 [Applications/Tor Browser]: Mouse Tracking Defenses in Tor Browser

2017-03-02 Thread Tor Bug Tracker & Wiki

#18379: Mouse Tracking Defenses in Tor Browser
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #19812 [Applications/Tor Browser]: onion everywhere

2017-03-02 Thread Tor Bug Tracker & Wiki

#19812: onion everywhere
--+--
 Reporter:  ilf   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  onion, https everywhere   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #1670 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Allow onion alternate addresses in rulesets

2017-03-02 Thread Tor Bug Tracker & Wiki

#1670: Allow onion alternate addresses in rulesets
---+-
 Reporter:  bee|  Owner:  pde
 Type:  enhancement| Status:  new
 Priority:  Very Low   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS Everywhere  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by tokotoko):

 * cc: fdsfgs@… (added)
 * severity:   => Normal


--
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] #21200 [Applications/Tor Browser]: Move all TB Mozilla service calls to .onions

2017-03-02 Thread Tor Bug Tracker & Wiki

#21200: Move all TB Mozilla service calls to .onions
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #21555 [Applications/Tor Browser]: Twitter like button not working on 6.5

2017-03-02 Thread Tor Bug Tracker & Wiki

#21555: Twitter like button not working on 6.5
-+-
 Reporter:  isabela  |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  accepted
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability-website,   |  Actual Points:
  TorBrowserTeam201702   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #21483 [Applications/Tor Browser]: DuckDuckGo Onion should be the default instead of DuckDuckGo

2017-03-02 Thread Tor Bug Tracker & Wiki

#21483: DuckDuckGo Onion should be the default instead of DuckDuckGo
--+--
 Reporter:  lolscreen |  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 tokotoko):

 * cc: fdsfgs@… (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] #21456 [Applications/Tor Browser]: Ship own TCP/IP stack with TorBrowser to prevent OS fingerprinting

2017-03-02 Thread Tor Bug Tracker & Wiki

#21456: Ship own TCP/IP stack with TorBrowser to prevent OS fingerprinting
--+--
 Reporter:  cypherpunks   |  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 tokotoko):

 * cc: fdsfgs@… (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] #21431 [Applications/Tor Browser]: Clean-up system extensions shipped in Firefox 52

2017-03-02 Thread Tor Bug Tracker & Wiki

#21431: Clean-up system extensions shipped in Firefox 52
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201702  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #21321 [Applications/Tor Browser]: Convince Mozilla; .onion HTTP is SECURE.

2017-03-02 Thread Tor Bug Tracker & Wiki

#21321: Convince Mozilla; .onion HTTP is SECURE.
-+--
 Reporter:  cypherpunks  |  Owner:  tbb-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-usability-website  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #21514 [Applications/Tor Browser]: Deal with W^X backport bustage in upcoming ESR release

2017-03-02 Thread Tor Bug Tracker & Wiki

#21514: Deal with W^X backport bustage in upcoming ESR release
--+-
 Reporter:  gk|  Owner:  arthuredelstein
 Type:  task  | Status:  needs_review
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  TorBrowserTeam201703R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #16772 [Applications/Tor Browser]: Google's reCAPTCHA Tor Censorship !?

2017-03-02 Thread Tor Bug Tracker & Wiki

#16772: Google's reCAPTCHA Tor Censorship !?
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  reopened
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #21619 [Metrics/Atlas]: Flag fallback directory mirrors in Atlas

2017-03-02 Thread Tor Bug Tracker & Wiki

#21619: Flag fallback directory mirrors in Atlas
---+-
 Reporter:  teor   |  Owner:  irl
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by irl):

 Also useful for this would probably be to add
 "last_changed_address_or_port" to the details pages for relays. Probably
 in the 3rd column.

--
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] #21358 [Core Tor/Tor]: Tor fails to reconnect after computer resumes from sleep

2017-03-02 Thread Tor Bug Tracker & Wiki

#21358: Tor fails to reconnect after computer resumes from sleep
--+
 Reporter:  weasel|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.8
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #21034 [Applications/Tor Browser]: Per site security settings?

2017-03-02 Thread Tor Bug Tracker & Wiki

#21034: Per site security settings?
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #20843| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #16450 [Applications/Tor Browser]: Tor browser removes third-party cookies

2017-03-02 Thread Tor Bug Tracker & Wiki

#16450: Tor browser removes third-party cookies
--+--
 Reporter:  justuser  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #21237 [Core Tor/Tor]: Support domain isolation for onion connections too?

2017-03-02 Thread Tor Bug Tracker & Wiki

#21237: Support domain isolation for onion connections too?
--+--
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #15499 [Applications/Tor Browser]: Onion sites circuits are not properly isolated to URL bar domain

2017-03-02 Thread Tor Bug Tracker & Wiki

#15499: Onion sites circuits are not properly isolated to URL bar domain
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #21323 [Applications/Tor Browser]: Activate mixed content blocking

2017-03-02 Thread Tor Bug Tracker & Wiki

#21323: Activate mixed content blocking
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201703R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #13367 [Applications/Tor Browser]: Rate limit gyroscope sampling frequency on FF mobile

2017-03-02 Thread Tor Bug Tracker & Wiki

#13367: Rate limit gyroscope sampling frequency on FF mobile
--+--
 Reporter:  mikeperry |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security, tbb-mobile  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #19078 [Applications/Tor Browser]: Disable RtspMediaResource stuff in OrFox

2017-03-02 Thread Tor Bug Tracker & Wiki

#19078: Disable RtspMediaResource stuff in OrFox
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #20815 [Applications/Tor Browser]: UI dev work of security slider experience on Orfox

2017-03-02 Thread Tor Bug Tracker & Wiki

#20815: UI dev work of security slider experience on Orfox
--+--
 Reporter:  isabela   |  Owner:  synzvato
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, android   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #21221 [User Experience]: Perform usability testing for the mobile security slider

2017-03-02 Thread Tor Bug Tracker & Wiki

#21221: Perform usability testing for the mobile security slider
+-
 Reporter:  lnl |  Owner:  lnl
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  User Experience |Version:
 Severity:  Normal  | Resolution:
 Keywords:  orfox, tor browser, tbb-mobile  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #19675 [Applications/Tor Browser]: Merge Orfox patches into tor-browser

2017-03-02 Thread Tor Bug Tracker & Wiki

#19675: Merge Orfox patches into tor-browser
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:  #20680| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #21367 [Metrics/Atlas]: mark platform string red (or in some other obvious way) if recommended_version field is not true

2017-03-02 Thread Tor Bug Tracker & Wiki

#21367: mark platform string red (or in some other obvious way) if
recommended_version field is not true
---+--
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 Replying to [comment:12 irl]:
 > > might suggest that people blacklist this relay in their client torrc
 >
 > This is a scary enough thought to consider changing this. What about
 "NoRecVer"? It's a little cryptic but the tooltip is still there to
 explain and it's then a similar length to the others. I don't think this
 is any worse than V2Dir or HSDir.

 Please do not make this more cryptic.

 Moving the sign to the platform string and changing it from "not
 recommended"
 to
 "runs not recommended version"

 should be fine.

--
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] #21289 [Applications/Tor Browser]: Orfox needs global NoScript Anywhere++ HTTPS whitelisting

2017-03-02 Thread Tor Bug Tracker & Wiki

#21289: Orfox needs global NoScript Anywhere++ HTTPS whitelisting
--+--
 Reporter:  synzvato  |  Owner:  synzvato
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #5709 [Applications/Tor Browser]: Tor Browser Bundle build for Android

2017-03-02 Thread Tor Bug Tracker & Wiki

#5709: Tor Browser Bundle build for Android
--+--
 Reporter:  arma  |  Owner:  tbb-team
 Type:  project   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, tbb-gitian|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #21367 [Metrics/Atlas]: mark platform string red (or in some other obvious way) if recommended_version field is not true

2017-03-02 Thread Tor Bug Tracker & Wiki

#21367: mark platform string red (or in some other obvious way) if
recommended_version field is not true
---+--
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by irl):

 > might suggest that people blacklist this relay in their client torrc

 This is a scary enough thought to consider changing this. What about
 "NoRecVer"? It's a little cryptic but the tooltip is still there to
 explain and it's then a similar length to the others. I don't think this
 is any worse than V2Dir or HSDir.

--
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] #21615 [Metrics/Atlas]: Use hashed fingerprint in all lookups

2017-03-02 Thread Tor Bug Tracker & Wiki

#21615: Use hashed fingerprint in all lookups
---+---
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by irl):

 Ok, I see the inconsistency now. The search page, when fetching the
 details documents, isn't hashing but the details page is regardless of
 whether or not the fingerprint has already been hashed.

 So, to add to the examples of what is happening, I have two bridges that
 with the following search will do lookups for details documents of the
 hashed fingerprint but when going to the details pages, the hashed
 fingerprint will be hashed once more.

 https://atlas.torproject.org/#search/irlDn42

 The hashed fingerprints are already leaked in the search step, so either
 this is a defect in that we're leaking hashed fingerprints that need to be
 hashed again or there is an enhancement to be had in removing the re-
 hashing when fetching the details documents for the details pages.

 Currently, by the time we get to the details pages we've already leaked
 the hashed fingerprint for the bridge.

 karsten: I guess the question is, how many times do we need to hash the
 fingerprint?

--
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] #21619 [Metrics/Atlas]: Flag fallback directory mirrors in Atlas

2017-03-02 Thread Tor Bug Tracker & Wiki

#21619: Flag fallback directory mirrors in Atlas
---+-
 Reporter:  teor   |  Owner:  irl
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by teor):

 Replying to [comment:1 cypherpunks]:
 > Replying to [ticket:21619 teor]:
 > > Could Atlas do something like this, too?
 > > (Like the Not Recommended flag?)
 >
 > To add "Not Recommended" Atlas simply made use of onionoo boolean
 recommended_version, but there is no fallback flag in onionoo, so this
 would probably require a onionoo change first unless atlas keeps this list
 out of band.

 Thanks, opened #21620 for 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] #21620 [Metrics/Onionoo]: Flag fallback directory mirrors in OnionOO

2017-03-02 Thread Tor Bug Tracker & Wiki

#21620: Flag fallback directory mirrors in OnionOO
-+--
 Reporter:  teor |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Can you add a boolean fallback_dir flag to relays in OnionOO?

 See #21619 for details.

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

Re: [tor-bugs] #21599 [Core Tor/Tor]: Make hidden service descriptor creation more consistent

2017-03-02 Thread Tor Bug Tracker & Wiki

#21599: Make hidden service descriptor creation more consistent
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:  0.1
Parent ID:  #21446| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_revision => merge_ready


Comment:

 Replying to [comment:2 dgoulet]:
 > Patch lgtm however it will conflict because that patch also has the
 change of `remove_invalid_intro_points()` I've seen in another ticket.

 No, it won't conflict with #21596 - git is smart enough to merge commits
 that match.

 (See my branch today-in-hs for how this works.)

--
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] #21598 [Core Tor/Tor]: Log a message when a hidden service has fewer introduction points than expected

2017-03-02 Thread Tor Bug Tracker & Wiki

#21598: Log a message when a hidden service has fewer introduction points than
expected
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:  0.1
Parent ID:  #21446| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_revision => needs_information


Comment:

 Replying to [comment:2 dgoulet]:
 > This lgtm except I would simply add the onion address of the faulting
 service with something like:
 >
 > {{{
 > +log_fn(severity, LD_REND, "Hidden service %s wanted %d intro
 points, but "
 > +   "descriptor was updated with %d instead.",
 > +   service->service_id,
 > +   service->n_intro_points_wanted, have_intro);
 > }}}
 >
 > Note that it's not being used with `safe_str_client()` so an operator
 can at least identify which service is being affected without restarting
 with `SafeLogging 0`... Feel free to change that if you think it's a bad
 idea.

 rend_service_dump_stats() prints the configured directory, so I'm not sure
 if we need the service name as well. What do you think?

 Is the directory name safer than the service name?
 If this bug happens, a user will paste the logs in a public ticket.

--
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] #21619 [Metrics/Atlas]: Flag fallback directory mirrors in Atlas

2017-03-02 Thread Tor Bug Tracker & Wiki

#21619: Flag fallback directory mirrors in Atlas
---+-
 Reporter:  teor   |  Owner:  irl
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by cypherpunks):

 Replying to [ticket:21619 teor]:
 > Could Atlas do something like this, too?
 > (Like the Not Recommended flag?)

 To add "Not Recommended" Atlas simply made use of onionoo boolean
 recommended_version, but there is no fallback flag in onionoo, so this
 would probably require a onionoo change first unless atlas keeps this list
 out of band.

--
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] #21619 [Metrics/Atlas]: Flag fallback directory mirrors in Atlas

2017-03-02 Thread Tor Bug Tracker & Wiki

#21619: Flag fallback directory mirrors in Atlas
---+-
 Reporter:  teor   |  Owner:  irl
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by atagar):

 For what it's worth if you want the current list of fallback directories
 in the tor source here's what you can call (it pulls the list from
 gitweb)...

 
https://stem.torproject.org/api/descriptor/remote.html#stem.descriptor.remote.FallbackDirectory.from_remote

--
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] #21619 [Metrics/Atlas]: Flag fallback directory mirrors in Atlas

2017-03-02 Thread Tor Bug Tracker & Wiki

#21619: Flag fallback directory mirrors in Atlas
---+-
 Reporter:  teor   |  Owner:  irl
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Tor keeps a list of fallback directory mirrors in its source code.

 consensus-health flags these mirrors using the synthetic flag
 "FallbackDir".

 Could Atlas do something like this, too?
 (Like the Not Recommended flag?)

 The list is updated every 2-6 months:
 https://gitweb.torproject.org/tor.git/tree/src/or/fallback_dirs.inc

 And then parsed and included in stem in a friendlier format:
 
https://gitweb.torproject.org/stem.git/tree/stem/descriptor/fallback_directories.cfg

--
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] #20505 [Metrics/Torflow]: make min_bw configurable in bwauths

2017-03-02 Thread Tor Bug Tracker & Wiki

#20505: make min_bw configurable in bwauths
-+
 Reporter:  teor |  Owner:  aagbsn
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Torflow  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by teor):

 Replying to [comment:1 tom]:
 > This doesn't look like something we would want to apply to the main
 repo. Where would you want it to live? In a separate branch?  I'm doubtful
 it would be helpful to re-architect things sufficiently that this was
 easily parameterized...

 I'm not sure - this is an architectural question:

 Core tor has an option that sets a whole lot of parameters useful for test
 networks.
 Perhaps we could do the same with the bandwidth scanner. But that means
 the resulting changes are scattered throughout the code.

 Maybe a separate branch is better, but then it easily gets outdated.

 Ideally, we could make these parameters configurable, and distribute a
 testing config (or a set of testing defaults).

 Perhaps documenting this issue and providing a patch is the best strategy?

--
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] #21576 [Core Tor/Tor]: Bug: Assertion linked_dir_conn_base failed in connection_ap_handshake_send_begin

2017-03-02 Thread Tor Bug Tracker & Wiki

#21576: Bug: Assertion linked_dir_conn_base failed in
connection_ap_handshake_send_begin
-+
 Reporter:  alecmuffett  |  Owner:  teor
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  crash, 029-backport  |  Actual Points:  0.5
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+

Comment (by teor):

 Replying to [comment:7 asn]:
 > I'm a big newbie with this part of the codebase (particularly linked
 connections and how they work), but the fix looks reasonable given the
 description above, and it doesn't seem like it can make matters worse.
 >
 > I guess a side-question is whether that's the best place in the codebase
 to bail if the linked connection does not exist. Maybe we shouldn't even
 start sending the BEGIN cell if the linked conn has been teared down?

 We could do that too, but that's a separate ticket.

 We must always do the check right before we do the circuit length
 anonymity check, because we can't work out if a directory circuit needs to
 be anonymous or not without its linked directory connection.

 > Anyway, I think Nick will be better to evaluate this patch, so I'm
 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

Re: [tor-bugs] #21617 [Applications/Tor Browser]: RWX page observed on Windows

2017-03-02 Thread Tor Bug Tracker & Wiki

#21617: RWX page observed on Windows
--+--
 Reporter:  arthuredelstein   |  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 arthuredelstein):

 I opened a Mozilla bug to track this issue in Firefox:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1344034

--
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] #21514 [Applications/Tor Browser]: Deal with W^X backport bustage in upcoming ESR release

2017-03-02 Thread Tor Bug Tracker & Wiki

#21514: Deal with W^X backport bustage in upcoming ESR release
--+-
 Reporter:  gk|  Owner:  arthuredelstein
 Type:  task  | Status:  needs_review
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  TorBrowserTeam201703R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by mcs):

 I used the vmmap command on a macOS Sierra (10.12.3) system to confirm
 that there are no rwx segments when the patches are present. Without them,
 I see several such segments (as I do with Firefox ESR 45.x). So I think
 this is working on OSX as 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] #18090 [Applications/Tor Browser]: Torcrazybutton eats all memory and crashes Tor Browser

2017-03-02 Thread Tor Bug Tracker & Wiki

#18090: Torcrazybutton eats all memory and crashes Tor Browser
-+-
 Reporter:  bugzilla |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-crash, tbb-performance-leaking,  |  Actual Points:
  tbb-oom, tbb-torbutton |
Parent ID:  #18047   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by bugzilla):

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


Comment:

 Unfortunately, this bug is not fixed :(. Torbutton was affected by some
 underlying problem and made it easier to trigger and faster to go to OOM.
 Now, to trigger "unbound recursion" (?) you need, for example, to supply
 constant stream of tiny icons/images on a webpage and see when the process
 will become self-sustainable without it, and FF will continue to do
 something by overloading memory throughput, but very slowly growing in
 size (hours before OOM).

--
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] #21617 [Applications/Tor Browser]: RWX page observed on Windows

2017-03-02 Thread Tor Bug Tracker & Wiki

#21617: RWX page observed on Windows
--+--
 Reporter:  arthuredelstein   |  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 arthuredelstein):

 I see a similar single RWX page in Firefox 51.0.1 on Windows. So it's not
 special to Tor Browser.

--
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] #21618 [HTTPS Everywhere/EFF-HTTPS Everywhere]: bayern.de

2017-03-02 Thread Tor Bug Tracker & Wiki

#21618: bayern.de
---+--
 Reporter:  cypherpunks|  Owner:  jsha
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS Everywhere  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dgoulet):

 * owner:   => jsha
 * component:  - Select a component => HTTPS Everywhere/EFF-HTTPS Everywhere


--
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] #21514 [Applications/Tor Browser]: Deal with W^X backport bustage in upcoming ESR release

2017-03-02 Thread Tor Bug Tracker & Wiki

#21514: Deal with W^X backport bustage in upcoming ESR release
--+-
 Reporter:  gk|  Owner:  arthuredelstein
 Type:  task  | Status:  needs_review
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  TorBrowserTeam201703R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arthuredelstein):

 I used VMMap on Windows to examine the memory protections of gk's build
 from comment:8. Good news and bad news. The bad news is there was one 4k
 page with RWX  protection. The good news is that Jan helped me confirm
 that this block was far from (and therefore not part of) the 128 MB block
 allocated for the JIT. All the memory in the JIT block was RX or
 "Reserved".

 So I think my JIT `W^X` patch is also working correctly on Windows. But it
 would be good to track down the cause of the RWX block. I opened #21617 to
 look at this 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

[tor-bugs] #21618 [- Select a component]: bayern.de

2017-03-02 Thread Tor Bug Tracker & Wiki

#21618: bayern.de
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 there is currently only one rule switching bayern.de over to ssl

 https://www.eff.org/https-everywhere/atlas/domains/bayern.de.html

 Please make this rule for the complete domain bayern.de instead of just a
 subdomain.

--
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] #21617 [Applications/Tor Browser]: RWX page observed on Windows

2017-03-02 Thread Tor Bug Tracker & Wiki

#21617: RWX page observed on Windows
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 With the #21514 patch applied, I observed a single RWX page on Windows. It
 would be good to track this down and fix it.

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

Re: [tor-bugs] #21600 [Core Tor/Tor]: Hidden service introduction point retries occur at 1 second intervals

2017-03-02 Thread Tor Bug Tracker & Wiki

#21600: Hidden service introduction point retries occur at 1 second intervals
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, single-onion  |  Actual Points:
Parent ID:  #21446| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  new => needs_information


Comment:

 Hrm... failing 3 times in 3 seconds means that every circuit creation
 failed right away? In that case, "tor" might have more problems... But I
 think the behavior here should be that we open a circuit and then if it
 fails like in 10 seconds after, we note down the try and retry a second
 later. That sounds reasonable to me?

--
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] #21599 [Core Tor/Tor]: Make hidden service descriptor creation more consistent

2017-03-02 Thread Tor Bug Tracker & Wiki

#21599: Make hidden service descriptor creation more consistent
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:  0.1
Parent ID:  #21446| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 Patch lgtm however it will conflict because that patch also has the change
 of `remove_invalid_intro_points()` I've seen in another ticket.

--
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] #21598 [Core Tor/Tor]: Log a message when a hidden service has fewer introduction points than expected

2017-03-02 Thread Tor Bug Tracker & Wiki

#21598: Log a message when a hidden service has fewer introduction points than
expected
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:  0.1
Parent ID:  #21446| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 This lgtm except I would simply add the onion address of the faulting
 service with something like:

 {{{
 +log_fn(severity, LD_REND, "Hidden service %s wanted %d intro points,
 but "
 +   "descriptor was updated with %d instead.",
 +   service->service_id,
 +   service->n_intro_points_wanted, have_intro);
 }}}

 Note that it's not being used with `safe_str_client()` so an operator can
 at least identify which service is being affected without restarting with
 `SafeLogging 0`... Feel free to change that if you think it's a bad idea.

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

Re: [tor-bugs] #21596 [Core Tor/Tor]: When hidden services stop creating new intro points, they also stop checking existing ones

2017-03-02 Thread Tor Bug Tracker & Wiki

#21596: When hidden services stop creating new intro points, they also stop
checking existing ones
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, 030-backport  |  Actual Points:  0.2
Parent ID:  #21446| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * keywords:  tor-hs => tor-hs, 030-backport
 * status:  needs_review => merge_ready
 * milestone:  Tor: 0.3.0.x-final => Tor: 0.3.1.x-final


Comment:

 Oh this is also a good fix! lgtm;

 And yes, I believe moving that to 030 would be a good idea. I'm confident
 that it won't introduce instability. Flagging this for 030-backport
 consideration.

--
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] #21594 [Core Tor/Tor]: Hidden Services with many intro points delay checking circuits on startup

2017-03-02 Thread Tor Bug Tracker & Wiki

#21594: Hidden Services with many intro points delay checking circuits on 
startup
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.3.9-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:  0.2
Parent ID:  #21446| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => needs_information


Comment:

 Oh wow, that is a good find! So 10 was the maximum before and I bet it was
 considered to be that value because of "3" intro points. Which means, we
 would allow two rounds of intro point circuit connection because 3 + 2
 (extra for performance).

 Following that, I think it would be wise to do something like that which
 is at the very least do a retry if all 10 circs. fail. Now that makes it a
 bit more "involving" because it would be a dynamic maximum depending on
 how many intro points.

 So two choices, doing that dynamic thingy (not that crazy, there is one
 callsite I believe checking that maximum) or we just say (10 + 2) * 2 is
 our new max per period.

 Thoughts?

--
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] #6355 [Metrics/Atlas]: Distinguish between running relays and non-running relays which last had the Running flag

2017-03-02 Thread Tor Bug Tracker & Wiki

#6355: Distinguish between running relays and non-running relays which last had
the Running flag
---+--
 Reporter:  karsten|  Owner:  phw
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 The patch is based on master.

--
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] #6355 [Metrics/Atlas]: Distinguish between running relays and non-running relays which last had the Running flag

2017-03-02 Thread Tor Bug Tracker & Wiki

#6355: Distinguish between running relays and non-running relays which last had
the Running flag
---+--
 Reporter:  karsten|  Owner:  phw
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 See the inline patch for the idea i had in comment:12.

 {{{
 diff --git a/templates/search/do.html b/templates/search/do.html
 index cd07a61..e58cf73 100644
 --- a/templates/search/do.html
 +++ b/templates/search/do.html
 @@ -78,6 +78,7 @@
  
  <%= _.escape(relay.get('nickname')) %>
  
 +<% if (relay.get('running') === false) { %>Offline<% } %>
  
 <%= relay.get('bandwidth_hr') %>
 

 }}}

--
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] #6355 [Metrics/Atlas]: Distinguish between running relays and non-running relays which last had the Running flag

2017-03-02 Thread Tor Bug Tracker & Wiki

#6355: Distinguish between running relays and non-running relays which last had
the Running flag
---+--
 Reporter:  karsten|  Owner:  phw
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 Replying to [comment:10 RaBe]:
 > Replying to [comment:8 cypherpunks]:
 > > IMO greying out the row is a bit much since the uptime is already
 striked through.
 >
 > Maybe. I just wanted to make it a bit more clear that the relay is down,
 as you might miss a missing flag and just wonder about the strike
 through...
 I agree that the strike through is also confusing and I'm wondering
 whether the entire uptime column should be removed. I can imagine wanting
 to know whether several relays are running but i can't imagine needing to
 know the uptime/downtime of several relays.

 I got an idea of adding Bootstrap labels to the nicknames of relays that
 are not running. Dunno if this looks good but I'll code it up and report
 back.

--
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] #21616 [Internal Services/Tor Sysadmin Team]: Permission to commit to torflow

2017-03-02 Thread Tor Bug Tracker & Wiki

#21616: Permission to commit to torflow
-+-
 Reporter:  tom  |  Owner:  mikeperry
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin   |Version:
  Team   |
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Mike: teor has written a bunch of patches to torflow that I just saw
 recently. I'd like to get permission to commit to torflow to avoid bugging
 you to commit teor's patches. I expect to only commit things that are very
 certainly fine, such as #20580, #20467, and #20457. Other ones, like
 #20619 I'll read through and then ask you to confirm my thoughts if I
 think it's fine.

--
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] #21604 [Core Tor/Stem]: add descriptor-id calc functionality

2017-03-02 Thread Tor Bug Tracker & Wiki

#21604: add descriptor-id calc functionality
---+
 Reporter:  cypherpunks|  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by cypherpunks):

 thank you for considering this!

 Please default time to '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] #21367 [Metrics/Atlas]: mark platform string red (or in some other obvious way) if recommended_version field is not true

2017-03-02 Thread Tor Bug Tracker & Wiki

#21367: mark platform string red (or in some other obvious way) if
recommended_version field is not true
---+--
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 Ok lets change it to (as you suggested)
 "This relay is running a tor version that is not recommended by the
 directory authorities."

 "...software version..." is a bit to generic I think.


 On the relay page I would prefer
 "Not Recommended"
 to
 "Not Recommended Version"
 (hoping that this is not to long)

--
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] #20505 [Metrics/Torflow]: make min_bw configurable in bwauths

2017-03-02 Thread Tor Bug Tracker & Wiki

#20505: make min_bw configurable in bwauths
-+
 Reporter:  teor |  Owner:  aagbsn
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Torflow  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by tom):

 This doesn't look like something we would want to apply to the main repo.
 Where would you want it to live? In a separate branch?  I'm doubtful it
 would be helpful to re-architect things sufficiently that this was easily
 parameterized...

--
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] #21514 [Applications/Tor Browser]: Deal with W^X backport bustage in upcoming ESR release

2017-03-02 Thread Tor Bug Tracker & Wiki

#21514: Deal with W^X backport bustage in upcoming ESR release
--+-
 Reporter:  gk|  Owner:  arthuredelstein
 Type:  task  | Status:  needs_review
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  TorBrowserTeam201703R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arthuredelstein):

 I tested my own build of the 21514+5 branch on Linux. Using
 {{{
 cat /proc/$PID/maps | grep rwx
 }}}
 I confirmed that there were no rwx pages.

 I also tried reverting the W^X patch and then the same command showed
 several "rwxp" pages. So it looks like it is working as expected.

 I'm not sure yet how to do the same thing on OS X, but the vmmap command
 line tool looks promising. Windows has VMMap
 (https://technet.microsoft.com/en-us/sysinternals/vmmap.aspx), which I am
 going to try next.

--
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] #6355 [Metrics/Atlas]: Distinguish between running relays and non-running relays which last had the Running flag

2017-03-02 Thread Tor Bug Tracker & Wiki

#6355: Distinguish between running relays and non-running relays which last had
the Running flag
---+--
 Reporter:  karsten|  Owner:  phw
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Replying to [comment:10 RaBe]:
 > Replying to [comment:9 karsten]:
 > > Hmm, I wonder if removing the `"Running"` flag is too much.  I see how
 it's potentially confusing to keep it, but removing it is not quite
 accurate.  Maybe there's a way to keep it?
 >
 > Isn't a flag that says "Running and usable" exactly the thing that
 confuses the users? :)

 Well, if a relay or bridge is currently not running, it doesn't have any
 flags assigned at the time.  But the list of flags that Onionoo provides
 is what the relay or bridge had assigned when it was last running.
 Removing one flag from that list is wrong.  We could remove all flags, but
 that would also remove potentially useful information.

 As would removing the `"Running"` flag.  For example, there can be bridges
 that are listed in the network status without the `"Running"` flag,
 because the bridge authority cannot successfully reach it.  So, knowing
 whether it had the `"Running"` flag when it was last around is
 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] #6355 [Metrics/Atlas]: Distinguish between running relays and non-running relays which last had the Running flag

2017-03-02 Thread Tor Bug Tracker & Wiki

#6355: Distinguish between running relays and non-running relays which last had
the Running flag
---+--
 Reporter:  karsten|  Owner:  phw
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by RaBe):

 Replying to [comment:8 cypherpunks]:
 > IMO greying out the row is a bit much since the uptime is already
 striked through.

 Maybe. I just wanted to make it a bit more clear that the relay is down,
 as you might miss a missing flag and just wonder about the strike
 through...

 Replying to [comment:9 karsten]:
 > Hmm, I wonder if removing the `"Running"` flag is too much.  I see how
 it's potentially confusing to keep it, but removing it is not quite
 accurate.  Maybe there's a way to keep it?

 Isn't a flag that says "Running and usable" exactly the thing that
 confuses the users? :)

--
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] #21615 [Metrics/Atlas]: Use hashed fingerprint in all lookups

2017-03-02 Thread Tor Bug Tracker & Wiki

#21615: Use hashed fingerprint in all lookups
---+---
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by karsten):

 Wait, removing hashing is not a good idea.  See this part of the spec:
 "Complete hex-encoded fingerprints should always be hashed using SHA-1,
 regardless of searching for a relay or a bridge, in order to not
 accidentally leak non-hashed bridge fingerprints in the URL."  Happy to
 explain this more if needed.

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

Re: [tor-bugs] #21615 [Metrics/Atlas]: Use hashed fingerprint in all lookups

2017-03-02 Thread Tor Bug Tracker & Wiki

#21615: Use hashed fingerprint in all lookups
---+---
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 Removing hashing would also make fixing #21612 obsolete.

--
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] #6355 [Metrics/Atlas]: Distinguish between running relays and non-running relays which last had the Running flag

2017-03-02 Thread Tor Bug Tracker & Wiki

#6355: Distinguish between running relays and non-running relays which last had
the Running flag
---+--
 Reporter:  karsten|  Owner:  phw
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Hmm, I wonder if removing the `"Running"` flag is too much.  I see how
 it's potentially confusing to keep it, but removing it is not quite
 accurate.  Maybe there's a way to keep it?

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

Re: [tor-bugs] #21514 [Applications/Tor Browser]: Deal with W^X backport bustage in upcoming ESR release

2017-03-02 Thread Tor Bug Tracker & Wiki

#21514: Deal with W^X backport bustage in upcoming ESR release
--+-
 Reporter:  gk|  Owner:  arthuredelstein
 Type:  task  | Status:  needs_review
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  TorBrowserTeam201703R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by gk):

 Replying to [comment:9 mcs]:
 > Kathy and I reviewed the patches and they look okay to us. We also ran
 gk's test bundle on OSX and it seemed to work (we did notice that Unix
 domain sockets did not work for SOCKS, but that seems like a different
 problem... maybe a missing patch?)

 Yes, sorry. I just rebuilt the browser part of nightly builds I had around
 which contained torbutton master, while the browser part was based on
 45.8.0esr-6.5. So, it needs probably a stable torbutton.

--
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] #6355 [Metrics/Atlas]: Distinguish between running relays and non-running relays which last had the Running flag

2017-03-02 Thread Tor Bug Tracker & Wiki

#6355: Distinguish between running relays and non-running relays which last had
the Running flag
---+--
 Reporter:  karsten|  Owner:  phw
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 IMO greying out the row is a bit much since the uptime is already striked
 through.

--
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] #9768 [Metrics/Atlas]: The CSS used on Atlas should be responsive

2017-03-02 Thread Tor Bug Tracker & Wiki

#9768: The CSS used on Atlas should be responsive
---+--
 Reporter:  cypherpunks|  Owner:  RaBe
 Type:  enhancement| Status:  needs_review
 Priority:  Low|  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by RaBe):

 * status:  needs_revision => needs_review


Comment:

 I moved the search box back in:

 
https://github.com/RaphaelBergmann/atlas/commit/582751c5e93f695636a851fef699f97cf22440f8

--
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] #21065 [Applications/Tor Browser]: Make it easier to switch between security levels in Tor Browser

2017-03-02 Thread Tor Bug Tracker & Wiki

#21065: Make it easier to switch between security levels in Tor Browser
-+-
 Reporter:  zhr  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, tbb-security-slider,  |  Actual Points:
  tbb-usability  |
Parent ID:  #20843   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by intrigeri):

 * cc: intrigeri (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] #20843 [User Experience]: Tor Browser: How do we help users to use higher security?

2017-03-02 Thread Tor Bug Tracker & Wiki

#20843: Tor Browser: How do we help users to use higher security?
-+-
 Reporter:  arthuredelstein  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by intrigeri):

 * cc: intrigeri (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] #21034 [Applications/Tor Browser]: Per site security settings?

2017-03-02 Thread Tor Bug Tracker & Wiki

#21034: Per site security settings?
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #20843| Points:
 Reviewer:|Sponsor:
--+--
Changes (by intrigeri):

 * cc: intrigeri (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] #21514 [Applications/Tor Browser]: Deal with W^X backport bustage in upcoming ESR release

2017-03-02 Thread Tor Bug Tracker & Wiki

#21514: Deal with W^X backport bustage in upcoming ESR release
--+-
 Reporter:  gk|  Owner:  arthuredelstein
 Type:  task  | Status:  needs_review
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  TorBrowserTeam201703R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by mcs):

 Kathy and I reviewed the patches and they look okay to us. We also ran
 gk's test bundle on OSX and it seemed to work (we did notice that Unix
 domain sockets did not work for SOCKS, but that seems like a different
 problem... maybe a missing patch?)

 We could not figure out how to use lldb to examine the memory protection
 level of the running process (and find the JS-related pages). Maybe if
 someone can describe how to do that with gdb on Linux we can do something
 similar on OSX.

--
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] #6355 [Metrics/Atlas]: Distinguish between running relays and non-running relays which last had the Running flag

2017-03-02 Thread Tor Bug Tracker & Wiki

#6355: Distinguish between running relays and non-running relays which last had
the Running flag
---+--
 Reporter:  karsten|  Owner:  phw
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by RaBe):

 * status:  assigned => needs_review


Comment:

 I now remove the "Running" flag (that says "...is currently usable") and
 also grey out the not running relays in the search table:

 
https://github.com/RaphaelBergmann/atlas/commit/f97b495d061030a09523aa81b697273f603ea87f

--
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] #21615 [Metrics/Atlas]: Use hashed fingerprint in all lookups

2017-03-02 Thread Tor Bug Tracker & Wiki

#21615: Use hashed fingerprint in all lookups
---+---
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 Replying to [comment:1 irl]:
 > Atlas doesn't claim to hash fingerprints and we instead provide
 instructions on how to look up bridges using the hashed fingerprint. I'm
 not convinced this is a defect, as clearly lookups using fingerprints
 work.
 To give some back story, I noticed the inconsistency while working on
 #15415. Looking at the requests, the hash would change between requests
 because the search page doesn't hash the fingerprint and the details page
 does. For example, looking at the requests to Onionoo when browsing to
 https://atlas.torproject.org/#search/BC630CBBB518BE7E9F4E09712AB0269E9DC7D626,
 the first details request (from the search page) uses the actual
 fingerprint while subsequent calls (from the details page) use the hashed
 fingerprint.

 > Is Onionoo generally happy to respond to hashed fingerprints in place of
 fingerprints for both relays and bridges then?

 Onionoo does seem to be happy. For example, browsing to
 https://atlas.torproject.org/#details/C7A9862525665B3E5E48D27FCBC0D8B6E8A9F3C7
 which is a bridge shows a different hash in the request to Onionoo because
 it is hashed again.

 > What is the gain for this over the loss that a bridge fingerprint could
 be entered into the browser and perhaps leaked?
 I'm not sure. The hashing of fingerprints can be traced back to commit
 
[https://gitweb.torproject.org/atlas.git/commit/?id=ba56727fad15316814a7caf4acee4e49c173b86c
 ba56727fad15316814a7caf4acee4e49c173b86c] which doesn't give a motivation
 other than that Onionoo supports it.
 >
 > I'm not saying it's a bad idea, I'm saying I'm not sure I understand the
 motivation yet.
 I just like it to be consistent. Either everything should hash before
 requesting Onionoo or nothing should. Because its obviously hard to
 remember and check that every request should hash before sending it, i
 lean towards not hashing. It would remove the dependency on the JavaScript
 SHA library, remove some code, and speed Atlas up slightly.

--
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] #21604 [Core Tor/Stem]: add descriptor-id calc functionality

2017-03-02 Thread Tor Bug Tracker & Wiki

#21604: add descriptor-id calc functionality
---+
 Reporter:  cypherpunks|  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Hi cypherpunks. Sure, I wouldn't mind adding this to the
 'stem.util.tor_tools' module if you'd find that useful. Juggling a lot of
 other things so no promises on when I'll get to it but sounds like a fine
 idea.

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

Re: [tor-bugs] #21396 [Applications/Tor Browser]: Torbutton breaks Session Manager addon

2017-03-02 Thread Tor Bug Tracker & Wiki

#21396: Torbutton breaks Session Manager addon
-+-
 Reporter:  HolD |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-6.5-regression,  |  Actual Points:
  TorBrowserTeam201703R, GeorgKoppen201702   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 r=brade, r=mcs
 The revised fix looks good and seems to work. I am sorry for our
 contribution to the bustage.

 We did notice that a lot of messages like the following are logged to the
 Browser Console, but these are not new:
  15:09:57.836 NS_ERROR_NOT_AVAILABLE: Component returned failure code:
 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannel.getResponseHeader]1
 content-policy.js:99:0

 Maybe something on https://browserleaks.com/firefox is returning a 3xx
 response code without a Location header? Kathy and I will take a look
 after we spend some time on #21514.

--
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] #21615 [Metrics/Atlas]: Use hashed fingerprint in all lookups

2017-03-02 Thread Tor Bug Tracker & Wiki

#21615: Use hashed fingerprint in all lookups
---+-
 Reporter:  cypherpunks|  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Currently the fingerprints in detailed lookups performed by the search
 page are not hashed.

--
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] #21615 [Metrics/Atlas]: Use hashed fingerprint in all lookups

2017-03-02 Thread Tor Bug Tracker & Wiki

#21615: Use hashed fingerprint in all lookups
---+---
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by irl):

 * status:  new => needs_information
 * type:  defect => enhancement


Comment:

 Atlas doesn't claim to hash fingerprints and we instead provide
 instructions on how to look up bridges using the hashed fingerprint. I'm
 not convinced this is a defect, as clearly lookups using fingerprints
 work.

 Is Onionoo generally happy to respond to hashed fingerprints in place of
 fingerprints for both relays and bridges then? What is the gain for this
 over the loss that a bridge fingerprint could be entered into the browser
 and perhaps leaked?

 I'm not saying it's a bad idea, I'm saying I'm not sure I understand the
 motivation yet.

--
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] #19538 [Metrics/Atlas]: Replace raster glyphicons with vector icons for flags

2017-03-02 Thread Tor Bug Tracker & Wiki

#19538: Replace raster glyphicons with vector icons for flags
---+---
 Reporter:  twim   |  Owner:  phw
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by irl):

 * status:  reopened => needs_information


Comment:

 If this cannot work with security set to high, I think we should abandon
 this idea. Is there a workaround?

--
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] #21614 [Metrics]: JavaDoc should contain the version number

2017-03-02 Thread Tor Bug Tracker & Wiki

#21614: JavaDoc should contain the version number
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 (This is actually a Metrics/metrics-base ticket, but that component
 doesn't exist.)

 Including the version number would be easiest in the footer (similar to
 including the year).

--
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] #21612 [Metrics/Atlas]: Handle rehashing invalid fingerprints

2017-03-02 Thread Tor Bug Tracker & Wiki

#21612: Handle rehashing invalid fingerprints
---+--
 Reporter:  cypherpunks|  Owner:  irl
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

 * 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

Re: [tor-bugs] #6355 [Metrics/Atlas]: Distinguish between running relays and non-running relays which last had the Running flag

2017-03-02 Thread Tor Bug Tracker & Wiki

#6355: Distinguish between running relays and non-running relays which last had
the Running flag
---+--
 Reporter:  karsten|  Owner:  phw
 Type:  enhancement| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by irl):

 * priority:  Medium => High
 * severity:   => Normal


--
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] #15016 [Metrics/Atlas]: atlas displays running flag for non-running relays

2017-03-02 Thread Tor Bug Tracker & Wiki

#15016: atlas displays running flag for non-running relays
---+---
 Reporter:  cypherpunks|  Owner:  phw
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by irl):

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


Comment:

 For the most part, this is a duplicate of #6355. I don't think this ticket
 adds anything.

--
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] #21415 [Core Tor/Tor]: tor_bug_occurred_: Bug: src/or/entrynodes.c:1845: select_entry_guard_for_circuit: Non-fatal assertion !(!guard_has_descriptor(guard)) failed.

2017-03-02 Thread Tor Bug Tracker & Wiki

#21415: tor_bug_occurred_: Bug: src/or/entrynodes.c:1845:
select_entry_guard_for_circuit: Non-fatal assertion
!(!guard_has_descriptor(guard)) failed.
-+
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.0.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  review-group-16  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+
Changes (by asn):

 * status:  reopened => needs_review


Comment:

 OK, after about 4 hours of debugging, I present you a fix in my branch
 `bug21415_testfix`. We are dealing with a pretty hairy multi-component
 part of the codebase, so careful consideration is required.

 Here is the commit message that might help you:
 {{{
 The bridges+ipv6-min integration test has a client with bridges:
 Bridge 127.0.0.1:5003
 Bridge [::1]:5003
 which got stuck in
 guard_selection_have_enough_dir_info_to_build_circuits()
 because it couldn't find the descriptor of both bridges.

 Specifically, the guard_has_descriptor() function could not find the
 node_t of the [::1] bridge, because the [::1] bridge had no identity
 digest assigned to it.

 After further examination, it seems that during fetching the descriptor
 for our bridges, we used the CERTS cell to fill the identity digest of
 127.0.0.1:5003 properly. However, when we received a CERTS cell from
 [::1]:5003 we actually ignored its identity digest because the
 learned_router_identity() function was using
 get_configured_bridge_by_addr_port_digest() which was returning the
 127.0.0.1 bridge instead of the [::1] bridge (because it prioritizes
 digest matching over addrport matching).

 The fix replaces get_configured_bridge_by_addr_port_digest() with the
 recent get_configured_bridge_by_exact_addr_port_digest() function. It
 also relaxes the constraints of the
 get_configured_bridge_by_exact_addr_port_digest() function by making it
 return bridges whose identity digest is not yet known.

 By using the _exact_() function, learned_router_identity() actually
 fills in the identity digest of the [::1] bridge, which then allows
 guard_has_descriptor() to find the right node_t and verify that the
 descriptor is there.

 FWIW, in the bridges+ipv6-min test both 127.0.0.1 and [::1] bridges
 correspond to the same node_t, which I guess makes sense given that it's
 actually the same underlying bridge.
 }}}

 Please let me know what you think about this fix. I thought about
 unintended consequences of the mod in
 `get_configured_bridge_by_exact_addr_port_digest()` and
 `learned_router_identity()` but I couldn't find something 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] #18599 [Applications/Tor Browser]: Make sure OffScreenCanvas API does not render moot our canvas fingerprinting protection

2017-03-02 Thread Tor Bug Tracker & Wiki

#18599: Make sure OffScreenCanvas API does not render moot our canvas
fingerprinting protection
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff52-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4
--+--
Changes (by gk):

 * sponsor:   => Sponsor4


--
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] #19048 [Applications/Tor Browser]: Review Firefox Developer Docs and Undocumented bugs since FF45esr

2017-03-02 Thread Tor Bug Tracker & Wiki

#19048: Review Firefox Developer Docs and Undocumented bugs since FF45esr
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201702  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by gk):

 Replying to [comment:9 mcs]:
 > Kathy and I reviewed the Firefox 46 and 47 changes (by looking at the
 "Firefox ## for Developers" web pages, the target_milestone=mozilla##
 bugs, and the target_milestone=Firefox%20## bugs). Before we move on to
 48-52, we wanted to note here what we found so far:
 >
 > a) `DateTimeFormat.formatToParts`. We should verify that timezone and/or
 locale not leaked to web content by new API.
 > https://bugzilla.mozilla.org/show_bug.cgi?id=1289340
 > https://developer.mozilla.org/en-
 US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/formatToParts

 That's in mozill52, right? But, yes, we should double-check that. I opened
 #21608.

 > b) Some changes were made to device orientation events. We should ensure
 that orientation is not leaked to web content.
 > https://bugzilla.mozilla.org/show_bug.cgi?id=1205649

 #21609.

 > c) The Permissions API is now enabled. Kathy and I think we should turn
 it off to prevent fingerprinting based on choices that users make.
 Unfortunately, the `dom.permissions.enabled` pref was removed.
 > https://lists.mozilla.org/pipermail/dev-platform/2015-August/011466.html
 > https://bugzilla.mozilla.org/show_bug.cgi?id=1233702

 #21569.

 > d) TouchEvents are now enabled on Windows and Linux. I already poked
 #10286.
 >
 > e) window.showModalDialog() is not available when e10s is enabled.
 Should we always make it unavailable (even when e10s is disabled)? Or
 maybe we don't care because we will probably enable e10s for all Tor
 Browser users or none.
 > https://bugzilla.mozilla.org/show_bug.cgi?id=1234700

 I think we should not care. Besides that it seems that non of our code is
 using `showModalDialog()` anyway.

 > f) Looking through the bug lists reminded us about Web Animations
 possibly providing a high resolution timing source. But we do have #18273
 for that issue.

 I guess you mean #16337?

 > g) Similarly, we were reminded about WebAudio. See #13017.
 >
 > h) We will need to set `network.dns.blockDotOnion = false`.

 Hm. You mean for the transparent proxying option?

 > i) Should we disable about:profiles? Some of the functionality will
 confused our users, e.g., "Create New Profile" which may not work
 correctly on Linux and Windows and "Restart with Add-ons Disabled."
 > https://bugzilla.mozilla.org/show_bug.cgi?id=1235402

 Yes. I opened #21610.

 > j) A DNS lookup feature was added to about:networking DNS. We should
 verify that it respects the browser proxy settings.
 > https://bugzilla.mozilla.org/show_bug.cgi?id=907050

 #21611.

 > k) Is the Fetch API safe? It includes fetch events with mode=navigate,
 and Kathy and I are not sure if there are any linkability concerns with
 that API.
 > https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

 This is already #16326. Or did you find something new we should look at?

 Additional things I found:

 l) Remaining things for offscreen canvas got implemented in
 https://bugzilla.mozilla.org/show_bug.cgi?id=1172796. We should make sure
 that they are disabled as well (I updated #18599).

 m) windows are maximized on first run on small screens:
 https://bugzilla.mozilla.org/show_bug.cgi?id=384336 I'll have that in mind
 while reviewing the rebased patches in #20680.

 n) There is a "What's new" item on the about dialog pointing to Mozilla
 resources: https://bugzilla.mozilla.org/show_bug.cgi?id=1047395 I guess we
 should point to our blog post instead. I opened #21613.

--
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] #21613 [Applications/Tor Browser]: What's new? item on about dialog should not point to Mozilla page

2017-03-02 Thread Tor Bug Tracker & Wiki

#21613: What's new? item on about dialog should not point to Mozilla page
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff52-esr
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor4  |
--+--
 There is a What's new? item on the about page pointing to Mozilla. We
 should fix that and point to our release blog post instead I guess.

--
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] #21612 [Metrics/Atlas]: Handle rehashing invalid fingerprints

2017-03-02 Thread Tor Bug Tracker & Wiki

#21612: Handle rehashing invalid fingerprints
---+-
 Reporter:  cypherpunks|  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 The search and details pages rehash given fingerprints using the
 `hashFingerprints` function before looking them up. This function isn't
 strict enough in detecting fingerprints which results in the function
 passing invalid hex strings to the jssha library. The library then gives
 the following error in the console and the page gets stuck on the loading
 screen.

 {{{
 uncaught exception: srcString of HEX type must be in byte increments
 }}}

 This is reproducible with the following urls

 GOOD
 https://atlas.torproject.org/#details/BC630CBBB518BE7E9F4E09712AB0269E9DC7D626
 BAD
 https://atlas.torproject.org/#details/BC630CBBB518BE7E9F4E09712AB0269E9DC7D6261

 GOOD
 https://atlas.torproject.org/#search/BC630CBBB518BE7E9F4E09712AB0269E9DC7D626
 BAD
 https://atlas.torproject.org/#search/BC630CBBB518BE7E9F4E09712AB0269E9DC7D6261

 The fix is simple and a patch is coming once i get the ticket number.

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

1 2 >

1 - 100 of 163 matches

Mail list logo