Re: [tor-bugs] #24252 [Core Tor/Tor]: undefined reference to evdns_shutdown

[Tor Bug Tracker & Wiki]

#24252: undefined reference to evdns_shutdown
+
 Reporter:  maddoctor   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.1.8
 Severity:  Blocker | Resolution:
 Keywords:  evdns_shutdown  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by maddoctor):

 libevent 2.1.8 is installed correctly

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

Re: [tor-bugs] #23966 [Core Tor/Tor]: Refactor node_has_curve25519_onion_key() to use node_get_curve25519_onion_key()

[Tor Bug Tracker & Wiki]

#23966: Refactor node_has_curve25519_onion_key() to use
node_get_curve25519_onion_key()
+
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  easy, refactor  |  Actual Points:
Parent ID:  | Points:  0.2
 Reviewer:  |Sponsor:
+

Comment (by aruna1234):

 I did run the make check command. It is failing at line 1638 that is the
 one with the first if condition that returns NULL. I tried running without
 the if condition, but it's still failing at the same line.

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

Re: [tor-bugs] #24610 [Core Tor/Tor]: assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed

[Tor Bug Tracker & Wiki]

#24610: assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by teor):

 * keywords:   => prop224, tor-hs
 * version:   => Tor: 0.3.2.1-alpha
 * milestone:   => Tor: 0.3.2.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] #24612 [Core Tor/Tor]: Fix pretty printing of configure output for rust checks

[Tor Bug Tracker & Wiki]

#24612: Fix pretty printing of configure output for rust checks
-+
 Reporter:  isis |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-build, autoconf  |  Actual Points:
Parent ID:   | Points:  .1
 Reviewer:   |Sponsor:
-+
Changes (by isis):

 * version:  Tor: 0.3.2.1-alpha => Tor: 0.3.1.3-alpha


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

Re: [tor-bugs] #24612 [Core Tor/Tor]: Fix pretty printing of configure output for rust checks

[Tor Bug Tracker & Wiki]

#24612: Fix pretty printing of configure output for rust checks
-+
 Reporter:  isis |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-build, autoconf  |  Actual Points:
Parent ID:   | Points:  .1
 Reviewer:   |Sponsor:
-+
Changes (by isis):

 * status:  new => needs_review


