Re: [tor-bugs] #18101 [Applications/Tor Browser]: IP leak from Windows UI dialog with URI

[Tor Bug Tracker & Wiki]

#18101: IP leak from Windows UI dialog with URI
-+-
 Reporter:  uileak   |  Owner:  gk
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-proxy-bypass, ip-leak,   |  Actual Points:
  TorBrowserTeam201702, GeorgKoppen201702|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by elisebenine):

 could it be something related to browser's File API? noticed the same on
 http://internetvergelijken.nl/ today.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21650 [Core Tor/Tor]: prop140: Clients request diffs and handle diffs in replies

[Tor Bug Tracker & Wiki]

#21650: prop140: Clients request diffs and handle diffs in replies
--+
 Reporter:  nickm |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #13339| Points:  4
 Reviewer:|Sponsor:  Sponsor4
--+

Comment (by teor):

 Clients have a hard-coded list of authorities and fallback directories.
 They use this list to bootstrap when their consensus is outdated (older
 than 24 hours or so).
 Do clients ever want to download consensus diffs from these hard-coded
 addresses at bootstrap time?
 (I think the answer is no, but we should make this clear in the proposal)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20522 [Core Tor/Tor]: Enable DISABLE_DISABLING_ED25519

[Tor Bug Tracker & Wiki]

#20522: Enable DISABLE_DISABLING_ED25519
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ed25519-proto, triage-   |  Actual Points:
  out-030-201612 |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  SponsorZ
-+-

Comment (by teor):

 How can we make sure relay operators know what's going on when this
 happens?
 Can we warn them before it does?

 For example, #21636 adds the NoEdConsensus flag to Atlas.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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

[Tor Bug Tracker & Wiki]

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

Comment (by isis):

 Replying to [comment:4 gk]:
 > Could someone with Twitter presence double-check that this is not a 6.5
 regression by trying to hit the like buttons with 6.0.8?

 With `network.cookie.cookieBehavior` set to 1 on 6.0.8, both retweets and
 likes are broken. Setting the pref to 0 fixes 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] #21642 [Core Tor/Tor]: Prop275: Eliminate "published" times from microdescriptor consensus

[Tor Bug Tracker & Wiki]

#21642: Prop275: Eliminate "published" times from microdescriptor consensus
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201703  |  Actual Points:  .5
Parent ID: | Points:  2
 Reviewer: |Sponsor:  Sponsor4
---+

Comment (by teor):

 Replying to [comment:3 nickm]:
 > To review:
 >   * In my public tor repository, `prop275_minimal_029`, which permits
 published times to be in the future without breaking Tor.

 I thought we were only doing security backports to 0.2.9?
 Or does LTS buy us more latitude for change?

 > For later:
 >   * #21669 tracks the change where we eventually make the 'published'
 times uniform.

 The ticket #21669 doesn't exist 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] #21678 [Core Tor/Tor]: Unify Windows and Unix API for tor_read_all_handle() in util.c

[Tor Bug Tracker & Wiki]

#21678: Unify Windows and Unix API for tor_read_all_handle() in util.c
--+
 Reporter:  ahf   |  Owner:  ahf
 Type:  enhancement   | Status:  accepted
 Priority:  Low   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #21654| Points:
 Reviewer:|Sponsor:
--+

Comment (by ahf):

 I've added an untested patch to
 https://gitlab.com/ahf/tor/commits/bugs/21678 - it would be useful to get
 someone with a Windows machine to try it out. Otherwise, I'll try to get a
 Windows environment up and running and try it out there.


 I'm not marking this issue as `needs_review` since the code is still
 untested.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21666 [Core Tor/Tor]: Prop278: Code to decide whether we want to request and/or provide CPU-intensive compression methods

[Tor Bug Tracker & Wiki]

#21666: Prop278: Code to decide whether we want to request and/or provide CPU-
intensive compression methods
---+
 Reporter:  ahf|  Owner:
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201703  |  Actual Points:
Parent ID: | Points:  4
 Reviewer: |Sponsor:  Sponsor4
---+

Comment (by teor):

 Is the compression happening on the main thread?
 Because many tor relays are main-thread CPU bound, but have extra cores.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21654 [Core Tor/Tor]: Don't use fgets() when we might get EAGAIN

[Tor Bug Tracker & Wiki]

#21654: Don't use fgets() when we might get EAGAIN
--+--
 Reporter:  nickm |  Owner:  ahf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by ahf):

 * status:  needs_revision => needs_review


