Re: [tor-bugs] #19459 [Applications/Tor Browser]: Write (C++) patch for window resizing parts

[Tor Bug Tracker & Wiki]

#19459: Write (C++) patch for window resizing parts
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton-conversion,|  Actual Points:
  TorBrowserTeam201608   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-
Changes (by arthuredelstein):

 * status:  assigned => needs_review


Comment:

 Here's my current patch: https://github.com/arthuredelstein/tor-
 browser/19459

 It's in JavaScript, rather than C++, mainly because the window-sizing
 startup code in Firefox is already in JavaScript.

 I'm not entirely happy with the patch, because it uses a MutationObserver
 to alter the new window's dimensions after the dimensions are otherwise
 stabilized, but before the window is made visible. Unfortunately I wasn't
 able to find a more straightforward way to interject the resizing code.
 Perhaps during an uplift we can get advice on how to improve this
 approach.

 Nonetheless, I do think the code is in approximately the right place
 (browser.js) and should be a workable substitute for our torbutton code.

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

Re: [tor-bugs] #19998 [Core Tor/Tor]: Stop allowing 3DES in TLS ciphersuites

[Tor Bug Tracker & Wiki]

#19998: Stop allowing 3DES in TLS ciphersuites
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:  .2
 Reviewer:|Sponsor:
--+
Changes (by yawning):

 * keywords:   => tor-spec


Comment:

 I agree with the suggested fixes.

 This will require a tor-spec update as well since 3DES is listed as
 mandatory in a few locations (primarily in relation to outdated link
 handshakes), and although it is unlikely that someone will implement a tor
 that only supports 3DES, the spec should reflect the code.

 While we are revisiting the allowed cipher suites, should we proscribe the
 RC4 ones?  It's even less likely that any of those will be negotiated, and
 they're just as flawed as 3DES (Probably a separate 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] #20004 [Core Tor/Tor]: prop224: Add a trunnel subdirectory specifically for HS

[Tor Bug Tracker & Wiki]

#20004: prop224: Add a trunnel subdirectory specifically for HS
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #17241   | Points:  1
 Reviewer:   |Sponsor:  SponsorR-must
-+

Comment (by dgoulet):

 Started here. `ESTABLISH_INTRO` trunnel file is done (inspired by patch in
 #19043). Missing `INTRODUCE1` cell and we should be good.

 Branch: `ticket20004_029_01`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20004 [Core Tor/Tor]: prop224: Add a trunnel subdirectory specifically for HS

[Tor Bug Tracker & Wiki]

#20004: prop224: Add a trunnel subdirectory specifically for HS
---+
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:  tor-hs, prop224
Actual Points: |  Parent ID:  #17241
   Points:  1  |   Reviewer:
  Sponsor:  SponsorR-must  |
---+
 We'll be using trunnel for all cells parsing in proposal 224. This ticket
 is to add a subdirectory in `src/trunnel/hs` that will contain one
 .trunnel file per cell and most likely a common file for shared binary
 structure.

 This is the starting point for #17241 so if we can get this upstream as
 soon as possible, it makes thing much more easier to split the work
 between developers and branches instead of carrying a commit that adds
 that directory to the build system.

 The plan is to add two cell definition at first `ESTABLISH_INTRO` and
 `INTRODUCE1` and then add more as we implement them.

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

Re: [tor-bugs] #19733 [Applications/Tor Browser]: GETINFO response parser doesn't handle AF_UNIX entries.

[Tor Bug Tracker & Wiki]

#19733: GETINFO response parser doesn't handle AF_UNIX entries.
-+-
 Reporter:  yawning  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very Low |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Minor| Resolution:
 Keywords:  tbb-sandbox, tbb-torbutton,  |  Actual Points:
  TorBrowserTeam201608R  |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * status:  needs_revision => needs_review


Comment:

 Here is a new patch:
 
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug19733-02=f1932e73ee5199969f49ce595fb30ec14e76cb52

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

Re: [tor-bugs] #13802 [Core Tor/Tor]: Add instrumentation to tor

[Tor Bug Tracker & Wiki]

#13802: Add instrumentation to tor
--+--
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #13792| Points:  3
 Reviewer:|Sponsor:  SponsorR-can
--+--

Comment (by arma):

 Poor ticket title. Instrumentation of what?

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

Re: [tor-bugs] #17037 [Core Tor/Tor]: Too many introductions makes hidden service unreachable (was: Strange errors. Seems like new type of attack to hidden service.)

[Tor Bug Tracker & Wiki]

#17037: Too many introductions makes hidden service unreachable
--+
 Reporter:  alberto   |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.2-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-hs|  Actual Points:
Parent ID:  #15463| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 (I'm retitling the ticket since I was just showing it to somebody and the
 old title wasn't very helpful.)

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

Re: [tor-bugs] #10703 [TorBrowserButton]: Fallback charset enables fingerprinting of bundle localization

[Tor Bug Tracker & Wiki]

#10703: Fallback charset enables fingerprinting of bundle localization
-+-
 Reporter:  dcf  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  TorBrowserButton |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting, tbb-pref,|  Actual Points:
  MikePerry201402R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by xfix):

 The bug appears to still exist, and can be checked on
 https://hsivonen.com/test/moz/check-charset.htm

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