Comment:

 Fix in my `bug24612`
 [https://gitweb.torproject.org/user/isis/tor.git/log/?h=bug24612 branch].

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

[tor-bugs] #24612 [Core Tor/Tor]: Fix pretty printing of configure output for rust checks

[Tor Bug Tracker & Wiki]

#24612: Fix pretty printing of configure output for rust checks
--+-
 Reporter:  isis  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal|   Keywords:  tor-build, autoconf
Actual Points:|  Parent ID:
   Points:  .1|   Reviewer:
  Sponsor:|
--+-
 Right now we print:

 {{{
 […]
 checking for cargo... cargo
 checking rust crate dependencies... checking rust version... checking for
 library containing socket... none required
 […]
 }}}

 I think we're supposed to use `AC_MSG_RESULT` to print "yes" if the rust
 crate dependency checks go okay. After the "checking rust version" we
 should probably also print something indicating that the version was
 acceptible (I'd personally go for printing the version string, since it
 doesn't hurt to have that in the build logs).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24611 [Core Tor/Chutney]: Add a chutney network that does reachability tests

[Tor Bug Tracker & Wiki]

#24611: Add a chutney network that does reachability tests
-+-
 Reporter:  teor |  Owner:  (none)
 Type:   | Status:  new
  enhancement|
 Priority:  Medium   |  Milestone:
Component:  Core |Version:
  Tor/Chutney|   Keywords:  tor-relay address-detection
 Severity:  Normal   |  reachability
Actual Points:   |  Parent ID:  #17782
   Points:  1|   Reviewer:
  Sponsor:   |
  SponsorV-can   |
-+-
 Chutney sets `AssumeReachability 1` in all its networks.

 We should make a network which doesn't set AssumeReachability, so we can
 test relay reachability changes.

 We might even want to add the network to `make test-network-all` if it's
 fast enough, or add a separate make target if it's not.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24610 [Core Tor/Tor]: assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed

[Tor Bug Tracker & Wiki]

#24610: assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 {{{
 Mmm dd hh:01:30.000 [notice] Your system clock just jumped 2000 seconds
 forward; assuming established circuits no longer work.
 Mmm dd hh:02:00.000 [notice] Tor has successfully opened a circuit. Looks
 like client functionality is working.
 Mmm dd hh:02:00.000 [notice] Tor has successfully opened a circuit. Looks
 like client functionality is working.
 Mmm dd hh:03:07.000 [warn] tor_bug_occurred_(): Bug:
 src/or/hs_client.c:267: retry_all_socks_conn_waiting_for_desc: Non-fatal
 assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed. (on Tor
 0.3.2.6-alpha 87012d076ef58bb9)
 Mmm dd hh:03:07.000 [warn] Bug: Non-fatal assertion !(status ==
 HS_CLIENT_FETCH_HAVE_DESC) failed in retry_all_socks_conn_waiting_for_desc
 at src/or/hs_client.c:267. Stack trace: (on Tor 0.3.2.6-alpha
 87012d076ef58bb9)
 Mmm dd hh:03:07.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x52)
 [0x3d56c44a32] (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Mmm dd hh:03:07.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xc5)
 [0x3d56c61835] (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Mmm dd hh:03:07.000 [warn] Bug:
 /usr/bin/tor(hs_client_dir_info_changed+0x116) [0x3d56c23fc6] (on Tor
 0.3.2.6-alpha 87012d076ef58bb9)
 Mmm dd hh:03:07.000 [warn] Bug:
 /usr/bin/tor(networkstatus_set_current_consensus+0x3c2) [0x3d56b15f02] (on
 Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Mmm dd hh:03:07.000 [warn] Bug:
 /usr/bin/tor(connection_dir_reached_eof+0x14db) [0x3d56bf23fb] (on Tor
 0.3.2.6-alpha 87012d076ef58bb9)
 Mmm dd hh:03:07.000 [warn] Bug: /usr/bin/tor(+0x10ff39) [0x3d56bc8f39]
 (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Mmm dd hh:03:07.000 [warn] Bug: /usr/bin/tor(+0x5075d) [0x3d56b0975d]
 (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Mmm dd hh:03:07.000 [warn] Bug: /usr/lib64/libevent-2.1.so.6(+0x229ed)
 [0x3bd918df9ed] (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Mmm dd hh:03:07.000 [warn] Bug:
 /usr/lib64/libevent-2.1.so.6(event_base_loop+0x4f7) [0x3bd918e07f7] (on
 Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Mmm dd hh:03:07.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x29d)
 [0x3d56b0a76d] (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Mmm dd hh:03:07.000 [warn] Bug: /usr/bin/tor(tor_main+0xe2d)
 [0x3d56b0d62d] (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Mmm dd hh:03:07.000 [warn] Bug: /usr/bin/tor(main+0x28) [0x3d56b05ad8]
 (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Mmm dd hh:03:07.000 [warn] Bug:
 /lib64/libc.so.6(__libc_start_main+0xf6) [0x3bd8ff35f66] (on Tor
 0.3.2.6-alpha 87012d076ef58bb9)
 Mmm dd hh:03:07.000 [warn] Bug: /usr/bin/tor(_start+0x2a)
 [0x3d56b05b2a] (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Mmm dd hh:03:40.000 [notice] Tried for 120 seconds to get a connection to
 [scrubbed]:port. Giving up. (waiting for rendezvous desc)
 }}}


 Don't know if suspend+resume is necessary to trigger the 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] #24424 [Core Tor/Tor]: fails to build with libseccomp-dev installed on arm64

[Tor Bug Tracker & Wiki]

#24424: fails to build with libseccomp-dev installed on arm64
-+-
 Reporter:  weasel   |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:  fixed
 Keywords:  029-backport, 030-backport,  |  Actual Points:
  031-backport, review-group-27  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Taking this in 0.3.2, but not backporting, since it isn't sufficient to
 actually have the sandbox.c code ''work'' on arm yet.  I think when it
 does work, we should consider it a "new feature" rather than a bug fix,
 since it didn't work before.

 15b41fa6ae6a1356d5453242ccb7d7d301dd5e67 is the patch as applied.

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

Re: [tor-bugs] #23524 [Core Tor/Tor]: Avoid crashing when we ask for running bridges, but UseBridges is 0

[Tor Bug Tracker & Wiki]

#23524: Avoid crashing when we ask for running bridges, but UseBridges is 0
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  dos-resistance, 030-backport,|  Actual Points:  0.1
  031-backport   |
Parent ID:  #24392   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  dos-resistance, review-group-26, review-group-27 => dos-
 resistance, 030-backport, 031-backport
 * status:  merge_ready => needs_revision
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.0.x-final


Comment:

 This was fixed in #24392 in master and 0.3.2.
 We might also need to backport this to 0.3.0 and 0.3.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] #24486 [Core Tor/Tor]: Mark all bridges as up on application activity

[Tor Bug Tracker & Wiki]

#24486: Mark all bridges as up on application activity
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:  not a
 Keywords:  regression, tor-bridge-client,   |  bug
  s8-errors  |  Actual Points:
Parent ID:  #24367   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

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


Comment:

 We are now handling this case better, and the code has been merged. It
 turns out it was a redundant condition, so this ticket can close.

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

Re: [tor-bugs] #14952 [Applications/Tor Browser]: Audit HTTP/2 and SPDY if needed

[Tor Bug Tracker & Wiki]

#14952: Audit HTTP/2 and SPDY if needed
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, tbb-usability-  |  Actual Points:
  website, tbb-performance, ff59-esr |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Patrick McManus suggested we check if origin frames are properly isolated.
 Firefox has a pref to disable them if needed.

 https://tools.ietf.org/html/draft-ietf-httpbis-origin-frame-04

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

Re: [tor-bugs] #24392 [Core Tor/Tor]: Ignore cached bridge descriptors until we check if they are running

[Tor Bug Tracker & Wiki]

#24392: Ignore cached bridge descriptors until we check if they are running
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  030-backport, 031-backport,  |  Actual Points:  0.5
  regression, tor-bridge-client, s8-errors,  |
  review-group-27|
Parent ID:  #24367   | Points:  0.3
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.0.x-final


Comment:

 nickm squashed and merged to 0.3.2 and master.

 Leaving this open for a potential backport to 0.3.0 and 0.3.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] #24011 [Core Tor/Tor]: Attempt to open a stream on first hop of circuit

[Tor Bug Tracker & Wiki]

#24011: Attempt to open a stream on first hop of circuit
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-circuit   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Just saw it on master - it's a race condition that seems to happen under
 heavy CPU load:
 {{{
 PASS: bridges+ipv6-min
 Detail: chutney/tools/warnings.sh
 /Users/dev/tor/../chutney/tools/../net/nodes.1513124118
 Warning: Attempt by 127.0.0.1:51534 to open a stream on first hop of
 circuit. Closing. Number: 1
 Warning: circuit_receive_relay_cell (backward) failed. Closing. Number: 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] #24609 [Core Tor/Tor]: consdiff implementation in Rust

[Tor Bug Tracker & Wiki]

#24609: consdiff implementation in Rust
--+
 Reporter:  Sebastian |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * keywords:   => rust


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

Re: [tor-bugs] #24608 [Core Tor/Tor]: Update our Cargo.lock file to remove the deprecated and removed [root] section

[Tor Bug Tracker & Wiki]

#24608: Update our Cargo.lock file to remove the deprecated and removed [root]
section
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.6-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, cargo, rust-pilot, tor-ci  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by Sebastian):

 One of the original goals was to build with 1.14 (because that's available
 in Debian). Did we lose that along the way? Maybe we can provide both
 Cargo files and switch them out depending on the toolchain?

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

Re: [tor-bugs] #24609 [Core Tor/Tor]: consdiff implementation in Rust

[Tor Bug Tracker & Wiki]

#24609: consdiff implementation in Rust
--+
 Reporter:  Sebastian |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 if we can get this into 0.3.3, that'd be grand.  if not, 034 is a good
 target.

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

Re: [tor-bugs] #24608 [Core Tor/Tor]: Update our Cargo.lock file to remove the deprecated and removed [root] section

[Tor Bug Tracker & Wiki]

#24608: Update our Cargo.lock file to remove the deprecated and removed [root]
section
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.6-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, cargo, rust-pilot, tor-ci  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by isis):

 Replying to [comment:1 nickm]:
 > fwiw, I am generally not backporting rust stuff, on the theory that
 anybody who wants rust experience should really be sticking with the
 latest and greatest.
 >
 > (Edited to add: That is to say, I'm not treating "rust won't build" as a
 must-fix bug in anything older than 0.3.2.)

 Understood. This means that, in order to build the 0.3.1.x and 0.3.0.x
 series, from now on, you'll need to get ''an older'' nightly rust
 compiler.

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

Re: [tor-bugs] #24608 [Core Tor/Tor]: Update our Cargo.lock file to remove the deprecated and removed [root] section

[Tor Bug Tracker & Wiki]

#24608: Update our Cargo.lock file to remove the deprecated and removed [root]
section
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.6-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, cargo, rust-pilot, tor-ci  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by isis):

 * keywords:   => rust, cargo, rust-pilot, tor-ci


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24609 [Core Tor/Tor]: consdiff implementation in Rust

[Tor Bug Tracker & Wiki]

#24609: consdiff implementation in Rust
--+--
 Reporter:  Sebastian |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 in my public repo in branch rust4, there's a pretty much complete consdiff
 implementation in Rust (only missing some logging and testing from the C
 side iirc). I won't have time to pick it up anytime soon I'm afraid but I
 hope someone finds it useful. Note it looks a bit different compared to
 the C code as we were trying very hard to come up with something without
 any unsafe code and no external dependencies, as this was some of the
 first rust code ever written for tor. It should be straight-forward,
 though.

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

Re: [tor-bugs] #24503 [Core Tor/RPM packaging]: Rust build fails

[Tor Bug Tracker & Wiki]

#24503: Rust build fails
+
 Reporter:  tortux  |  Owner:  hiviah
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/RPM packaging  |Version:  Tor: 0.3.1.9
 Severity:  Normal  | Resolution:  worksforme
 Keywords:  rust packaging  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by isis):

 * cc: isis (added)
 * status:  new => closed
 * resolution:   => worksforme


Comment:

 Hi tortux!

 Thanks for reporting this. From looking at your `build.log`, you'll need
 to also pass the `--enable-cargo-online` flag to `./configure`. If you're
 not able/willing to do that, you'll need to set up cargo offline builds
 using the repo that Sebastian mentioned. Instructions for doing the latter
 can be found
 
[https://gitweb.torproject.org/tor.git/tree/doc/HACKING/GettingStartedRust.md?id=13455c0f1a1#n60
 here]. Please feel free to reopen if either of those solutions fails to
 work for you.

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

Re: [tor-bugs] #24392 [Core Tor/Tor]: Ignore cached bridge descriptors until we check if they are running

[Tor Bug Tracker & Wiki]

#24392: Ignore cached bridge descriptors until we check if they are running
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  030-backport, 031-backport,  |  Actual Points:  0.5
  regression, tor-bridge-client, s8-errors,  |
  review-group-27|
Parent ID:  #24367   | Points:  0.3
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:19 teor]:
 > Replying to [comment:18 nickm]:
 > > Hi! I have some questions, that are not necessarily blockers.
 > >
 > > ...
 >
 > > Second question: In e9cb0cd7c8fe03dbd7e0fef91ab868cb56f280b0, when we
 do
 > > {{{
 > > -  } else if (!options->UseBridges || num_bridges_usable() > 0) {
 > > +  } else {
 > > }}}
 > > can we add a `tor_nonfatal_assert()` there to make sure that the
 second case really and truly only happens when we think it does?
 >
 > Yes, I'll do this in the morning.

 Done and pushed in:
 {{{
 [bug24367_032 42a77862ab] fixup! Simplify some conditionals in
 circuit_get_open_circ_or_launch()
 }}}

 Waiting for it to compile.

 > > Last:
 > > > I am no longer convinced that this bug is restricted to 0.3.2, we
 should consider backporting these changes to 0.3.0 as a precautionary
 measure.
 > >
 > > This is a pretty complex set of changes, and the rebase isn't clean.
 Is there a minimal set of changes that, we could put into a branch based
 on 0.3.0?
 >
 > I'll look into this in the morning.
 > I think we only need the `int first = num_bridges_usable(0) < 1;`
 change.
 >
 > Because `} else if (!options->UseBridges || num_bridges_usable() > 0) {`
 is redundant, and the final change is on code that didn't exist before
 0.3.2.

 I will work on this now.

 > > And final question: how is the testing on this?
 >
 > It passes all of `make test-network-all`, and gk likes it better than
 any of the previous versions when testing bridge switches in Tor Browser.

 Now the testing also has Travis CI™.base

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

Re: [tor-bugs] #24608 [Core Tor/Tor]: Update our Cargo.lock file to remove the deprecated and removed [root] section

[Tor Bug Tracker & Wiki]

#24608: Update our Cargo.lock file to remove the deprecated and removed [root]
section
--+
 Reporter:  isis  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.6-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+

Comment (by nickm):

 fwiw, I am generally not backporting rust stuff, on the theory that
 anybody who wants rust experience should really be sticking with the
 latest and greatest

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24608 [Core Tor/Tor]: Update our Cargo.lock file to remove the deprecated and removed [root] section

[Tor Bug Tracker & Wiki]

#24608: Update our Cargo.lock file to remove the deprecated and removed [root]
section
--+
 Reporter:  isis  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.6-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor8-can  |
--+
 This is [https://travis-ci.org/tlyu/tor/jobs/315398995 causing build
 errors on Travis], which picked up the newest cargo nightly a week ago. As
 pointed out by Sebastian, the error appears to be due to
 [https://github.com/rust-lang/cargo/issues/4563 cargo issue #4563], which
 completely removed the `[root]` section of Cargo.lock files. Often,
 historically, the `[root]` section was used with an arbitrary non-existent
 crate, before cargo workspaces were implemented. However, our Cargo.lock
 file contains not only a `[root]`, but one which points to a non-arbitrary
 crate, `tor_util`. IIUC, we'll just need to remove that section.

 (While we're at it, we may want to update to the newest libc dependency.)

 I think we'll need to backport this to 0.3.0.x, since no newer cargos will
 build something with a `[root]` section.

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

Re: [tor-bugs] #24607 [Obfuscation/BridgeDB]: CAPTCHAs on BridgeDB seem to be getting more difficult

[Tor Bug Tracker & Wiki]

#24607: CAPTCHAs on BridgeDB seem to be getting more difficult
--+--
 Reporter:  alison|  Owner:  isis
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by alison):

 * Attachment "Screenshot from 2017-12-12 17-41-23.png" added.

 looks-like-G-f-but-its-not

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24607 [Obfuscation/BridgeDB]: CAPTCHAs on BridgeDB seem to be getting more difficult

[Tor Bug Tracker & Wiki]

#24607: CAPTCHAs on BridgeDB seem to be getting more difficult
--+--
 Reporter:  alison|  Owner:  isis
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 I just tried to solve 12 CAPTCHAs unsuccessfully before I got to one that
 worked. In each, at least one or two characters was impossible to discern.

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

Re: [tor-bugs] #24607 [Obfuscation/BridgeDB]: CAPTCHAs on BridgeDB seem to be getting more difficult

[Tor Bug Tracker & Wiki]

#24607: CAPTCHAs on BridgeDB seem to be getting more difficult
--+--
 Reporter:  alison|  Owner:  isis
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by alison):

 * Attachment "Screenshot from 2017-12-12 17-41-53.png" added.

 bad-captcha-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] #24367 [Core Tor/Tor]: Changing pluggable transports (during start-up) in Tor Browser is broken

[Tor Bug Tracker & Wiki]

#24367: Changing pluggable transports (during start-up) in Tor Browser is broken
-+-
 Reporter:  gk   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  030-backport, 031-backport,  |  Actual Points:
  regression, tor-bridge-client, s8-errors,  |
  tbb-wants  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by gk):

 We debugged this a bit on IRC today and it turned out that a crucial part
 in this bug seems to be that one of the `obfs3` and one of the `obfs4`
 bridges share the same ID. So, if one chooses an `obfs3` bridge Tor
 Launcher issues a `SETCONF` command like
 {{{
 [12-12 16:21:14] TorLauncher DBUG: Sending Tor command: SETCONF
 UseBridges=1 Bridge="obfs3 109.105.109.163:38980
 1E05F577A0EC0213F971D81BF4D86A9E4E8229ED" Bridge="obfs3
 109.105.109.163:47779 4C331FA9B3D1D6D8FB0D8FBBF0C259C360D97E6A"
 Bridge="obfs3 83.212.101.3:80 A09D536DD1752D542E1FBB3C9CE4449D51298239"
 Bridge="obfs3 169.229.59.75:46328
 AF9F66B7B04F8FF6F32D455F05135250A16543C9"
 Bridge="obfs3 169.229.59.74:31493
 AF9F66B7B04F8FF6F32D455F05135250A16543C9"
 }}}
 . When pressing `Cancel` during the bootstrap process and selecting the
 `obfs4` option instead, Tor Launcher is sending a similar `SETCONF`
 command. However, later on we easily get a bootstrap error like
 {{{
 Dec 12 17:21:35.000 [warn] Problem bootstrapping. Stuck at 85%:
 Finishing handshake with first hop. (DONE; DONE; count 1;
 recommendation warn; host A09D536DD1752D542E1FBB3C9CE4449D51298239 at
 83.212.101.3:80)
 }}}
 The ID A09D536DD1752D542E1FBB3C9CE4449D51298239 is used by one of the
 `obfs4` bridges as well (the IP is the same but the port is different
 (50002 in this case)). It seems things are working much better if I remove
 the `obfs3` bridge with A09D536DD1752D542E1FBB3C9CE4449D51298239 first
 before starting. I did some tests and I never ran into the bootstrap
 error. FWIW it is visible as well if one starts with `obfs4` first and
 switches to `obfs3`, although it seems the error does not pop up outright
 (as in the `obfs3` -> `obfs4` switch) but gets visible once I press
 `Cancel` in Tor Launcher after the bootstrap process is stuck.

 According to Nick the issue seems to be that Tor Browser will have a guard
 entry for the bridge it was using before but it seems the lookup which is
 done by fingerprint _and_ address is not working as expected.

 So, that's the error case in 4) in my comment:description. I am not sure
 about the stalling part yet. My current plan is to open a new ticket once
 all open issues related to that one are fixed/merged and I can still come
 up with a scenario to reproduce a stalled bootstrap process.

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