Comment:

 I've updated https://gitlab.com/ahf/tor/commits/bugs/21654 to add an
 additional patch that refactors out our usage of `FILE*` in the Unix paths
 in the utility functions around `process_handle_t`.

 I've also opened #21678 which is a refactoring patch which is related to
 this issue, but I do not have access to a Windows machine to test it on
 currently.

 This additional patch passes `make check` on OS X, Linux (glibc), OpenBSD,
 FreeBSD, and HardenedBSD.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21678 [Core Tor/Tor]: Unify Windows and Unix API for tor_read_all_handle() in util.c

[Tor Bug Tracker & Wiki]

#21678: Unify Windows and Unix API for tor_read_all_handle() in util.c
--+
 Reporter:  ahf   |  Owner:  ahf
 Type:  enhancement   | Status:  accepted
 Priority:  Low   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #21654| Points:
 Reviewer:|Sponsor:
--+
Changes (by ahf):

 * owner:   => ahf
 * status:  new => accepted


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

[tor-bugs] #21678 [Core Tor/Tor]: Unify Windows and Unix API for tor_read_all_handle() in util.c

[Tor Bug Tracker & Wiki]

#21678: Unify Windows and Unix API for tor_read_all_handle() in util.c
--+
 Reporter:  ahf   |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #21654
   Points:|   Reviewer:
  Sponsor:|
--+
 While working on #21654 I noticed that we have some different code paths
 that depends upon whether we're running on Windows or not where it would
 be trivial to turn them into a single code path.

 I do not have access to a Windows machine right now, so it would be useful
 if someone could help test the patch(es).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21661 [Core Tor/Tor]: Proactive Response and Detection of TOR Anonymizers

[Tor Bug Tracker & Wiki]

#21661: Proactive Response and Detection of TOR Anonymizers
---+---
 Reporter:  Dbryrtfbcbhgf  |  Owner:
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

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


Comment:

 It's not a realistic attack, nor a quality paper.
 Pluggable transports like obfs4 should be sufficient.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #7164 [Core Tor/Tor]: microdesc.c:378: Bug: microdesc_free() called, but md was still referenced 1 node(s); held_by_nodes == 1

[Tor Bug Tracker & Wiki]

#7164: microdesc.c:378: Bug: microdesc_free() called, but md was still 
referenced
1 node(s); held_by_nodes == 1
-+-
 Reporter:  jaj123   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.19
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, 025-backport, nickm- |  Actual Points:
  should-review, TorCoreTeam201609   |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * milestone:  Tor: unspecified => Tor: 0.3.2.x-final


Comment:

 Duplicate in #21640, aspirationally moving this to 0.3.2, because it would
 be great to 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] #20916 [Core Tor/Tor]: Inconsistent IPv6 address between consensus and microdescriptor

[Tor Bug Tracker & Wiki]

#20916: Inconsistent IPv6 address between consensus and microdescriptor
-+-
 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:  needs-proposal, ipv6, regression,|  Actual Points:
  triage-out-030-201612  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  ipv6, regression, triage-out-030-201612 => needs-proposal,
 ipv6, regression, triage-out-030-201612
 * owner:   => teor
 * status:  new => assigned


Comment:

 This also makes it easier for IPv6 clients to bootstrap, and makes happy-
 eyeballs-style IPv6 detection possible.

 We'll need a short proposal for this explaining why it will work (and why
 it gets better once we have consensus diffs).

 One decision will be:
 * do we move IPv6 addresses from the microdesc to microconsensus in one
 consensus method?
  * (clients will be fine, back to 0.2.8 where we made IPv6 from the
 consensus work)
 * or, do we have one method to add them to the microconsensus, and another
 to remove them from the microdesc in a later release?

 (The staged option seems much more sensible, but maybe we could make them
 N & N+1 in the same release, in case we need to run with both for a while
 due to an unexpected bug.)

 Some tools and external code might need to adapt. But much external code
 uses the full consensus anyway.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21677 [Core Tor/Tor]: Prop140: analyze diff performance

[Tor Bug Tracker & Wiki]

#21677: Prop140: analyze diff performance
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #13339| Points:
 Reviewer:|Sponsor:  Sponsor4
--+
Changes (by nickm):

 * 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

[tor-bugs] #21677 [Core Tor/Tor]: Prop140: analyze diff performance

[Tor Bug Tracker & Wiki]

#21677: Prop140: analyze diff performance
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #13339
   Points:|   Reviewer:
  Sponsor:|
--+


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

[tor-bugs] #21676 [Core Tor/Tor]: Increase MIN_BW_TO_ADVERTISE_DIRSERVER above RELAY_REQUIRED_MIN_BANDWIDTH

[Tor Bug Tracker & Wiki]