Re: [tor-bugs] #10703 [TorBrowserButton]: Fallback charset enables fingerprinting of bundle localization

[Tor Bug Tracker & Wiki]

#10703: Fallback charset enables fingerprinting of bundle localization
-+-
 Reporter:  dcf  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  TorBrowserButton |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting, tbb-pref,|  Actual Points:
  MikePerry201402R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by xfix):

 * status:  closed => reopened
 * resolution:  fixed =>
 * 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] #19977 [Core Tor/Tor]: testsuite fails on mips, powerpc, s390x

[Tor Bug Tracker & Wiki]

#19977: testsuite fails on mips, powerpc, s390x
--+
 Reporter:  weasel|  Owner:  dgoulet
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.2-alpha
 Severity:  Major | Resolution:  fixed
 Keywords:  tor-sr, test  |  Actual Points:  0.5
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:  SponsorR-must
--+
Changes (by nickm):

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


Comment:

 Merged 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] #20003 [Core Tor/Tor]: Sandbox causing crash when setting HidServAuth

[Tor Bug Tracker & Wiki]

#20003: Sandbox causing crash when setting HidServAuth
--+--
 Reporter:  segfault  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.6
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 Does this bug also exist in 0.2.8.6 and later?

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

Re: [tor-bugs] #20001 [Core Tor/Tor]: Infer running and valid from presence in consensus

[Tor Bug Tracker & Wiki]

#20001: Infer running and valid from presence in consensus
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  prop272   |  Actual Points:  .1
Parent ID:| Points:  .2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * keywords:  needs-proposal => prop272


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

Re: [tor-bugs] #20002 [Core Tor/Tor]: Never include non-Valid nodes in consensus.

[Tor Bug Tracker & Wiki]

#20002: Never include non-Valid nodes in consensus.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  prop272   |  Actual Points:  .1
Parent ID:  #20001| Points:  .1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * keywords:  needs-proposal => prop272
 * status:  accepted => needs_review
 * actualpoints:   => .1


Comment:

 See branch "ticket20002" in my public repository.

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

Re: [tor-bugs] #20002 [Core Tor/Tor]: Never include non-Valid nodes in consensus.

[Tor Bug Tracker & Wiki]

#20002: Never include non-Valid nodes in consensus.
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:  accepted
 Priority:  Medium  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  needs-proposal  |  Actual Points:
Parent ID:  #20001  | Points:  .1
 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] #20001 [Core Tor/Tor]: Infer running and valid from presence in consensus

[Tor Bug Tracker & Wiki]

#20001: Infer running and valid from presence in consensus
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:  accepted
 Priority:  Medium  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  needs-proposal  |  Actual Points:
Parent ID:  | Points:  .2
 Reviewer:  |Sponsor:
+
Changes (by nickm):

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


Comment:

 Please have a look at branch "ticket20001" in my public repository.  We
 shouldn't actually merge this till #20002 is also done and deployed, and
 we may want to do it in conjunction with #19958.

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

Re: [tor-bugs] #20001 [Core Tor/Tor]: Infer running and valid from presence in consensus

[Tor Bug Tracker & Wiki]

#20001: Infer running and valid from presence in consensus
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  needs-proposal  |  Actual Points:  .1
Parent ID:  | Points:  .2
 Reviewer:  |Sponsor:
+
Changes (by nickm):

 * status:  accepted => needs_review
 * actualpoints:   => .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

Re: [tor-bugs] #20003 [Core Tor/Tor]: Sandbox causing crash when setting HidServAuth

[Tor Bug Tracker & Wiki]

#20003: Sandbox causing crash when setting HidServAuth
--+--
 Reporter:  segfault  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.6
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by segfault):

 * cc: segfault@… (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

[tor-bugs] #20003 [Core Tor/Tor]: Sandbox causing crash when setting HidServAuth

[Tor Bug Tracker & Wiki]

#20003: Sandbox causing crash when setting HidServAuth
--+--
 Reporter:  segfault  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.6
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 I'm working on Tails Server and I'm currently implementing client
 authentication for it. When I use SETCONF to set the HidServAuth, or set
 it in the torrc and reload Tor, Tor crashes with this error message:

 {{{
  T= 1472233872
 (Sandbox) Caught a bad syscall attempt (syscall chmod)
 /usr/bin/tor(+0x13d8bc)[0xf76a28bc]
 /lib/i386-linux-gnu/libc.so.6(chmod+0x11)[0xf7141361]
 /lib/i386-linux-gnu/libc.so.6(chmod+0x11)[0xf7141361]
 /usr/bin/tor(+0x583bf)[0xf75bd3bf]
 /usr/bin/tor(rend_service_load_all_keys+0x7f)[0xf75bf21f]
 /usr/bin/tor(set_options+0xcc1)[0xf762d1f1]
 /usr/bin/tor(options_trial_assign+0xc4)[0xf762e8c4]
 /usr/bin/tor(+0xe7c83)[0xf764cc83]
 /usr/bin/tor(connection_control_process_inbuf+0x981)[0xf76509f1]
 /usr/bin/tor(+0xcecdd)[0xf7633cdd]
 /usr/bin/tor(+0xd75a8)[0xf763c5a8]
 /usr/bin/tor(+0x2f0a9)[0xf75940a9]
 /usr/lib/i386-linux-
 gnu/libevent-2.0.so.5(event_base_loop+0x73d)[0xf748136d]
 /usr/bin/tor(do_main_loop+0x27d)[0xf7594b0d]
 /usr/bin/tor(tor_main+0x176d)[0xf7598a8d]
 /usr/bin/tor(main+0x35)[0xf7591b35]
 /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xf7092723]
 /usr/bin/tor(+0x2cb94)[0xf7591b94]
 }}}

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

Re: [tor-bugs] #19958 [Core Tor/Tor]: Implement proposal 264 (protocol versioning)

[Tor Bug Tracker & Wiki]

#19958: Implement proposal 264 (protocol versioning)
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201608  |  Actual Points:  2
Parent ID:  #15055 | Points:  2
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * status:  accepted => needs_review
 * type:  defect => enhancement
 * actualpoints:   => 2


Comment:

 See branch "protover" in my public repository.  I have also updated
 proposal 264, and created a new fun proposal 272.

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

Re: [tor-bugs] #20002 [Core Tor/Tor]: Never include non-Valid nodes in consensus.

[Tor Bug Tracker & Wiki]

#20002: Never include non-Valid nodes in consensus.
+
 Reporter:  nickm   |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  needs-proposal  |  Actual Points:
Parent ID:  #20001  | Points:  .1
 Reviewer:  |Sponsor:
+

Comment (by nickm):

 This is part of proposal 272.

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

Re: [tor-bugs] #20001 [Core Tor/Tor]: Infer running and valid from presence in consensus

[Tor Bug Tracker & Wiki]

#20001: Infer running and valid from presence in consensus
+
 Reporter:  nickm   |  Owner:
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  needs-proposal  |  Actual Points:
Parent ID:  | Points:  .2
 Reviewer:  |Sponsor:
+

Comment (by nickm):

 This is part of proposal 272.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20002 [Core Tor/Tor]: Never include non-Valid nodes in consensus.

[Tor Bug Tracker & Wiki]

#20002: Never include non-Valid nodes in consensus.
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  needs-proposal
Actual Points:|  Parent ID:  #20001
   Points:  .1|   Reviewer:
  Sponsor:|
--+
 Right now, we don't include non-Running nodes.  Let's make it so we never
 include non-Valid nodes either.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20001 [Core Tor/Tor]: Infer running and valid from presence in consensus