Re: [tor-bugs] #24398 [Applications/Tor Browser]: Plugin-container exhausts memory leading to thrash and/or crash on Linux

[Tor Bug Tracker & Wiki]

#24398: Plugin-container exhausts memory leading to thrash and/or crash on Linux
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash, TorBrowserTeam201712R  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by mcs):

 r=brade, r=mcs
 We confirmed that the patch avoids the recursion problem. Because the
 devtools code cannot load file URLs such as the userContent.css
 stylesheet, things still do not work correctly... but at least we avoid
 infinite recursion.

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

Re: [tor-bugs] #24423 [Core Tor/Tor]: Fix STACK warnings in Tor

[Tor Bug Tracker & Wiki]

#24423: Fix STACK warnings in Tor
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-27  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+

Comment (by catalyst):

 Hm maybe that should be `if (cert_lifetime <= min_real_lifetime +
 start_granularity || cert_lifetime > now)` because the subtraction for
 `earliest_start_time` could still underflow.  (also fixed the comparison
 operator that I had wrong before)

 Then again you could also start getting mixed signed/unsigned comparison
 warnings so maybe we need to use a signed intermediate.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by asn):

 Replying to [comment:23 tom]:
 > I spoke with Mozilla's crypto engineering team - they're not aware of
 any padlock deprecation, so I think the design guide is a separate thing.

 ACK thanks for asking. That's good. This means we can continue considering
 onions in the URL bar.

 BTW, you guys that are at All Hands this week, would you be able to figure
 out the tradeoffs about onion color on HTTP vs self-signed HTTPS? There is
 a debate in the end of the pad that might help you. All Hands seems like a
 good place to figure this debate out!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24606 [Webpages/Website]: web pages are not fully loaded

[Tor Bug Tracker & Wiki]