#21676: Increase MIN_BW_TO_ADVERTISE_DIRSERVER above 
RELAY_REQUIRED_MIN_BANDWIDTH
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  0.2   |   Reviewer:
  Sponsor:|
--+
 MIN_BW_TO_ADVERTISE_DIRSERVER is 50KB, but RELAY_REQUIRED_MIN_BANDWIDTH is
 75KB. So we might want to make the DIRSERVER bandwidth at least 150 KB, so
 that a dirserver can at least deliver one client one consensus in 10
 seconds (clients generally wait a few seconds for dirservers to deliver a
 consensus).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21654 [Core Tor/Tor]: Don't use fgets() when we might get EAGAIN

[Tor Bug Tracker & Wiki]

#21654: Don't use fgets() when we might get EAGAIN
--+--
 Reporter:  nickm |  Owner:  ahf
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * status:  needs_review => needs_revision


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21654 [Core Tor/Tor]: Don't use fgets() when we might get EAGAIN

[Tor Bug Tracker & Wiki]

#21654: Don't use fgets() when we might get EAGAIN
--+--
 Reporter:  nickm |  Owner:  ahf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 Hm.  I wonder if we should propagate this switch from FILE to fileno even
 higher in the read_all_handle code.  That is, on anything where we call
 tor_read_all_handle, we shouldn't be using fgets() at all: It's not safe
 to mix buffered IO (like FILE) does and non-buffered IO.

 Alternatively, for an easier alternative, we can try turning off buffering
 on these particular FILEs.  I forget how to do that.  setvbuf?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21654 [Core Tor/Tor]: Don't use fgets() when we might get EAGAIN

[Tor Bug Tracker & Wiki]

#21654: Don't use fgets() when we might get EAGAIN
--+--
 Reporter:  nickm |  Owner:  ahf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by ahf):

 * status:  assigned => needs_review


Comment:

 I've made a patch on branch 'bugs/21654' in my Gitlab Tor repository:

 https://gitlab.com/ahf/tor/commits/bugs/21654

 This patch should hopefully make the race condition go away for good.

 I've tested it on Linux (glibc), FreeBSD, HardenedBSD, OS X, and OpenBSD.
 Thanks to rubiate in #tor-dev for providing me access to an OpenBSD host.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21616 [Internal Services/Service - git]: Permission to commit to torflow

[Tor Bug Tracker & Wiki]

#21616: Permission to commit to torflow
-+---
 Reporter:  tom  |  Owner:  mikeperry
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by Sebastian):

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


Comment:

 [x]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21644 [Core Tor/Tor]: Prop140: Fuzz the diff and patch code

[Tor Bug Tracker & Wiki]

#21644: Prop140: Fuzz the diff and patch code
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  task   | Status:  accepted
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201703  |  Actual Points:
Parent ID:  #13339 | Points:  1
 Reviewer: |Sponsor:  Sponsor4
---+

Comment (by nickm):

 I spoke too soon: found my first crash bug, and fixed it: 89ec2eced55b72

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21616 [Internal Services/Service - git]: Permission to commit to torflow

[Tor Bug Tracker & Wiki]

#21616: Permission to commit to torflow
-+---
 Reporter:  tom  |  Owner:  mikeperry
 Type:  defect   | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by mikeperry):

 * status:  closed => reopened
 * component:  Internal Services/Tor Sysadmin Team => Internal
 Services/Service - git
 * resolution:  invalid =>


Comment:

 As a committer of TorFlow, I approve tjr having commit access to TorFlow.

 tjr - please do bring more complicated things like #20619 to my attention
 before merging (I still need to think about that one, but it is probably
 fine. The rest seem 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] #21622 [Core Tor/Tor]: Log a message when a hidden service delays new introduction point circuits

[Tor Bug Tracker & Wiki]

#21622: Log a message when a hidden service delays new introduction point 
circuits
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  needs_review
 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:  dgoulet   |Sponsor:  SponsorR-can
--+
Changes (by dgoulet):

 * reviewer:   => dgoulet
 * sponsor:   => SponsorR-can


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21644 [Core Tor/Tor]: Prop140: Fuzz the diff and patch code

[Tor Bug Tracker & Wiki]

#21644: Prop140: Fuzz the diff and patch code
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  task   | Status:  accepted
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201703  |  Actual Points:
Parent ID:  #13339 | Points:  1
 Reviewer: |Sponsor:  Sponsor4
---+

Comment (by nickm):

 I've added preliminary fuzzing support, and in the process found some bugs
 in my wrappers.  More work needed.  Should let fuzzers run longer.  At
 least they seem not to crash 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] #18559 [Applications/Tor Browser]: Number of logical processors is detectable from web content