[Tor Bug Tracker & Wiki]

#20001: Infer running and valid from presence in consensus
--+
 Reporter:  nickm |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  needs-proposal
Actual Points:|  Parent ID:
   Points:  .2|   Reviewer:
  Sponsor:|
--+
 We no longer include in the consensus any non-running nodes.

 We are no longer _supposed_ to include in the consensus any non-Valid
 nodes.

 Let us update Tor to infer these flags as true from their presence in the
 consensus.  This could work with prop#266 as another means to kill off
 obsolete clients.

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

Re: [tor-bugs] #19999 [Core Tor/Tor]: Maybe test-cases should complete without BUG warnings?

[Tor Bug Tracker & Wiki]

#1: Maybe test-cases should complete without BUG warnings?
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  testing   |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 We could at least enforce that no BUG() or tor_assert_nonfatal()
 violations happen during unit tests.

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

Re: [tor-bugs] #20000 [Core Tor/Tor]: Improve our release process: we need fewer surprises.

[Tor Bug Tracker & Wiki]

#2: Improve our release process: we need fewer surprises.
--+
 Reporter:  nickm |  Owner:
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Description changed by nickm:

Old description:



New description:

 Apologies for submitting this with no text: I wanted to grab ticket #2
 while it was available.

 This ticket will be about ways to improve our release process.  My current
 major complaints about the last series have been:

   * 0.2.9 began too large, and took too long to get clarity on must vs
 should vs could.
   * 0.2.9 had us delay our freeze date by 1.5 months. Should we have seen
 that coming earlier?
   * During the 0.2.9 series, we managed to "forget about" too many items
 and have them "appear" on our radar with less flexibility than we'd like.
   * 0.2.8 took far too long between freeze and stability. Why?
   * 0.2.8 has had a nonzero number of post-release regressions
   * 0.2.7.7 never shipped, and probably shouldn't ship as it stands.
   * 0.2.7 is in a zombie state right now.
   * 0.2.7 shipped with a nonworking ed25519 voting algorithm.
   * Versions earlier than 0.2.7 should really be starting to decommision.
 Why are they still around? What can we do to get more uptake?

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20000 [Core Tor/Tor]: Improve our release process: we need fewer surprises.

[Tor Bug Tracker & Wiki]

#2: Improve our release process: we need fewer surprises.
--+
 Reporter:  nickm |  Owner:
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+


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

[tor-bugs] #19999 [Core Tor/Tor]: Maybe test-cases should complete without BUG warnings?

[Tor Bug Tracker & Wiki]

#1: Maybe test-cases should complete without BUG warnings?
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  testing
Actual Points:|  Parent ID:
   Points:  2 |   Reviewer:
  Sponsor:|
--+
 If you run the unit tests with the --warn option, you fill find a lot of
 warnings.  We deliberately test warning-paths, so that's not too bad...


 ... but you'll also see a lot of "Bug" warnings, and that's not so great.
 Some of them even cause stack traces.

 I think we should go over these before 0.2.9 finishes, too make sure they
 aren't causing actual bugs.

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

Re: [tor-bugs] #17241 [Core Tor/Tor]: prop224: Implement relay side support

[Tor Bug Tracker & Wiki]

#17241: prop224: Implement relay side support
-+
 Reporter:  dgoulet  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  High |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #12424   | Points:  parent
 Reviewer:  asn, dgoulet |Sponsor:  SponsorR-must
-+
Changes (by dgoulet):

 * keywords:  tor-hs, 030-proposed => tor-hs, prop224
 * points:   => parent
 * milestone:  Tor: 0.2.??? => Tor: 0.3.0.x-final


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

Re: [tor-bugs] #19733 [Applications/Tor Browser]: GETINFO response parser doesn't handle AF_UNIX entries.

[Tor Bug Tracker & Wiki]

#19733: GETINFO response parser doesn't handle AF_UNIX entries.
-+-
 Reporter:  yawning  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very Low |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Minor| Resolution:
 Keywords:  tbb-sandbox, tbb-torbutton,  |  Actual Points:
  TorBrowserTeam201608R  |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * status:  needs_review => needs_revision