#24606: web pages are not fully loaded
--+
 Reporter:  Ahmed94   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Webpages/Website  |Version:  Tor: 0.3.2.6-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Hi!
 As the title said ... some websites are not fully loaded and it's getting
 worse over time .. for example
 Some online games use superrewards wall to either pay money or doing
 either free or paid offers
 in the past, it was loaded well, after some time the surveys tab only
 didn't load but after that, the wall didn't load in the game site although
 it's loaded when I get the wall link from the game website's source
 although the same survey tab didn't load but now after installing a new
 version of windows the whole wall didn't load neither from the game site
 nor the link extracted from the page's source
 the game's website doesn't use https protocol and here is the site that
 the problem happening (a private server btw)
 http://silkroad-europe.com/?pg=index
 I also made some deep tests on different types of websites and it was
 happening in some thumbnail pictures in some video porn sites and these
 were the same elements each visit and each ip (not the same video but for
 example 3rd video in page, search results, etc)and it disappeared after
 installing my new copy of windows
 finally sorry for my long description :(

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

Re: [tor-bugs] #24423 [Core Tor/Tor]: Fix STACK warnings in Tor

[Tor Bug Tracker & Wiki]

#24423: Fix STACK warnings in Tor
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-27  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+

Comment (by catalyst):

 It looks like STACK is complaining about the comparison on line 498 `if
 (earliest_start_time >= now)` being simplified based on the assumption
 that the `earliest_start_time` computation doesn't overflow or underflow,
 and therefore the algebraic equivalences hold (cancelling the `now` from
 the comparison).  The added `tor_assert(cert_lifetime <= INT_MAX)` adds
 some constraints to `cert_lifetime` but apparently that's not enough.
 STACK doesn't seem to know any constraints on `now`, so maybe as far as
 it's concerned, the subtraction could still underflow. (or the additions
 could overflow)

 Perhaps the comparison on line 498 should be `if (cert_lifetime <
 min_real_lifetime + start_granularity)`, with the original
 `earliest_start_time` computation moved into an `else` clause.

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

Re: [tor-bugs] #24554 [Core Tor/Tor]: sched: Have per-scheduler type data in a channel_t

[Tor Bug Tracker & Wiki]

#24554: sched: Have per-scheduler type data in a channel_t
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:  #23993| Points:
 Reviewer:  pastly|Sponsor:
--+
Changes (by pastly):

 * status:  needs_review => needs_revision


Comment:

 Left comments on oniongit.

 - One easy to fix compile issue.
 - Some rambling thoughts about the consequences of ignoring a `chan` with
 invalid `sched_info` in the middle of a scheduling run.

 Marking needs_revision for the compile 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] #24566 [Applications/Tor Browser]: When I open TorBrowser 7.0.11 the popup goes completely white

[Tor Bug Tracker & Wiki]

#24566: When I open TorBrowser 7.0.11 the popup goes completely white
--+---
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:7 gk]:


 > Replying to [comment:6 Dbryrtfbcbhgf]:
 >
 > > Replying to [comment:5 gk]:
 > >
 > >
 > >
 > > > Replying to [comment:4 Dbryrtfbcbhgf]:
 > > >
 > > >
 > > > > The bug also shows up for a second on the security settings dialog
 every time it is open.
 > > > >
 > > > >
 > > >
 > > > Thanks. What about my two questions in comment:1? Is this a new
 thing coming with 7.0.11/7.5a9? Tor Browser is still working as expected?
 > > >
 > > The questions were answered in
 https://trac.torproject.org/projects/tor/ticket/24566?replyto=5#comment:3
 , thanks gk.
 > > This does happen with a clean install of 7.5a9 and 7.0.11, Tor browser
 is functional, but I must click on the white app or move it around to get
 the connect to to button to appear.
 > >
 >
 > Thanks, yes, I saw that it happens with a clean install of 7.0.11 and
 7.5a9 but what about 7.0.10?
 This does effect 7.0.10 and it also effects a clean install of 52.5.2
 (64-bit), sorry I read you 1st comment wrong. I made another video showing
 the the first intro screen stays white and may confuse users.
 Here is the video
 ​https://filenurse.com/download/048ee301b1d2c7c3c164cd8fd5f2df5a.html

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

Re: [tor-bugs] #21969 [Core Tor/Tor]: We're missing descriptors for some of our primary entry guards

[Tor Bug Tracker & Wiki]

#21969: We're missing descriptors for some of our primary entry guards
---+---
 Reporter:  asn|  Owner:  asn
 Type:  defect | Status:
   |  needs_information
 Priority:  Immediate  |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.6
 Severity:  Blocker| Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID: | Points:  1.5
 Reviewer: |Sponsor:  SponsorV
---+---

Comment (by cypherpunks):

 Replying to [comment:57 teor]:
 > But how long is your Tor in that state?
 More than 10 minutes, in which case I just have to restart the browser.

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

Re: [tor-bugs] #24398 [Applications/Tor Browser]: Plugin-container exhausts memory leading to thrash and/or crash on Linux

[Tor Bug Tracker & Wiki]