[Tor Bug Tracker & Wiki]

#18559: Number of logical processors is detectable from web content
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-fingerprinting, ff52-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4
--+--

Comment (by gk):

 We have #21675 for `window.navigator.hardwareConcurrency` now. While it
 would be neat to deal with "leaking the number of cores" once and for all.
 Defending against the probabilistic approach mentioned in this ticket
 might be harder than dealing with the low hanging fruit in #21675. Hence
 two tickets.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21675 [Applications/Tor Browser]: Set window.navigator.hardwareConcurrency to a constant value

[Tor Bug Tracker & Wiki]

#21675: Set window.navigator.hardwareConcurrency to a constant value
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-fingerprinting, ff52-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4
--+--
Description changed by gk:

Old description:

> We should avoid leaking the amount of CPUs a user has available by asking
> `window.navigator.hardwareConcurrency`. Not sure which value we should
> give back and if we should return the same one for all users.

New description:

 We should avoid leaking the amount of cores a user has available by asking
 `window.navigator.hardwareConcurrency`. Not sure which value we should
 give back and if we should return the same one for all 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] #21675 [Applications/Tor Browser]: Set window.navigator.hardwareConcurrency to a constant value

[Tor Bug Tracker & Wiki]

#21675: Set window.navigator.hardwareConcurrency to a constant value
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-fingerprinting, ff52-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4
--+--

Comment (by gk):

 Note, there is #18559 where a probabilistic means is used to detect the
 number of cores.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21675 [Applications/Tor Browser]: Set window.navigator.hardwareConcurrency to a constant value

[Tor Bug Tracker & Wiki]

#21675: Set window.navigator.hardwareConcurrency to a constant value
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-fingerprinting,
 Severity:  Normal   |  ff52-esr
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:  Sponsor4 |
-+-
 We should avoid leaking the amount of CPUs a user has available by asking
 `window.navigator.hardwareConcurrency`. Not sure which value we should
 give back and if we should return the same one for all 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] #19048 [Applications/Tor Browser]: Review Firefox Developer Docs and Undocumented bugs since FF45esr

[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, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201703, GeorgKoppen201703|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by gk):

 Replying to [comment:17 mcs]:
 > Replying to [comment:15 gk]:
 > > Replying to [comment:9 mcs]:
 > > > 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.
 >
 > Okay. Kathy and I were thinking about regular web pages using that API
 and/or detecting that it is not available. But there are probably other
 ways to detect that e10s is enabled.

 I made a note in #21432. Maybe we find some good solution to the "e10s and
 fingerprinting" issue.

 > > > h) We will need to set `network.dns.blockDotOnion = false`.
 > >
 > > Hm. You mean for the transparent proxying option?
 >
 > I was thinking that the Firefox code would block .onion requests even
 when they go through the SOCKS proxy. But you may be correct.

 I opened #21674 for investigating 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] #21674 [Applications/Tor Browser]: Do we need to set network.dns.blockDotOnion to false in ESR 52?

[Tor Bug Tracker & Wiki]

#21674: Do we need to set network.dns.blockDotOnion to false in ESR 52?
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff52-esr
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor4  |
--+--
 `network.dns.blockDotOnion` is set to `false` in Firefox but we might need
 to set it to `true` in Tor Browser for transparent proxying. At least that
 is indicated by https://bugzilla.mozilla.org/show_bug.cgi?id=1228457#c18.
 We should investigate that.

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

Re: [tor-bugs] #21432 [Applications/Tor Browser]: Make a plan on how to deploy e10s in Tor Browser

[Tor Bug Tracker & Wiki]

#21432: Make a plan on how to deploy e10s in Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201703   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Just to note this here: e10s in its current form probably brings some
 fingerprinting risks with it. e.g. users of accessibility tools won't have
 e10s enabled on Windows and macOS at least. Windows XP users with D3D9
 support neither. mcs and brade found that `showModalDialog()` is not
 available when e10s is enabled etc. Not sure whether we can do anything
 about that and whether we should.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => needs_information