Comment:

 Mozilla changed their implementation to use file: URLs instead of simple
 paths (see https://bugzilla.mozilla.org/show_bug.cgi?id=1211567#c22). We
 will revise this patch accordingly.

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

Re: [tor-bugs] #17238 [Core Tor/Tor]: prop224: Implement HSDir support

[Tor Bug Tracker & Wiki]

#17238: prop224: Implement HSDir support
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, TorCoreTeam201608,  |  Actual Points:  6+
  review-group-7, actualreviewpoints=2   |
Parent ID:  #12424   | Points:  parent
 Reviewer:  asn  |Sponsor:
 |  SponsorR-must
-+-
Changes (by dgoulet):

 * status:  needs_information => merge_ready
 * actualpoints:   => 6+


Comment:

 Ok! We think (asn and I) this is ready for the next stage, the nickm
 stage! :)

 https://gitlab.com/dgoulet/tor/merge_requests/10

 Branch: `ticket17238_029_02`

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

Re: [tor-bugs] #19977 [Core Tor/Tor]: testsuite fails on mips, powerpc, s390x

[Tor Bug Tracker & Wiki]

#19977: testsuite fails on mips, powerpc, s390x
--+
 Reporter:  weasel|  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.2-alpha
 Severity:  Major | Resolution:
 Keywords:  tor-sr, test  |  Actual Points:  0.5
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:  SponsorR-must
--+
Changes (by dgoulet):

 * status:  accepted => needs_review
 * actualpoints:   => 0.5


Comment:

 Fix in branch `bug19977_029_01`

 I've tested the above on s390x arch. thanks to weasel and Debian 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] #19998 [Core Tor/Tor]: Stop allowing 3DES in TLS ciphersuites

[Tor Bug Tracker & Wiki]

#19998: Stop allowing 3DES in TLS ciphersuites
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  .2|   Reviewer:
  Sponsor:|
--+
 Thanks to the SWEET32 attack, 3des is getting lots of attention.

 Right now, Tor is willing in principle to negotiate a 3DES TLS connection.

 But the good news is (I think) that two non-obsolete Tor instances will
 never actually do so. Here is my reasoning:
* Our source code has always preferred AES to 3DES. So the only way to
 get 3DES would be if one party didn't support AES.
* OpenSSL began supporting AES in version 0.9.7.
* Tor has required OpenSSL 0.9.7 or later since 7da93b80ca7a6ba , which
 was in 0.2.0.10-alpha.

 So this cipher shouldn't get negotiated, unless you're doing something
 very very weird.

 I suggest that the best fix is to stop servers from ever choosing it.

 I suggest that as an additional fix, clients should reject a connection to
 any server that  _does_ choose 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] #17238 [Core Tor/Tor]: prop224: Implement HSDir support

[Tor Bug Tracker & Wiki]

#17238: prop224: Implement HSDir support
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, TorCoreTeam201608,  |  Actual Points:
  review-group-7, actualreviewpoints=2   |
Parent ID:  #12424   | Points:  parent
 Reviewer:  asn  |Sponsor:
 |  SponsorR-must
-+-
Changes (by dgoulet):

 * status:  needs_revision => needs_information


Comment:

 re consensus param: Yes I did fail there. I just pushed a new branch with
 the top commit fixed. It should be a bit better now :).

 re stats: Agree, we could also put some researchers in the loop! So I say
 let's postpone until dev meeting and anyway even if this gets in 029, the
 feature won't be enabled because of the consensus param.

 See branch: `ticket17238_029_02`

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

Re: [tor-bugs] #19608 [Core Tor/Tor]: IPv6-only clients can't fetch microdescriptors on 0.2.8.5-rc

[Tor Bug Tracker & Wiki]

#19608: IPv6-only clients can't fetch microdescriptors on 0.2.8.5-rc
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  reopened
 Priority:  High |  Milestone:  Tor:
 |  0.2.8.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.2-alpha
 Severity:  Major| Resolution:
 Keywords:  ipv6, microdesc, fallbacks,  |  Actual Points:  0.5
  regression |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * priority:  Medium => High


Comment:

 I can confirm.

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

Re: [tor-bugs] #18640 [Core Tor/Tor]: Use smarter algorithms to handle socket exhaustion

[Tor Bug Tracker & Wiki]