#24398: Plugin-container exhausts memory leading to thrash and/or crash on Linux
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash, TorBrowserTeam201712R  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by mcs):

 Kathy and I do not always see the memory growth, but when running with
 `--verbose`` we see many lines like the following:
  newChannelForURL@resource://gre/modules/commonjs/toolkit/loader.js ->
 resource://devtools/shared/DevToolsUtils.js:567:12
 and then a few like this:
  console.error: Protocol error (unknownError): too much recursion

 So I think we are reproducing the bug. We did not do anything special; if
 you load a page you should have a plugin-container process (assuming
 multiprocess mode is working).

 We are going to rebuild with the proposed fix in place and see if the
 problem goes away.

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

Re: [tor-bugs] #23104 [Applications/Tor Browser]: CSS line-height reveals the platform Tor Browser is running on

[Tor Bug Tracker & Wiki]

#23104: CSS line-height reveals the platform Tor Browser is running on
-+-
 Reporter:  gk   |  Owner:  igt0
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-os,   |  Actual Points:
  TorBrowserTeam201712R  |
Parent ID:   | Points:
 Reviewer:  gk   |Sponsor:
-+-

Comment (by igt0):

 Replying to [comment:19 mcs]:
 > The new patch looks good to Kathy and me. We did not build and test a
 Windows browser to make sure that #23701 was fixed. Igor or Georg, did you
 do that?

 I tested in a Windows and Linux machines, however I would love to have a
 second person giving a try to make sure I didn't miss anything.

 >
 > Also, we noticed that a Math.ceil() call was removed from the test. I
 assume it is not needed?

 Yep, It was not needed.

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

Re: [tor-bugs] #23016 [Applications/Tor Browser]: "Print to File" does not create the expected file in non-English locales

[Tor Bug Tracker & Wiki]

#23016: "Print to File" does not create the expected file in non-English locales
-+-
 Reporter:  intrigeri|  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  AffectsTails, tbb-7.0-issues, tbb-   |  Actual Points:
  regression, tbb-e10s, TorBrowserTeam201712R|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 r=brade, r=mcs
 Good work on this bug.
 It would be nice to fix the following typos within the commit message:
  s/base off/based off/
  s/prference/preference/
  s/setlocale occur/setlocale occurs/

 R.e. uplifting to Firefox, I wonder if the new replacement for
 nsLocaleService has a similar problem. But I guess your testing shows that
 it does not. Also, we are patching files under xpcom that are still
 present on mozilla-central today so maybe we want to request that those
 parts be uplifted? e.g., the changes in xpcom/build/XPCOMInit.cpp may
 still be needed.

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

[tor-bugs] #24605 [Core Tor/Tor]: Log main loop iteration count as part of the heartbeat messages

[Tor Bug Tracker & Wiki]

#24605: Log main loop iteration count as part of the heartbeat messages
--+
 Reporter:  ahf   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:  s8, s8-perf
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor8  |
--+
 We should log information about the main loop iteration count as part of
 the heartbeat messages to gain a better understanding on why we are waking
 up and to be able to compare our progress with waking up less.

 We should only enable this when the user configures their Tor to log and
 collect this information.

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

Re: [tor-bugs] #24399 [Webpages/Website]: Consistent set of icons for relay flags

[Tor Bug Tracker & Wiki]

#24399: Consistent set of icons for relay flags
--+
 Reporter:  irl   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 This looks like a good set of icons. Thanks!

 Here's how the definitions relate to one another:

 "Reachable IPv6 ORPort" and "Reachable IPv6" are the same concept.
 We're going with the "Reachable IPv6" name.
 (We just had a conversation about this on the metrics list.)

 Also, we might rename "Reachable ORPort" to be "Reachable IPv4".

 And "Running" is a combination of "Reachable IPv4" and "Reachable IPv6".

 I wonder if this helps us find an icon for "OR". I like the current
 "Running" icon. What does it look like if we add "4" or "6" or "IPv4" or
 "IPv6" to the "Running" icon, and use them for the "OR" icons?

 I have some suggestions for consistency:

 Can we make FallbackDir look like V2Dir?
 Can we take the "V2" out of "V2Dir", because it's the most common kind of
 generic directory?

 Can we make "NoEdConsensus", "Unmeasured", and the "Unreachable" series
 look more like a warning, like "BadExit" or "Not Recommended"? Or should
 we make all the bad icons look grey?

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

Re: [tor-bugs] #23104 [Applications/Tor Browser]: CSS line-height reveals the platform Tor Browser is running on

[Tor Bug Tracker & Wiki]

#23104: CSS line-height reveals the platform Tor Browser is running on
-+-
 Reporter:  gk   |  Owner:  igt0
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-os,   |  Actual Points:
  TorBrowserTeam201712R  |
Parent ID:   | Points:
 Reviewer:  gk   |Sponsor:
-+-

Comment (by mcs):

 The new patch looks good to Kathy and me. We did not build and test a
 Windows browser to make sure that #23701 was fixed. Igor or Georg, did you
 do that?

 Also, we noticed that a Math.ceil() call was removed from the test. I
 assume it is not needed?

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

Re: [tor-bugs] #24011 [Core Tor/Tor]: Attempt to open a stream on first hop of circuit

[Tor Bug Tracker & Wiki]

#24011: Attempt to open a stream on first hop of circuit
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-circuit   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 I haven't seen it for a few weeks, either.
 Was it something we broke and then fixed?
 Or is it a race condition that doesn't happen very often?

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

Re: [tor-bugs] #24392 [Core Tor/Tor]: Ignore cached bridge descriptors until we check if they are running

[Tor Bug Tracker & Wiki]

#24392: Ignore cached bridge descriptors until we check if they are running
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  030-backport, 031-backport,  |  Actual Points:  0.5
  regression, tor-bridge-client, s8-errors,  |
  review-group-27|
Parent ID:  #24367   | Points:  0.3
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:18 nickm]:
 > Hi! I have some questions, that are not necessarily blockers.
 >
 > In the new commit bca43d548ad7301fc3698e8ded0a94d43a41858d:
 > {{{
 > -int first = num_bridges_usable() <= 1;
 > +/* Retry directory downloads whenever we get a bridge descriptor:
 > + * - when bootstrapping, and
 > + * - when we aren't sure if any of our bridges are reachable.
 > + * Keep on retrying until we have at least one reachable bridge. */
 > +int first = num_bridges_usable(0) < 1;
 > }}}
 >
 > Do we know why this was `<=` before?  It looks like I introduced the
 code in bca43d548ad7301fc3698e8ded0a94d43a41858d, but I don't understand
 what my original rationale was, so I'm a little uncertain here.  I'll try
 to see if I can puzzle this out.

 I suspect that it was `num_bridges_usable() <= 1` because in the old code
 that meant:
 "keep on trying until we have more than one bridge that is maybe or
 definitely reachable".
 This isn't quite right, because two maybe-reachable bridges can still be
 useless to a client.

 But now `num_bridges_usable(0) < 1` means:
 "keep on trying until we have one bridge that is definitely reachable".
 I think that's what we actually want, and I added the comment for future
 reference.

 > Second question: In e9cb0cd7c8fe03dbd7e0fef91ab868cb56f280b0, when we do
 > {{{
 > -  } else if (!options->UseBridges || num_bridges_usable() > 0) {
 > +  } else {
 > }}}
 > can we add a `tor_nonfatal_assert()` there to make sure that the second
 case really and truly only happens when we think it does?

 Yes, I'll do this in the morning.

 > Last:
 > > I am no longer convinced that this bug is restricted to 0.3.2, we
 should consider backporting these changes to 0.3.0 as a precautionary
 measure.
 >
 > This is a pretty complex set of changes, and the rebase isn't clean.  Is
 there a minimal set of changes that, we could put into a branch based on
 0.3.0?

 I'll look into this in the morning.
 I think we only need the `int first = num_bridges_usable(0) < 1;` change.

 Because `} else if (!options->UseBridges || num_bridges_usable() > 0) {`
 is redundant, and the final change is on code that didn't exist before
 0.3.2.

 > And final question: how is the testing on this?

 It passes all of `make test-network-all`, and gk likes it better than any
 of the previous versions when testing bridge switches in Tor Browser. But
 there's still a bug in #23524 where an old cached bridge descriptor /
 state file entry that is no longer in the torrc still forms part of the
 set of guards.

 I was hoping someone else would have a look at that one, I'm not that
 familiar with the new guard 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] #24399 [Webpages/Website]: Consistent set of icons for relay flags

[Tor Bug Tracker & Wiki]

#24399: Consistent set of icons for relay flags
--+
 Reporter:  irl   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by antonela):

 Hi all!

 Thanks for inviting the UX team to work on this ticket :)

 I've started to work on this set. You can see the progress here:

 https://24399.glitch.me/

 To make it easy extendible, I opted in for looking into FontAwesome if
 some related icon exists and use it. If not, then I created a custom one.

 Icons are tricky. Since Icons are a representation of an idea, each
 concept could take a lot of shapes. Having a consensus about them within
 the Tor community will allow us to make them easily recognizable.

 So, I'd like to encourage people to comment this thread if some icon is
 not what you expected or if any icon could be more precise using another
 kind of representation.

 Again, this is the first approach. I'm sure some of them will change after
 the review.

 Fingerprinting and AS are remaining; I'm working on them.

 Let me know if I missed any required and what do you think :)

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

Re: [tor-bugs] #24011 [Core Tor/Tor]: Attempt to open a stream on first hop of circuit

[Tor Bug Tracker & Wiki]

#24011: Attempt to open a stream on first hop of circuit
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-circuit   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Also, I'm unable to reproduce this warning right now with chutney but I do
 remember seeing it some weeks ago so this must be some race condition...?

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

Re: [tor-bugs] #24011 [Core Tor/Tor]: Attempt to open a stream on first hop of circuit

[Tor Bug Tracker & Wiki]

#24011: Attempt to open a stream on first hop of circuit
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-circuit   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Ok I bet everything that this is why we see this warning now:
 66aff2d8f35217cc802bd46eeeaf49326d7de4b0

 Originally, we were using `is_first_hop` instead of "is client" and here
 is how it was set:

 {{{
   circ->is_first_hop = (created_cell->cell_type == CELL_CREATED_FAST);
 }}}

 Leaving behind the `CREATE` and `CREATE2` that also makes a channel being
 marked as a client. This was modified after we removed
 `AllowSingleHopExits` with commit: d52a1e2faaf

 So now the question is still how did the channel on the OR connection got
 flagged as a client?

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

[tor-bugs] #24604 [Core Tor/Tor]: Decorate IPv6 addresses in connection_t->address to avoid ambiguity

[Tor Bug Tracker & Wiki]

#24604: Decorate IPv6 addresses in connection_t->address to avoid ambiguity
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  ipv6, tor-relay
Actual Points:|  Parent ID:  #24403
   Points:  2 |   Reviewer:
  Sponsor:  SponsorV-can  |
--+
 Currently, connection_t->address can be in one of three formats:
 * hostname: www.example.com
 * IPv4: 1.1.1.1
 * IPv6: 2003::0001

 Tor often uses this address with a port like this:
 * hostname: www.example.com:1234
 * IPv4: 1.1.1.1:1234
 * IPv6: 2003::0001:1234

 The IPv6 case is ambiguous, and we should fix it.

 One way of fixing it is to provide a flag if address is an IPv6 literal,
 and a function to format address and port. (Unfortunately, we can't always
 decorate IPv6 addresses, because that would cause bugs in other code and
 in controllers.)

 Then we would need to go through every instance of `conn->address` and
 find the ones that use a port. This may also require a spec update, like
 #24603.

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

Re: [tor-bugs] #24603 [Core Tor/Tor]: Update control spec to allow decorated IPv6 addresses in reachability events

[Tor Bug Tracker & Wiki]

#24603: Update control spec to allow decorated IPv6 addresses in reachability
events
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, tor-relay, tor-spec  |  Actual Points:
Parent ID:  #24403 | Points:  0.5
 Reviewer: |Sponsor:  SponsorV-can
---+---
Changes (by teor):

 * status:  assigned => needs_revision


Comment:

 See my branch bug24603, which corresponds to the changes in #13112.
 We will need to add more changes to this branch when relays initiate IPv6
 reachability checks in #6939.

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

Re: [tor-bugs] #13112 [Core Tor/Tor]: Some things are probably broken when we advertise multiple ORPorts and only some are reachable

[Tor Bug Tracker & Wiki]

#13112: Some things are probably broken when we advertise multiple ORPorts and 
only
some are reachable
-+-
 Reporter:  andrea   |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay reachability self-testing  |  Actual Points:  0.2
  needs-design ipv6 tor-bridge   |
Parent ID:  #24403   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by teor):

 * status:  assigned => 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] #24392 [Core Tor/Tor]: Ignore cached bridge descriptors until we check if they are running

[Tor Bug Tracker & Wiki]

#24392: Ignore cached bridge descriptors until we check if they are running
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  030-backport, 031-backport,  |  Actual Points:  0.5
  regression, tor-bridge-client, s8-errors,  |
  review-group-27|
Parent ID:  #24367   | Points:  0.3
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Hi! I have some questions, that are not necessarily blockers.

 In the new commit bca43d548ad7301fc3698e8ded0a94d43a41858d:
 {{{
 -int first = num_bridges_usable() <= 1;
 +/* Retry directory downloads whenever we get a bridge descriptor:
 + * - when bootstrapping, and
 + * - when we aren't sure if any of our bridges are reachable.
 + * Keep on retrying until we have at least one reachable bridge. */
 +int first = num_bridges_usable(0) < 1;
 }}}

 Do we know why this was `<=` before?  It looks like I introduced the code
 in bca43d548ad7301fc3698e8ded0a94d43a41858d, but I don't understand what
 my original rationale was, so I'm a little uncertain here.  I'll try to
 see if I can puzzle this out.

 Second question: In e9cb0cd7c8fe03dbd7e0fef91ab868cb56f280b0, when we do
 {{{
 -  } else if (!options->UseBridges || num_bridges_usable() > 0) {
 +  } else {
 }}}
 can we add a `tor_nonfatal_assert()` there to make sure that the second
 case really and truly only happens when we think it does?

 Last:
 > I am no longer convinced that this bug is restricted to 0.3.2, we should
 consider backporting these changes to 0.3.0 as a precautionary measure.

 This is a pretty complex set of changes, and the rebase isn't clean.  Is
 there a minimal set of changes that, we could put into a branch based on
 0.3.0?

 And final question: how is the testing on this?

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

Re: [tor-bugs] #13112 [Core Tor/Tor]: Some things are probably broken when we advertise multiple ORPorts and only some are reachable

[Tor Bug Tracker & Wiki]

#13112: Some things are probably broken when we advertise multiple ORPorts and 
only
some are reachable
-+-
 Reporter:  andrea   |  Owner:  teor
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay reachability self-testing  |  Actual Points:  0.2
  needs-design ipv6 tor-bridge   |
Parent ID:  #24403   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by teor):

 * actualpoints:   => 0.2


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

Re: [tor-bugs] #13112 [Core Tor/Tor]: Some things are probably broken when we advertise multiple ORPorts and only some are reachable

[Tor Bug Tracker & Wiki]

#13112: Some things are probably broken when we advertise multiple ORPorts and 
only
some are reachable
-+-
 Reporter:  andrea   |  Owner:  teor
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay reachability self-testing  |  Actual Points:
  needs-design ipv6 tor-bridge   |
Parent ID:  #24403   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by teor):

 * status:  new => assigned
 * owner:  (none) => teor


Comment:

 Please see my branch bug13112_tree, which is based on #17782 (bug17782).
 I expect this will need revision as we implement relay initiation of IPv6
 ORPort reachability checks.

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

Re: [tor-bugs] #17782 [Core Tor/Tor]: Relays may publish descriptors with incorrect IP address

[Tor Bug Tracker & Wiki]

#17782: Relays may publish descriptors with incorrect IP address
---+---
 Reporter:  fk |  Owner:  teor
 Type:  defect | Status:
   |  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Major  | Resolution:
 Keywords:  intro tor-relay address-detection  |  Actual Points:  0.5
Parent ID:  #24403 | Points:  1
 Reviewer: |Sponsor:  SponsorV-
   |  can
---+---
Changes (by teor):

 * status:  assigned => needs_review


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

[tor-bugs] #24603 [Core Tor/Tor]: Update control spec to allow decorated IPv6 addresses in reachability events

[Tor Bug Tracker & Wiki]

#24603: Update control spec to allow decorated IPv6 addresses in reachability
events
--+---
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  ipv6, tor-relay, tor-spec
Actual Points:|  Parent ID:  #24403
   Points:  0.5   |   Reviewer:
  Sponsor:  SponsorV-can  |
--+---
 When we add IPv6 ORPort reachability checks, we want them to report
 decorated addresses (with brackets) to avoid ambiguity.

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

Re: [tor-bugs] #24603 [Core Tor/Tor]: Update control spec to allow decorated IPv6 addresses in reachability events

[Tor Bug Tracker & Wiki]

#24603: Update control spec to allow decorated IPv6 addresses in reachability
events
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, tor-relay, tor-spec  |  Actual Points:
Parent ID:  #24403 | Points:  0.5
 Reviewer: |Sponsor:  SponsorV-can
---+---
Changes (by teor):

 * owner:  (none) => teor
 * status:  new => assigned


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

Re: [tor-bugs] #17782 [Core Tor/Tor]: Relays may publish descriptors with incorrect IP address

[Tor Bug Tracker & Wiki]

#17782: Relays may publish descriptors with incorrect IP address
---+---
 Reporter:  fk |  Owner:  teor
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Major  | Resolution:
 Keywords:  intro tor-relay address-detection  |  Actual Points:  0.5
Parent ID:  #24403 | Points:  1
 Reviewer: |Sponsor:  SponsorV-
   |  can
---+---
Changes (by teor):

 * owner:  (none) => teor
 * status:  new => assigned
 * actualpoints:   => 0.5


Comment:

 See my branch bug17782 on github, which hasn't had any testing 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] #21847 [Applications/Tor Browser]: Update copy for security slider to be consistent with the mobile experience

[Tor Bug Tracker & Wiki]

#21847: Update copy for security slider to be consistent with the mobile 
experience
-+-
 Reporter:  isabela  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-security-slider,  |  Actual Points:
  TorBrowserTeam201712R, GeorgKoppen201712   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * Attachment "torbutton-1.9.8.3_21847.xpi" 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] #21847 [Applications/Tor Browser]: Update copy for security slider to be consistent with the mobile experience

[Tor Bug Tracker & Wiki]

#21847: Update copy for security slider to be consistent with the mobile 
experience
-+-
 Reporter:  isabela  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-security-slider,  |  Actual Points:
  TorBrowserTeam201712R, GeorgKoppen201712   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  new => needs_review
 * cc: mcs, brade (added)
 * keywords:
 tbb-usability, tbb-security-slider, TorBrowserTeam201712,
 GeorgKoppen201712
 =>
 tbb-usability, tbb-security-slider, TorBrowserTeam201712R,
 GeorgKoppen201712


Comment:

 `bug_21847`
 
(https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_21847=e0a8b16619c691ff44488c9c5b003875f62960ca)
 in my torbutton repo has a patch for review.

 I was tempted to follow the "HTML-ization" of the dialog by adding the
 bullets but I then thought this is still XUL and mixing both might look
 weird in the end given that the remaining UI has basically no HTML
 elements. This I left the bullets out (but the result is still list-like).

 I attached an .xpi which should be working to test this in en-US bundles.

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

Re: [tor-bugs] #24595 [Core Tor/Tor]: hs_service_intro_circ_has_closed: Assertion desc failed

[Tor Bug Tracker & Wiki]

#24595: hs_service_intro_circ_has_closed: Assertion desc failed
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, assert, prop224  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:  asn  |Sponsor:
-+
Changes (by nickm):

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


Comment:

 merging to 0.3.2 and master.

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

Re: [tor-bugs] #24595 [Core Tor/Tor]: hs_service_intro_circ_has_closed: Assertion desc failed

[Tor Bug Tracker & Wiki]

#24595: hs_service_intro_circ_has_closed: Assertion desc failed
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  merge_ready
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, assert, prop224  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:  asn  |Sponsor:
-+
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 `bug24595_032_02` LGTM!

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

Re: [tor-bugs] #23827 [Core Tor/Tor]: Clients/Relays: Use IPv6 Addresses from microdesc consensus

[Tor Bug Tracker & Wiki]

#23827: Clients/Relays: Use IPv6 Addresses from microdesc consensus
---+
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  ipv6, review-group-27  |  Actual Points:  1
Parent ID:  #20916 | Points:  0.5
 Reviewer:  dgoulet|Sponsor:  SponsorV-can
---+
Changes (by nickm):

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


Comment:

 Sounds good to me; code looks good too.  Merging to master!

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

Re: [tor-bugs] #24595 [Core Tor/Tor]: hs_service_intro_circ_has_closed: Assertion desc failed

[Tor Bug Tracker & Wiki]

#24595: hs_service_intro_circ_has_closed: Assertion desc failed
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, assert, prop224  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:  asn  |Sponsor:
-+

Comment (by dgoulet):

 asn changed it and I approve so here is the second version:
 `bug24595_032_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] #23862 [Core Tor/Tor]: Tor only updates guard state after a consensus if it has enough directory info