Comment:

 Here are test builds with the patch applied. Can anybody hitting this
 issue in the wild confirm that those builds work while the currently
 released ones don't? Plus, while we are at it, can anybody test whether
 the tweetdeck login problem (aka #16540) goes away with that patch as
 well?

 https://people.torproject.org/~gk/testbuilds/tor-browser-linux32-tbb-
 nightly_ALL_21555.tar.xz
 https://people.torproject.org/~gk/testbuilds/tor-browser-linux32-tbb-
 nightly_ALL_21555.tar.xz.asc

 https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-tbb-
 nightly_ALL_21555.tar.xz
 https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-tbb-
 nightly_ALL_21555.tar.xz.asc

 https://people.torproject.org/~gk/testbuilds/torbrowser-install-tbb-
 nightly_ALL_21555.exe
 https://people.torproject.org/~gk/testbuilds/torbrowser-install-tbb-
 nightly_ALL_21555.exe.asc

 https://people.torproject.org/~gk/testbuilds/TorBrowser-tbb-nightly-
 osx64_ALL_21555.dmg
 https://people.torproject.org/~gk/testbuilds/TorBrowser-tbb-nightly-
 osx64_ALL_21555.dmg.asc

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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

[Tor Bug Tracker & Wiki]

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

Comment (by mcs):

 r=brade, r=mcs
 Kathy and I did not verify that this fixes the problem, but the patch
 looks good.

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

Re: [tor-bugs] #21673 [Core Tor/Tor]: prop140: Handle signatures correctly

[Tor Bug Tracker & Wiki]

#21673: prop140: Handle signatures correctly
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #13339| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 My #21643 branch switches to sha3 and covers the entire document, but
 doesn't yet create or enforce a consistent signature ordering.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21673 [Core Tor/Tor]: prop140: Handle signatures correctly

[Tor Bug Tracker & Wiki]

#21673: prop140: Handle signatures correctly
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #13339| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:   => nickm
 * status:  new => accepted


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

[tor-bugs] #21673 [Core Tor/Tor]: prop140: Handle signatures correctly

[Tor Bug Tracker & Wiki]

#21673: prop140: Handle signatures correctly
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #13339
   Points:|   Reviewer:
  Sponsor:|
--+
 For diffs to work properly, we need to check the input document and the
 output document in their entirety, including their signatures.  Otherwise,
 the diffs won't apply correctly when they change the signatures!

 But for *that* to work, we need to do what we can to minimize the odds
 that anybody has a consensus with different signatures, or with signatures
 organized differently.

 As an alternative, we could change the diff format so that it always
 replaces all the old signatures with the new ones.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21643 [Core Tor/Tor]: Prop140: Extract, test, revise, and clean the diff code

[Tor Bug Tracker & Wiki]

#21643: Prop140: Extract, test, revise, and clean the diff code
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201703  |  Actual Points:
Parent ID:  #13339 | Points:  3
 Reviewer: |Sponsor:  Sponsor4
---+

Comment (by nickm):

 Okay, now the branch is up to 100% coverage.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21547 [Applications/Tor Browser]: e10s and 52esr compatibility for tor circuit display

[Tor Bug Tracker & Wiki]

#21547: e10s and 52esr compatibility for tor circuit display
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton,   |  Actual Points:
  TorBrowserTeam201703R, ff52-esr, tbb-7.0-must  |
Parent ID:  #21201   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Kathy and I reviewed the code and ran it with a browser built from your
 tor-browser.git 20680+4 branch. Circuit display seems to work, but we see
 quite a few messages like this:
  Torbutton INFO: Failed to get credentials or browser from channel

 We modified the code to log the exception and chan.URI.spec. Here is an
 example:
  `[Exception... "Component returned failure code: 0x80004002
 (NS_NOINTERFACE) [nsIInterfaceRequestor.getInterface]"  nsresult:
 "0x80004002 (NS_NOINTERFACE)"  location: "JS frame ::
 chrome://torbutton/content/tor-circuit-display.js :: browserForChannel ::
 line 163"  data: no]`
  uri: https://check.torproject.org/torcheck/img/tor-on.png

 The above error occurred while loading
 https://check.torproject.org/?lang=en_US; we also see similar messages for
 many "internal" fetches such as OSCP which is not as surprising.

 We should figure out a way to suppress the logging for errors that are
 expected. When we do log, we may want to include the exception as well as
 chan.URI.spec to make debugging easier.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21652 [Internal Services/Tor Sysadmin Team]: Finishing touches for onionperf setup on papillare.

[Tor Bug Tracker & Wiki]

#21652: Finishing touches for onionperf setup on papillare.
-+
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


Comment:

 ok, thanks for explaining things on IRC.

 After the nightly job has created all the files on papillare, please run
 `static-update-component onionperf.torproject.org` - that will update the
 user visible content on https://onionperf.torproject.org/

 Cheers,

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21643 [Core Tor/Tor]: Prop140: Extract, test, revise, and clean the diff code

[Tor Bug Tracker & Wiki]

#21643: Prop140: Extract, test, revise, and clean the diff code
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201703  |  Actual Points:
Parent ID:  #13339 | Points:  3
 Reviewer: |Sponsor:  Sponsor4
---+

Comment (by nickm):

 After some tweaks, I can measure coverage again.  Coverage on consdiff.c
 is at 90%, which isn't bad, but we should get it higher.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21309 [Applications/Tor Browser]: Fix Omnibox for TBB/52ESR

[Tor Bug Tracker & Wiki]

#21309: Fix Omnibox for TBB/52ESR
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201703R  |
Parent ID:  #20680   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by mcs):

 Replying to [comment:12 arthuredelstein]:
 > For some reason removing all but the default entry doesn't work, even
 for US English. nsSearchService.js is pretty convoluted so I'm not sure
 why. My current approach is to change all locales we deploy to include the
 same search engine list, and then rely on our #18915 patches for tor-
 browser-bundle.git to copy these search engines and the list to each
 locale xpi. It's awkward, but it seems like it should work. Unfortunately
 I'm having trouble getting tor-browser-bundle.git to build right now, so I
 haven't fully tested this. But here is the patch in any case:
 >
 > https://github.com/arthuredelstein/tor-browser/commit/21309+1

 This patch looks okay, except should the URLs in ddg-onion.xml be https
 instead of http?

 Regarding the changes needed for packaging (builders/tor-browser-
 bundle.git), Kathy and I wonder if it will work to simply remove
 `browser/chrome/$LOCALE/locale/browser/searchplugins` from each of the
 language packs. But we have not tried 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] #21652 [Internal Services/Tor Sysadmin Team]: Finishing touches for onionperf setup on papillare.