#18640: Use smarter algorithms to handle socket exhaustion
-+-
 Reporter:  nickm|  Owner:  andrea
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dos, TorCoreTeam201606, review-  |  implemented
  group-5, review-group-7|  Actual Points:  4
Parent ID:  #17293   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  SponsorU-can
-+-
Changes (by nickm):

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


Comment:

 Merged.

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

Re: [tor-bugs] #19163 [Core Tor/Tor]: Make sure clients almost always use ntor

[Tor Bug Tracker & Wiki]

#19163: Make sure clients almost always use ntor
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rsos, tor-hs, TorCoreTeam201608, |  Actual Points:  6
  review-group-7 |
Parent ID:   | Points:  2.0
 Reviewer:  nickm|Sponsor:
-+-

Comment (by nickm):

 I think we should consider _that_ ntor-upgrade a separate bug, and open
 another ticket for 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] #16106 [Core Tor/Tor]: Sandbox causes crash when creating a hidden service through the control port

[Tor Bug Tracker & Wiki]

#16106: Sandbox causes crash when creating a hidden service through the control
port
--+---
 Reporter:  micahlee  |  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.5.12
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  small/medium
 Reviewer:|Sponsor:
--+---
Changes (by nickm):

 * severity:  Blocker => 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] #16106 [Core Tor/Tor]: Sandbox causes crash when creating a hidden service through the control port

[Tor Bug Tracker & Wiki]

#16106: Sandbox causes crash when creating a hidden service through the control
port
--+---
 Reporter:  micahlee  |  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.5.12
 Severity:  Blocker   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  small/medium
 Reviewer:|Sponsor:
--+---
Changes (by segfault):

 * cc: segfault@… (added)
 * severity:   => Blocker


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19997 [Obfuscation/BridgeDB]: BridgeDB's get-tor-exits script doesn't account for IPv6

[Tor Bug Tracker & Wiki]