[Tor Bug Tracker & Wiki]

#23862: Tor only updates guard state after a consensus if it has enough 
directory
info
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-guard, tor-bridge, tor-client,   |  Actual Points:
  030-backport, 031-backport |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorV
-+-
Changes (by nickm):

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


Comment:

 whoops; sorry -- found this independently, and fixed it to make jenkins
 happy.

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

Re: [tor-bugs] #24362 [Core Tor/Tor]: Add logging backend for Android

[Tor Bug Tracker & Wiki]

#24362: Add logging backend for Android
--+
 Reporter:  ahf   |  Owner:  ahf
 Type:  enhancement   | Status:  closed
 Priority:  Low   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Minor | Resolution:  fixed
 Keywords:  s8|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8
--+
Changes (by nickm):

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


Comment:

 all looks reasonable. merging!

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

Re: [tor-bugs] #24558 [Core Tor/Tor]: enable expensive hardening message is wrong with static library builds

[Tor Bug Tracker & Wiki]

#24558: enable expensive hardening message is wrong with static library builds
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Very Low  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:  fixed
 Keywords:  easy, intro   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 lgtm ; 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] #24596 [Core Tor/Tor]: FREE_AND_NULL documentation uses different names for the macro parameter

[Tor Bug Tracker & Wiki]