[Tor Bug Tracker & Wiki]

#21652: Finishing touches for onionperf setup on papillare.
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by weasel):

 Replying to [comment:2 hiro]:
 > Twisted serves the directory of files and it is started by onionperf in
 > measurement mode. If it is possible I'd like to keep the setup as in the
 other
 > machines and have the server running.

 If it's really just serving static files, I'd prefer we don't expose
 twisted to
 the network.  How much data is in those static files and how often do they
 change?

 > Here are the packages that I would need installed to get rid of
 virtualenv:
 > python-stem python-twisted python-lxml python-networkx python-matplotlib
 python-numpy python-scipy
 Installed.

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

Re: [tor-bugs] #21643 [Core Tor/Tor]: Prop140: Extract, test, revise, and clean the diff code

[Tor Bug Tracker & Wiki]

#21643: Prop140: Extract, test, revise, and clean the diff code
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201703  |  Actual Points:
Parent ID:  #13339 | Points:  3
 Reviewer: |Sponsor:  Sponsor4
---+

Comment (by nickm):

 I've extracted the diff/patch code (and only the diff/patch code) from the
 rebased consdiff branch into a new branch, `prop140_21643_diff_only`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21652 [Internal Services/Tor Sysadmin Team]: Finishing touches for onionperf setup on papillare.

[Tor Bug Tracker & Wiki]

#21652: Finishing touches for onionperf setup on papillare.
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 Hi,

 so a little bit of background.

 Twisted serves the directory of files and it is started by onionperf in
 measurement mode. If it is possible I'd like to keep the setup as in the
 other machines and have the server running. We can redirect to port 8081
 all the request, it doesn't need to run on port 80. Sorry for the
 confusion. In fact, I would redirect everything over https (80 included).

 We can get rid of virtualenv it is not strictly needed. I used to pull a
 few (very few) updated packages, but we can use the deb version.

 Here are the packages that I would need installed to get rid of
 virtualenv:

 python-stem python-twisted python-lxml python-networkx python-matplotlib
 python-numpy python-scipy

 I hope this clarifies everything.

 Let me know if is there anything else I should add.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #13339 [Core Tor/Tor]: Prop140: Complete Consensus diffs / Merge GSoC project

[Tor Bug Tracker & Wiki]

#13339: Prop140: Complete Consensus diffs / Merge GSoC project
-+-
 Reporter:  mvdan|  Owner:
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  gsoc, merge, tor-client, prop140,|  Actual Points:
  027-triaged-1-in, 028-triaged, pre028-patch,   |
  tor-dos, low-bandwidth, nickm- |
  deferred-20160905, tor-03-unspecified-201612,  |
  sponsor4 TorCoreTeam201703 |