#19997: BridgeDB's get-tor-exits script doesn't account for IPv6
--+
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Major |   Keywords:  bridge-enumeration
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 As Arlo pointed out [https://lists.torproject.org/pipermail/tor-
 dev/2016-August/011318.html on the tor-dev mailing list], the `exit-
 addresses` script running on check.torproject.org doesn't include IPv6
 exit addresses, making anything that relies upon the list unreliable.
 BridgeDB's `scripts/get-tor-exits` downloads the output of `exit-
 addresses`, and uses it to treat clients using Tor to request bridges as
 coming from the same address. Not taking IPv6 addresses into account will
 allow an adversary to use IPv6-capable tor exits to get additional bridges
 during a time period.

 Some new script should be written to generate a list of IPv6 (optionally
 also IPv4 addresses, so that everything is in one document) exit addresses
 to fix this issue.

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

Re: [tor-bugs] #19996 [HTTPS Everywhere]: extensions.torbutton.https_proxy and similar preferences are gone

[Tor Bug Tracker & Wiki]

#19996: extensions.torbutton.https_proxy and similar preferences are gone
--+--
 Reporter:  gk|  Owner:  legind
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  HTTPS Everywhere  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: legind (removed)
 * owner:   => legind
 * 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] #19996 [HTTPS Everywhere]: extensions.torbutton.https_proxy and similar preferences are gone

[Tor Bug Tracker & Wiki]

#19996: extensions.torbutton.https_proxy and similar preferences are gone
--+-
 Reporter:  gk|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  HTTPS Everywhere  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 After #15852 landed on master (commit
 1b41636c9351b46bbcb2094a65c65a4407b60a37)
 `extensions.torbutton.https_proxy` and friends are no longer. I am getting
 now:
 {{{
 NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000
 (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getCharPref]
 }}}
 while the SSL Observatory code is trying to access
 `extensions.torbutton.https_proxy` etc.

 This part needs to get adapted accordingly.

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

Re: [tor-bugs] #18589 [Applications/Tor Browser]: Tor browser writes SiteSecurityServiceState.txt with usage history

[Tor Bug Tracker & Wiki]

#18589: Tor browser writes SiteSecurityServiceState.txt with usage history
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-disk-leak |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:  tbb-disk-leak, tbb-newnym => tbb-disk-leak


Comment:

 The `NEWNYM` issue is dealt with in #19995.

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

Re: [tor-bugs] #19995 [Applications/Tor Browser]: New Identity does not clear HSTS state anymore

[Tor Bug Tracker & Wiki]

#19995: New Identity does not clear HSTS state anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-newnym, tbb-torbutton,   |  Actual Points:
  GeorgKoppen201608, TorBrowserTeam201608R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  new => needs_review
 * cc: arthuredelsteint (removed)
 * cc: arthuredelstein (added)
 * keywords:  tbb-newnym, tbb-torbutton => tbb-newnym, tbb-torbutton,
 GeorgKoppen201608, TorBrowserTeam201608R


Comment:

 While working on the design document I stumbled over #18589 again and
 after looking at it a bit at least the `NEWNYM` issue seemed trivially to
 fix. A patch is in my bug_19995_v2
 (https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_19995_v2).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19995 [Applications/Tor Browser]: New Identity does not clear HSTS state anymore

[Tor Bug Tracker & Wiki]

#19995: New Identity does not clear HSTS state anymore
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-newnym, tbb-
 Severity:  Normal   |  torbutton
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 A while back Mozilla changed the way site security preferences are
 handled. The permission manager is not responsible for them anymore. This
 affects clearing HSTS (and possibly other state) on New Identity: it does
 not get deleted anymore.
 This is a spin-off of #18589

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

Re: [tor-bugs] #1922 [Core Tor/Tor]: torrc.d-style configuration directories

[Tor Bug Tracker & Wiki]

#1922: torrc.d-style configuration directories
---+--
 Reporter:  aa138346   |  Owner:
 Type:  enhancement| Status:  new
 Priority:  High   |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-client, intro  |  Actual Points:
Parent ID: | Points:  medium
 Reviewer: |Sponsor:
---+--
Changes (by segfault):

 * cc: segfault@… (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] #17238 [Core Tor/Tor]: prop224: Implement HSDir support

[Tor Bug Tracker & Wiki]

#17238: prop224: Implement HSDir support
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, TorCoreTeam201608,  |  Actual Points:
  review-group-7, actualreviewpoints=2   |
Parent ID:  #12424   | Points:  parent
 Reviewer:  asn  |Sponsor:
 |  SponsorR-must
-+-

Comment (by asn):

 Regarding HS stats, maybe let's find some time to discuss this during the
 dev meeting, and see what more people think? Specifically, should we add a
 new stats line for next gen onion services, or blend them with the old
 stats?

 The former approach sounds more reasonable, but we should think of
 security issues here (gathering stats on a growing community) and also
 whether the current noise will make the stats useless until there are
 hundreds of next gen onion services.

 A patch to add stats would be pretty small and easy whichever approach we
 follow, so we can also get it through in the next release.

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

Re: [tor-bugs] #17238 [Core Tor/Tor]: prop224: Implement HSDir support

[Tor Bug Tracker & Wiki]

#17238: prop224: Implement HSDir support
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, TorCoreTeam201608,  |  Actual Points:
  review-group-7, actualreviewpoints=2   |
Parent ID:  #12424   | Points:  parent
 Reviewer:  asn  |Sponsor:
 |  SponsorR-must
-+-
Changes (by asn):

 * status:  needs_information => needs_revision


Comment:

 Replying to [comment:17 dgoulet]:
 > I've merged all your things! _minor_ fixes here and there mostly to
 follow some syntax but that's it. I've integrated them in the current
 commit that exists. The `fetch` feature has its own commit as well as the
 unit test for it. Finally, the "make check-spaces happy" is also its own
 commit.
 >
 > On top of all this, I've added a commit for the consensus params
 (discussed in #19899). This is imo ready for a `merge_ready` state that is
 put it in nickm's court.
 >

 Hmm, you mean `af4d413`?

 I don't see a consensus param there. I only see a torrc option being
 introduced.

 I don't think a torrc option is that useful: I'd actually like a real
 consensus param (like `SRVAgreements`). Am I reading this right?

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

Re: [tor-bugs] #19875 [Core Tor/Tor]: shuffle our bridges when we load them from config

[Tor Bug Tracker & Wiki]

#19875: shuffle our bridges when we load them from config
--+--
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by hdevalence):

 This version of the patch uses a config option, `ShuffleBridges`:
 https://github.com/hdevalence/tor/compare/trac/19875

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

Re: [tor-bugs] #19875 [Core Tor/Tor]: shuffle our bridges when we load them from config

[Tor Bug Tracker & Wiki]

#19875: shuffle our bridges when we load them from config
--+--
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by hdevalence):

 Hi.  I got some time to learn how to use Chutney for testing.  I tweaked
 the "bridges" network configuration to have 3 bridges instead of 1, hoping
 to see that (without the patch) the bridge client always selected the
 first one as its guard.  However, this doesn't happen -- the bridge client
 sometimes uses other bridges than the first one.

 entrynodes.c says:
 {{{
 /** A list of configured bridges. Whenever we actually get a descriptor
  * for one, we add it as an entry guard.  Note that the order of bridges
  * in this list does not necessarily correspond to the order of bridges
  * in the torrc. */
 static smartlist_t *bridge_list = NULL;
 }}}
 which is different from the behaviour described at the top of the ticket.
 So, if the order already does not correspond to the order in the torrc,
 I'm not sure how to test that it's shuffled.

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

Re: [tor-bugs] #19985 [Core Tor/Tor]: pathbias_mark_use_success

[Tor Bug Tracker & Wiki]

#19985: pathbias_mark_use_success
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

 * version:   => Tor: 0.2.9.1-alpha
 * component:  - Select a component => Core Tor/Tor


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

Re: [tor-bugs] #19986 [Core Tor/Tor]: pathbias_count_use_attempt

[Tor Bug Tracker & Wiki]

#19986: pathbias_count_use_attempt
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

 * version:   => Tor: 0.2.9.1-alpha
 * component:  - Select a component => Core Tor/Tor


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

Re: [tor-bugs] #2903 [Applications/Torbutton]: Loading a startup page is not working properly

[Tor Bug Tracker & Wiki]

#2903: Loading a startup page is not working properly
+---
 Reporter:  gk  |  Owner:  mikeperry
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Torbutton  |Version:
 Severity:  Normal  | Resolution:  wontfix
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by gk):

 * status:  new => closed
 * cc: g.koppen@… (removed)
 * cc: gk (added)
 * resolution:   => wontfix
 * severity:   => Normal


Comment:

 Toggle relict which is at least a won't fix.

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

Re: [tor-bugs] #4545 [Applications/Tor Browser]: torbutton_set_timezone() does not work (properly)

[Tor Bug Tracker & Wiki]

#4545: torbutton_set_timezone() does not work (properly)
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  tbb-torbutton, tbb-fingerprinting-   |  Actual Points:
  time   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  assigned => closed
 * cc: g.koppen@… (removed)
 * cc: gk (added)
 * resolution:   => wontfix


Comment:

 This is obsolete now that the code in question is gone.

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

Re: [tor-bugs] #15852 [Applications/Tor Browser]: Remove/synchronize Torbutton SOCKS pref logic

[Tor Bug Tracker & Wiki]

#15852: Remove/synchronize Torbutton SOCKS pref logic
-+-
 Reporter:  mikeperry|  Owner:  brade
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-4.5-regression, tbb-torbutton-   |  Actual Points:
  conversion, TorBrowserTeam201608R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-
Changes (by gk):

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


Comment:

 Thanks! This is commit 1b41636c9351b46bbcb2094a65c65a4407b60a37 on
 torbutton master now.

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

[tor-bugs] #19994 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Forwards URLs with dedicated port number which causes breakage

[Tor Bug Tracker & Wiki]

#19994: Forwards URLs with dedicated port number which causes breakage
---+--
 Reporter:  hanno  |  Owner:  jsha
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS Everywhere  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 I recently stumbled upon someone linking his pgp key to an url at
 pgp.mit.edu like this one:
 http://pgp.mit.edu:11371/

 Now HTTPS Everywhere has pgp.mit.edu listed as an https url, therefore it
 tries to forward it. However there is no reasonable way to forward such an
 URL, as it has a dedicated port number. HTTPS everywhere tries to forward
 it to this:
 https://pgp.mit.edu:11371/

 This obviously does not work, as it is now trying to connect via TLS on
 the same port that an HTTP server is running.

 In this case it would work to forward to the "normal" https port, aka:
 https://pgp.mit.edu/
 But this is merely a very special situation, because it seems for
 pgp.mit.edu the same service is running on the normal 80/443 http/https
 ports.

 I think the general solution should be to never forward URLs that have a
 specific port set.

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