#24596: FREE_AND_NULL documentation uses different names for the macro parameter
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:  0.1
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

[Tor Bug Tracker & Wiki]

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

Comment (by tom):

 I spoke with Mozilla's crypto engineering team - they're not aware of any
 padlock deprecation, so I think the design guide is a separate thing.

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

Re: [tor-bugs] #24595 [Core Tor/Tor]: hs_service_intro_circ_has_closed: Assertion desc failed

[Tor Bug Tracker & Wiki]

#24595: hs_service_intro_circ_has_closed: Assertion desc failed
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, assert, prop224  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:  asn  |Sponsor:
-+
Changes (by dgoulet):

 * status:  new => needs_review


Comment:

 Branch: `bug24595_032_01`

 Fortunately for us, this bug was never released so no changes file.
 Introduced in e80893e51b0c0320838cbed8c46fd5b0fe608bef

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

Re: [tor-bugs] #23862 [Core Tor/Tor]: Tor only updates guard state after a consensus if it has enough directory info

[Tor Bug Tracker & Wiki]

#23862: Tor only updates guard state after a consensus if it has enough 
directory
info
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  reopened
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client,   |  Actual Points:
  030-backport, 031-backport |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorV
-+-
Changes (by teor):

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


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

Re: [tor-bugs] #23862 [Core Tor/Tor]: Tor only updates guard state after a consensus if it has enough directory info

[Tor Bug Tracker & Wiki]

#23862: Tor only updates guard state after a consensus if it has enough 
directory
info
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client,   |  Actual Points:
  030-backport, 031-backport |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorV
-+-
Changes (by teor):

 * status:  reopened => merge_ready


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

Re: [tor-bugs] #23862 [Core Tor/Tor]: Tor only updates guard state after a consensus if it has enough directory info

[Tor Bug Tracker & Wiki]

#23862: Tor only updates guard state after a consensus if it has enough 
directory
info
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-guard, tor-bridge, tor-client,   |  Actual Points:
  030-backport, 031-backport |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorV
-+-

Comment (by teor):

 Oops, there is a typo in the name of the changes file, it does not pass
 `make check-changes`.

 Please see my branch bug23862-changes-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] #24601 [Metrics/Website]: CollecTor directory listing apparently breaks when a directory in recent/ runs dry

[Tor Bug Tracker & Wiki]

#24601: CollecTor directory listing apparently breaks when a directory in 
recent/
runs dry
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * priority:  Medium => Low


Comment:

 There is no log, AFAIK.

 The listing is broken in the sense that it stopped being updated. Well, I
 should write ''was'' broken, because it's fixed again, probably due to a
 server restart for #24602, entirely unrelated to this ticket.

 We might still be able to reproduce this issue by feeding a modified
 `index.json` file, say, without any bridge descriptors into the servlet.
 Just to avoid future occurrences.

 I realize that this is now a rather weak bug report with just an idea for
 reproducing, the error being gone, and the error not being the end of the
 world. Setting priority to 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] #9390 [Core Tor/Tor]: Warn if you're being a public relay but have too-low file descriptor limit

[Tor Bug Tracker & Wiki]

#9390: Warn if you're being a public relay but have too-low file descriptor 
limit
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay easy dos resources |  Actual Points:
  logging|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:6 aruna1234]:
 > As far as I have understood the bug,a new function has to be created
 which would check whether the relay is a public relay

 Use `public_server_mode(get_options())` to check if tor is a relay.

 > and if it is then check whether the limit is under 8192. If yes then
 warn the user about the same. Let me know if I understood something wrong.
 > The only thing that I am not sure of is where will the new function be
 added?

 You could add code at the end of `set_max_file_descriptors()` that checks
 `limit`.

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

Re: [tor-bugs] #23966 [Core Tor/Tor]: Refactor node_has_curve25519_onion_key() to use node_get_curve25519_onion_key()

[Tor Bug Tracker & Wiki]

#23966: Refactor node_has_curve25519_onion_key() to use
node_get_curve25519_onion_key()
+
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  easy, refactor  |  Actual Points:
Parent ID:  | Points:  0.2
 Reviewer:  |Sponsor:
+

Comment (by teor):

 Did you compile this and run the unit tests using "make check"?

 Please fix the indenting here - we indent code blocks, so this will
 confuse people:
 {{{
if(!node)
return NULL;
 }}}

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

Re: [tor-bugs] #9390 [Core Tor/Tor]: Warn if you're being a public relay but have too-low file descriptor limit

[Tor Bug Tracker & Wiki]

#9390: Warn if you're being a public relay but have too-low file descriptor 
limit
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay easy dos resources |  Actual Points:
  logging|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by aruna1234):

 As far as I have understood the bug,a new function has to be created which
 would check whether the relay is a public relay and if it is then check
 whether the limit is under 8192. If yes then warn the user about the same.
 Let me know if I understood something wrong.
 The only thing that I am not sure of is where will the new function be
 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] #24601 [Metrics/Website]: CollecTor directory listing apparently breaks when a directory in recent/ runs dry

[Tor Bug Tracker & Wiki]

#24601: CollecTor directory listing apparently breaks when a directory in 
recent/
runs dry
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Is there any logging about this incident?  And, what does the 'broken'
 listing look like?

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

Re: [tor-bugs] #23966 [Core Tor/Tor]: Refactor node_has_curve25519_onion_key() to use node_get_curve25519_onion_key()

[Tor Bug Tracker & Wiki]

#23966: Refactor node_has_curve25519_onion_key() to use
node_get_curve25519_onion_key()
+
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  easy, refactor  |  Actual Points:
Parent ID:  | Points:  0.2
 Reviewer:  |Sponsor:
+
Changes (by aruna1234):

 * Attachment "0004-node_has_curve25519_onion_key-is-refactored-and-
 dupl.patch" 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] #24602 [Internal Services/Tor Sysadmin Team]: Please install r-cran-tidyr on meronense

[Tor Bug Tracker & Wiki]

#24602: Please install r-cran-tidyr on meronense
-+
 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 qbi):

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


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

Re: [tor-bugs] #24580 [Metrics/ExoneraTor]: Let ExoneraTor only serve completed dates

[Tor Bug Tracker & Wiki]

#24580: Let ExoneraTor only serve completed dates
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+--