Parent ID:   | Points:  parent
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by nickm):

 Thanks, Daniel!  I'll let you know as any questions come up.  Right now I
 think it's mainly going to be a bunch of additional testing and
 refactoring.

 I just did a rebase, plus some code updates as a branch `consdiff_rebased`
 in my public repository.  My next plan is to split it into the consdiff
 parts and the other parts, and start working through them independently.

 Thanks again for all your work here: I hope we can finally get it to go
 live in a couple of months.  You might be interested to know that it will
 be of even greater benefit now than it would have been two years ago: see
 the updates to proposal 140, and proposals 274-278.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21438 [Internal Services/Tor Sysadmin Team]: retire orestis

[Tor Bug Tracker & Wiki]

#21438: retire orestis
-+
 Reporter:  karsten  |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


Comment:

 the new orestis now is just an ssl terminating caching frontend

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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

[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):

 Great catch! Thanks for the patch :) Also, I removed the "is/was"
 replacement and added a "Last seen" line instead, to make it more clear
 that the specific flag info is outdated. What do you think?

 
https://github.com/RaphaelBergmann/atlas/commit/574b26d1688ff7e4d253065553b2468bccb50959

 [[Image(http://cc-ltd.net/trac/offline2.png, 700)]]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21272 [Metrics]: Onionperf deployment

[Tor Bug Tracker & Wiki]

#21272: Onionperf deployment
-+--
 Reporter:  hiro |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by hiro):

 Let's encrypt is running. New domain names are:

 - op-us.onionperf.torproject.net

 - op-nl.onionperf.torproject.net

 Working on tpo setup.

 For OFT Cloud we have a new location available: Hong Kong. Are we
 interested in setting this up?

 Regarding the tpf files not showing up in the directory. Logs are
 generated but files are not "packed" into tpf at midnight. I am trying to
 investigate why this is happening.

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

[tor-bugs] #21672 [User Experience/Website]: Update Matt's description

[Tor Bug Tracker & Wiki]

#21672: Update Matt's description
-+--
 Reporter:  sysrqb   |  Owner:  hiro
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Hi!

 Currently my description on the website says:
 {{{
 Matt Finkel, Developer
 Has helped maintain and develop BridgeDB, OONI, and many other
 projects.
 }}}

 I think this is great except for including OONI. To be fair, I never
 worked on OONI (I represented the OONI team once a few years ago), so I
 don't deserve any credit for their amazing work.

 A new version that I feel less bad about is:
 {{{
 Matt Finkel, Developer, Trainer, Outreacher
 Helps in various areas. Worked on tor, torsocks, and many other
 projects.
 Helped maintain and develop BridgeDB.
 }}}

 Feel free to tweak it as needed. I can sign this request if you need it.

 Thanks!

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

Re: [tor-bugs] #21621 [Core Tor/Tor]: Intro points can get stuck in CIRCUIT_PURPOSE_S_ESTABLISH_INTRO

[Tor Bug Tracker & Wiki]

#21621: Intro points can get stuck in CIRCUIT_PURPOSE_S_ESTABLISH_INTRO
--+
 Reporter:  teor  |  Owner:  teor
 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:
Parent ID:  #21446| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Thanks, Teor!  Two requests.

 1. If you're going to use `BUG(intro->time_launched > now)`, you should
 probably use one of the monotonic time functions, not time().

 2. Could you rebase this onto master, without the changes from other
 tickets that have already been (squashed and) merged?  I tried to do it
 myself, but I ran into conflicts.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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

[Tor Bug Tracker & Wiki]

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

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


Comment:

 okay, that's persuasive.  Merging to 030.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21540 [Core Tor/Tor]: Warning "Failure from drain_fd"

[Tor Bug Tracker & Wiki]

#21540: Warning "Failure from drain_fd"
--+
 Reporter:  PjotrV|  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Low   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.9
 Severity:  Minor | Resolution:
 Keywords:  supressed |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * priority:  Medium => Low


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21540 [Core Tor/Tor]: Warning "Failure from drain_fd"

[Tor Bug Tracker & Wiki]

#21540: Warning "Failure from drain_fd"
--+
 Reporter:  PjotrV|  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.9
 Severity:  Minor | Resolution:
 Keywords:  supressed |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:   => nickm
 * status:  new => accepted


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

Re: [tor-bugs] #21028 [Core Tor/Tor]: tor never checks TLS certificate lifetimes

[Tor Bug Tracker & Wiki]

#21028: tor never checks TLS certificate lifetimes
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:  security  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21658 [Metrics/Atlas]: Do not attempt to plot graphs when the actual request for bandwidth data failed

[Tor Bug Tracker & Wiki]

#21658: Do not attempt to plot graphs when the actual request for bandwidth data
failed
---+-
 Reporter:  irl|  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #6762  | Points:
 Reviewer: |Sponsor:
---+-
Changes (by irl):

 * parent:   => #6762


Comment:

 I've added #6762 as the parent ticket to help us track these.

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

Re: [tor-bugs] #16149 [Applications/Tor Browser]: The newChannel() API is deprecated and broken in Tor Browser based on ESR 52

[Tor Bug Tracker & Wiki]

#16149: The newChannel() API is deprecated and broken in Tor Browser based on 
ESR
52
--+--
 Reporter:  gk|  Owner:  gk
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff59-esr, tbb-torbutton   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:  ff52-esr, tbb-torbutton => ff59-esr, tbb-torbutton


Comment:

 Still available in esr52 moving to ff59-esr then.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20348 [Metrics/Censorship analysis]: Kazakhstan blocking of vanilla Tor and obfs4 by Allot Communications hardware, 2016-06

[Tor Bug Tracker & Wiki]

#20348: Kazakhstan blocking of vanilla Tor and obfs4 by Allot Communications
hardware, 2016-06
-+-
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

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


Comment:

 Don't reopen!
 Your project useless anyway, you kickbans only.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #15988 [Applications/Tor Browser]: Update Tor Browser design documentation for 6.5

[Tor Bug Tracker & Wiki]

#15988: Update Tor Browser design documentation for 6.5
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-spec, TorBrowserTeam201703R, |  Actual Points:
  GeorgKoppen201703  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_information => needs_revision


Comment:

 Replying to [comment:56 mikeperry]:
 > Ok, I attached a second follow-on patch that updates the speculative
 connect subsection. It gives what I hope is a more clear description of
 what we do and why we do it. It is written assuming that rel=prefetch and
 rel=prerender are also properly isolated for cache and other state via the
 existing rel=preconnect patch. If the investigation in #21657 finds this
 not to be the case, then we need to either fix it, or disable prefetching
 and prerendering and update this patch to say so.
 >
 > Leaving this as needs_information until #21657 is resolved for that
 reason.

 {{{
 Explicit preconnects via the rel attribute are still
 performed, however.
 }}}

 This is muddying the waters because `rel="preconnect"` things are not
 performed even if they are explicit. You linked to the bug in the sentence
 before the quote which is explaining the findings. The terminal output
 indicating that there is indeed a connection is lying as those preconnect
 things are cancelled at a deeper level.

 An easy way to fix this is by picking up the distincion you made by adding
 "and prefetched" into the section caption:
 {{{
 Prefetches via the rel attribute are still performed,
 however.
 }}}
 This would make it clear that we are making a somewhat similar distinction
 to the spec which has resource hint links and speculative fetches
 (confusingly, though, `prefetch` and `prerender` are mentioned as example
 of the former as well (section 2) but looking at the spec further down it
 seems to talk only about speculative fetches in relation to them).

 Marking this second fixup as `needs_revision`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #6762 [Metrics/Atlas]: Make Atlas more robust to inconsistent Onionoo replies

[Tor Bug Tracker & Wiki]

#6762: Make Atlas more robust to inconsistent Onionoo replies
---+-
 Reporter:  karsten|  Owner:  hellais
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 This is somewhat related to #21658.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21658 [Metrics/Atlas]: Do not attempt to plot graphs when the actual request for bandwidth data failed

[Tor Bug Tracker & Wiki]

#21658: Do not attempt to plot graphs when the actual request for bandwidth data
failed
---+-
 Reporter:  irl|  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 This is somewhat related to #6762.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #8918 [Applications/Tor Browser]: Windows paging file contains Tor Browser Bundle filename

[Tor Bug Tracker & Wiki]

#8918: Windows paging file contains Tor Browser Bundle filename
--+--
 Reporter:  runa  |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-disk-leak |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:5 gk]:
 > Please, don't invent new keywords out of the box and don't close tickets
 even if there is no obvious workaround or fix imaginable at the moment.
 Thanks.
 Unless you encrypt all of Firefox's memory with an encryption key, and put
 that encryption key in non-paged memory, then you're not going to be able
 to keep all of Firefox off of the disk. Imagine how bad the performance
 hit for that would be! Forget the filename for the executable, everything
 in memory for Firefox is eligible to be paged out to the disk. Just like
 Linux's `mlock()`, Windows' `VirtualLock()` imposes a limit on how many
 pages you are allowed to lock per process. If Windows is anything at all
 like Linux in how it handles locked, non-paged memory (which I believe), I
 would have closed this ticket too.

 The real solution for Windows for the stated threat model is to run this
 in cmd.exe, running as Administrator, in order to encrypt the paging file
 with a key stored in memory:

 `fsutil behavior set EncryptPagingFile 1`

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