Comment (by karsten):

 Sounds good to me. I haven't had the time to read up on all Java 8
 date/time things yet, so I might not pick the best classes. Happy to
 switch everything else in this class (ideally in a separate commit).

 I'd say whoever start working on this leaves a quick note here. :)

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

Re: [tor-bugs] #24580 [Metrics/ExoneraTor]: Let ExoneraTor only serve completed dates

[Tor Bug Tracker & Wiki]

#24580: Let ExoneraTor only serve completed dates
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+--

Comment (by iwakeh):

 As there are only dates used in the servlet the calculations should also
 only use date time objects. In addition, the calculation shouldn't rely on
 string comparison when actually comparing dates.

 For example:
 {{{
 #!diff
 diff --git
 a/src/main/java/org/torproject/metrics/exonerator/ExoneraTorServlet.java
 b/src/main/java/org/torproject/metrics/exonerator/ExoneraTorServlet.java
 index c26d08e..beea0d2 100644
 ---
 a/src/main/java/org/torproject/metrics/exonerator/ExoneraTorServlet.java
 +++
 b/src/main/java/org/torproject/metrics/exonerator/ExoneraTorServlet.java
 @@ -15,8 +15,9 @@ import java.io.StringWriter;
  import java.net.URL;
  import java.text.ParseException;
  import java.text.SimpleDateFormat;
 +import java.time.LocalDate;
  import java.time.ZoneOffset;
 -import java.time.ZonedDateTime;
 +import java.time.format.DateTimeFormatter;
  import java.util.ArrayList;
  import java.util.Arrays;
  import java.util.List;
 @@ -321,8 +322,8 @@ public class ExoneraTorServlet extends HttpServlet {
 * it matches the day before the current system date (in UTC) or is
 even
 * younger. */
static boolean checkTimestampTooRecent(String timestampParameter) {
 -return timestampParameter.compareTo(ZonedDateTime.now(ZoneOffset.UTC)
 -.toLocalDate().minusDays(1).toString()) >= 0;
 +return LocalDate.parse(timestampParameter,
 DateTimeFormatter.ISO_LOCAL_DATE)
 +.isAfter(LocalDate.now(ZoneOffset.UTC).minusDays(2));
}

/* Helper method for fetching a query response via URL. */
 }}}

 Actually, this would be a perfect time to introduce java 8 date time
 classes throughout this servlet; avoiding the mixture of parsing methods
 and most likely reducing the number of lines (' checkTimestampTooRecent'
 could actually be avoided with the use of `isAfter` etc.), and also making
 the code also more readable.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24602 [Internal Services/Tor Sysadmin Team]: Please install r-cran-tidyr on meronense

[Tor Bug Tracker & Wiki]

#24602: Please install r-cran-tidyr on meronense
-+-
 Reporter:  karsten  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Please install the `r-cran-tidyr` package on meronense.

 I'm planning to use this R package and at least one more that is a
 dependency of this Debian package in future graphs. That code is not
 written/reviewed yet, but it will be good to have this package installed
 on meronense when we're ready to deploy the new code.

 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] #21847 [Applications/Tor Browser]: Update copy for security slider to be consistent with the mobile experience

[Tor Bug Tracker & Wiki]

#21847: Update copy for security slider to be consistent with the mobile 
experience
-+-
 Reporter:  isabela  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-security-slider,  |  Actual Points:
  TorBrowserTeam201712, GeorgKoppen201712|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:11 teor]:
 > Can we do some minor English copy editing here?

 Sure.

 > "causing some sites will lose functionality"
 > "causing some sites to lose functionality"

 That's actually already fixed in the mobile strings. So it might be a copy
 and paste error or older strings which are shown in comment:description.

 > And is there any reason why these headings are different?
 >
 > "At this cautious setting:"
 > "At the strict security setting:"
 >
 > If not, let's use:
 >
 > "At the cautious security setting:"
 > "At the strict security setting:"
 >
 > Or maybe for both:
 >
 > "At this setting:"

 We have

 `safer_list_label = At this safer setting`
 `safest_list_label = At the safest setting`

 in the mobile strings. I think I'll use "At the safer setting" and "At the
 safest setting" instead assuming `safer_list_label` has a typo.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24601 [Metrics/Website]: CollecTor directory listing apparently breaks when a directory in recent/ runs dry

[Tor Bug Tracker & Wiki]

#24601: CollecTor directory listing apparently breaks when a directory in 
recent/
runs dry
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 The CollecTor directory listings on Tor Metrics broke at or shortly after
 2017-12-11 13:08:

 https://metrics.torproject.org/collector/recent/relay-descriptors/server-
 descriptors/

 The index.json file looks okay right now:

 https://collector.torproject.org/index/index.json

 I suspect the reason is that some of the directories in `recent/`
 containing sanitized bridge descriptors ran dry yesterday afternoon. Maybe
 we ran into a `NullPointerException` or something.

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

Re: [tor-bugs] #24433 [Obfuscation/BridgeDB]: moat isn't returning bridges on successful CAPTCHA completion

[Tor Bug Tracker & Wiki]

#24433: moat isn't returning bridges on successful CAPTCHA completion
--+--
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bridgedb-dist moat|  Actual Points:  .5
Parent ID:| Points:  1
 Reviewer:|Sponsor:  SponsorM
--+--
Changes (by intrigeri):

 * cc: anonym, intrigeri (added)


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

Re: [tor-bugs] #23971 [Applications/Tor Launcher]: implement multi-step progress bar for new Tor Launcher UI

[Tor Bug Tracker & Wiki]

#23971: implement multi-step progress bar for new Tor Launcher UI
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #21951 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by intrigeri):

 * cc: anomym, intrigeri (added)


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

Re: [tor-bugs] #21951 [Applications/Tor Launcher]: Helping censored users bootstrap to Tor: Tor launcher improvements and automation

[Tor Bug Tracker & Wiki]

#21951: Helping censored users bootstrap to Tor: Tor launcher improvements and
automation
---+--
 Reporter:  linda  |  Owner:  linda
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by intrigeri):

 * cc: intrigeri, anonym (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] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201712   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by intrigeri):

 * cc: anonym (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] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201712   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by intrigeri):

 * cc: intrigeri (added)


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

Re: [tor-bugs] #24592 [Applications/Tor Browser]: Tor Browser crashes on Motherboard website

[Tor Bug Tracker & Wiki]

#24592: Tor Browser crashes on Motherboard website
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * keywords:   => tbb-crash
 * status:  new => needs_information
 * severity:  Normal => Major
 * priority:  Medium => High


Comment:

 Works for me. Do you feel you could try to follow the debugging steps on
 our HACKING document and come back with a stack trace from your crashes?
 See:
 https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#Usinggdb.

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

Re: [tor-bugs] #18859 [Core Tor/Tor]: A new SOCKS connection should use a pre-built circuit for its first stream

[Tor Bug Tracker & Wiki]

#18859: A new SOCKS connection should use a pre-built circuit for its first 
stream
-+-
 Reporter:  arthuredelstein  |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-performance tor-client   |  Actual Points:
  performance  031-backpot   |
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by intrigeri):

 * cc: intrigeri (added)


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

Re: [tor-bugs] #24565 [Community/Tor Support]: User queries and issues

[Tor Bug Tracker & Wiki]

#24565: User queries and issues
---+---
 Reporter:  Pari   |  Owner:  phoul
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by gk):

 * owner:  (none) => phoul
 * component:  - Select a component => Community/Tor Support


Comment:

 I wonder if it would be smart to have a wiki page on trac instead. It
 seems to me it gets easily messy if we want to use the bug tracker for
 that project.

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

Re: [tor-bugs] #22084 [Applications/Tor Browser]: Neuter NetworkInformation API on Tor Browser Mobile

[Tor Bug Tracker & Wiki]

#22084: Neuter NetworkInformation API on Tor Browser Mobile
-+-
 Reporter:  gk   |  Owner:  igt0
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile tbb-fingerprinting,   |  Actual Points:
  TorBrowserTeam201712R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-mobile tbb-fingerprinting => tbb-mobile tbb-
 fingerprinting, TorBrowserTeam201712R


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

Re: [tor-bugs] #24423 [Core Tor/Tor]: Fix STACK warnings in Tor

[Tor Bug Tracker & Wiki]

#24423: Fix STACK warnings in Tor
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-27  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+

Comment (by gk):

 Replying to [comment:17 nickm]:
 > Putting back in accepted for the tortls issue.  (gk, do I understand
 correctly that I never figured out how to make stack stop complaining
 about that?)

 Correct.

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