Re: [tor-bugs] #16678 [Applications/Tor Browser]: Enhance KeyboardEvent fingerprinting protection for unusual characters

[Tor Bug Tracker & Wiki]

#16678: Enhance KeyboardEvent fingerprinting protection for unusual characters
-+-
 Reporter:  arthuredelstein  |  Owner:  sysrqb
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting,  |  Actual Points:
  TorBrowserTeam201709   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * status:  needs_revision => needs_review


Comment:

 As mentioned on the ML [0], I pushed a final branch [1] for this.

 One commit suppressed the keydown event for Dead keys [2], and the other
 commit is mostly fixups and improves based on Arthur's feedback [3].

 [0] https://lists.torproject.org/pipermail/tbb-
 dev/2017-September/000620.html
 [1] https://github.com/sysrqb/tor-browser/tree/bug16678_2
 [2] https://github.com/sysrqb/tor-
 browser/commit/29d8c9ffec2340e64ad26a0dbc48315b47ac6028
 [3] https://github.com/sysrqb/tor-
 browser/commit/962194b1151768ddc6d3beb30132d833c1a4a81f

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

Re: [tor-bugs] #23602 [Core Tor/Tor]: Detect homebrew OpenSSL on OSX (was:Fix compilation on macOS)

[Tor Bug Tracker & Wiki]

#23602: Detect homebrew OpenSSL on OSX (was:Fix compilation on macOS)
-+-
 Reporter:  hellais  |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport, 032-backport, 031  |  Actual Points:
  -backport-maybe, 030-backport-maybe|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:   => 029-backport, 032-backport, 031-backport-maybe, 030
 -backport-maybe
 * status:  needs_review => merge_ready


Comment:

 Homebrew has always worked for me, but I pass custom paths to ./configure.
 Getting it working with minimal intervention would be great.

 `./configure && make test` works for me on macOS 10.12 with homebrew and
 the standard developer tools. I think I might have a recent clang custom
 installed, too.

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

Re: [tor-bugs] #23653 [Core Tor/Tor]: When accessing onion service with no fetchable descriptor, Tor sits around until timeout rather than hanging up

[Tor Bug Tracker & Wiki]

#23653: When accessing onion service with no fetchable descriptor, Tor sits 
around
until timeout rather than hanging up
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 arma asked me on IRC how to make a hidden service address no-one has ever
 posted.

 This command will do it:

 {{{
 export TORDIR=`mktemp -d`
 src/or/tor DisableNetwork 1 DataDirectory "$TORDIR/data" HiddenServiceDir
 "$TORDIR/hs" HiddenServiceVersion 3 HiddenServicePort 1
 # type ctrl-C
 cat "$TORDIR/hs/hostname"
 }}}

 It can be used for v2 or v3 by modifying the HiddenServiceVersion option.

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

Re: [tor-bugs] #23653 [Core Tor/Tor]: When accessing onion service with no fetchable descriptor, Tor sits around until timeout rather than hanging up

[Tor Bug Tracker & Wiki]

#23653: When accessing onion service with no fetchable descriptor, Tor sits 
around
until timeout rather than hanging up
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 v3 onion addresses exhibit the same bug:
 {{{
 Sep 26 01:50:06.898 [info] hs_pick_hsdir(): Could not pick one of the
 responsible hidden service directories, because we requested them all
 recently without success.
 Sep 26 01:50:06.898 [info] fetch_v3_desc(): Couldn't pick a v3 hsdir.
 }}}
 yet I wait the full 120 seconds until
 {{{
 Sep 26 01:51:56.882 [notice] Tried for 120 seconds to get a connection to
 7ga6xlti5joarlmkuhjaifa47ukgcwz6tfndgax45ocyn4rixm632jie:80. Giving up.
 (waiting for rendezvous desc)
 }}}

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

Re: [tor-bugs] #23416 [Core Tor/Tor]: Document the precision and limits of sample_laplace_distribution()

[Tor Bug Tracker & Wiki]

#23416: Document the precision and limits of sample_laplace_distribution()
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-relay, privcount  |  Actual Points:
Parent ID:  #23061| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


Comment:

 This is a work in progress, it can wait until 0.3.3

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

Re: [tor-bugs] #23415 [Core Tor/Tor]: sample_laplace_distribution() should take multiple random inputs

[Tor Bug Tracker & Wiki]

#23415: sample_laplace_distribution() should take multiple random inputs
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:
  031-backport, 030-backport, 029-backport, 028  |
  -backport-maybe, 026-backport-maybe|
Parent ID:  #23061   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

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


Comment:

 This can wait until 0.3.3

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

Re: [tor-bugs] #23500 [Core Tor/Tor]: check-spaces.pl should check spaces after a comma when in functions.

[Tor Bug Tracker & Wiki]

#23500: check-spaces.pl should check spaces after a comma when in functions.
--+
 Reporter:  ewong |  Owner:  (none)
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  code-style|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:10 ewong]:
 > as it stands, the find.. command is getting difficult since I have yet
 to discover
 > a single command line which checks if the additional ','->', ' change
 will increase
 > the line length.. if so, it changes the line and then wraps the line
 near the end;
 > but that affects a bunch load of other lines.
 >
 > I'm starting to feel like just going through the list of files and
 changing
 > it manually will make it 'easier'.   might anyone have any advice?
 > thanks

 A mass replace script in one commit, then a few manual fixes in the next
 commit is fine.

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

Re: [tor-bugs] #23653 [Core Tor/Tor]: When accessing onion service with no fetchable descriptor, Tor sits around until timeout rather than hanging up

[Tor Bug Tracker & Wiki]

#23653: When accessing onion service with no fetchable descriptor, Tor sits 
around
until timeout rather than hanging up
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Notice that in git master now, rend_client_desc_trynow() has an
 {{{
   } else { /* 404, or fetch didn't get that far */
 }}}
 clause, which is never reached because the function is only called from
 one point in handle_response_fetch_renddesc_v2() where we just
 successfully got the descriptor.

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

Re: [tor-bugs] #23653 [Core Tor/Tor]: When accessing onion service with no fetchable descriptor, Tor sits around until timeout rather than hanging up

[Tor Bug Tracker & Wiki]

#23653: When accessing onion service with no fetchable descriptor, Tor sits 
around
until timeout rather than hanging up
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 commit d8b93b3 is where it's at:

 {{{
 -  ret = rend_client_fetch_v2_desc(rend_query, NULL);
 -  if (ret <= 0) {
 -/* Close pending connections on error or if no hsdir can be found. */
 -rend_client_desc_trynow(rend_query->onion_address);
 -  }
 +  rend_client_fetch_v2_desc(rend_query, NULL);
 +  /* We don't need to look the error code because either on failure or
 +   * success, the necessary steps to continue the HS connection will be
 +   * triggered once the descriptor arrives or if all fetch failed. */
return;
 }}}

 Where does the "if all fetch failed" logic kick in?

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

Re: [tor-bugs] #23653 [Core Tor/Tor]: When accessing onion service with no fetchable descriptor, Tor sits around until timeout rather than hanging up

[Tor Bug Tracker & Wiki]

#23653: When accessing onion service with no fetchable descriptor, Tor sits 
around
until timeout rather than hanging up
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arma):

 * version:   => Tor: 0.2.8.2-alpha


Comment:

 Tor 0.2.8.2-alpha has the bad behavior.

 Tor 0.2.8.1-alpha has the good behavior.

 I am suspecting #15937.

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

Re: [tor-bugs] #16678 [Applications/Tor Browser]: Enhance KeyboardEvent fingerprinting protection for unusual characters

[Tor Bug Tracker & Wiki]

#16678: Enhance KeyboardEvent fingerprinting protection for unusual characters
-+-
 Reporter:  arthuredelstein  |  Owner:  sysrqb
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting,  |  Actual Points:
  TorBrowserTeam201709   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Okay, following up on the comment Arthur made [0], I think we can mitigate
 this by suppressing the keydown events on dead keys and track these keys
 as modifier keys. The current behavior when a dead key is pressed is an
 event is dispatched with `key="Dead"`. In Firefox, the javascript keydown
 callback's event.code reflects the key pressed (ex. BracketLeft), and
 `charCode=which=keyCode=location=0` and `altKey=ctrlKey=metaKey=false`.
 With this patch, Tor Browser sends `key="Dead"` and checks the hashmap for
 the proper code (of which there isn't a mapping, so it chooses the
 default). When the next character is pressed, Firefox and Tor Browser
 dispatch another event that contains the raw (unmodified) character that
 was pressed (ex. `key='o'`). It does not make the substitution. I believe
 we can use the functionality already available in the TextInputProcessor
 for tracking a dead key and dispatching an event with the modified
 character.

 I think in the short term, it's safe to suppress keydown events dead keys.
 As with shift/alt/altgr this only filters dead keys from javascript
 keydown callbacks, I confirmed this does not affec
 t input in chrome fields or using dead keys on interactive javascript
 websites like etherpad.

 [0] https://github.com/sysrqb/tor-
 browser/commit/52b021674c6885d30e851557b14a8d70b5702a75#commitcomment-24553008

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

Re: [tor-bugs] #23653 [Core Tor/Tor]: When accessing onion service with no fetchable descriptor, Tor sits around until timeout rather than hanging up

[Tor Bug Tracker & Wiki]

#23653: When accessing onion service with no fetchable descriptor, Tor sits 
around
until timeout rather than hanging up
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 I noticed this bug because onionshare's behavior is to launch the
 transient onion service via the control port, and then try connecting to
 the onion address repeatedly until it works. In the old onionshare
 behavior (Tor 0.2.5), it tried a few times, with not much delay between
 tries, and then it was ready. In the new onionshare behavior (Tor 0.3.2),
 it has to wait the whole 120 seconds before it learns that its first try
 didn't work.

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

Re: [tor-bugs] #23653 [Core Tor/Tor]: When accessing onion service with no fetchable descriptor, Tor sits around until timeout rather than hanging up

[Tor Bug Tracker & Wiki]

#23653: When accessing onion service with no fetchable descriptor, Tor sits 
around
until timeout rather than hanging up
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Here are the relevant logs from the 0.2.5 case:
 {{{
 Sep 26 00:07:40.912 [info] connection_dir_client_reached_eof(): Received
 rendezvous descriptor (size 0, status 404 ("Not found"))
 Sep 26 00:07:40.912 [info] connection_dir_client_reached_eof(): Fetching
 v2 rendezvous descriptor failed: Retrying at another directory.
 Sep 26 00:07:40.912 [debug] conn_close_if_marked(): Cleaning up connection
 (fd -1).
 Sep 26 00:07:40.912 [debug] rend_client_refetch_v2_renddesc(): Fetching v2
 rendezvous descriptor for service qiu3onp7v7z25u5i
 Sep 26 00:07:40.912 [info] directory_get_from_hs_dir(): Could not pick one
 of the responsible hidden service directories, because we requested them
 all recently without success.
 Sep 26 00:07:40.912 [info] directory_get_from_hs_dir(): Could not pick one
 of the responsible hidden service directories, because we requested them
 all recently without success.
 Sep 26 00:07:40.912 [info] rend_client_refetch_v2_renddesc(): Could not
 pick one of the responsible hidden service directories to fetch
 descriptors, because we already tried them all unsuccessfully.
 Sep 26 00:07:40.912 [notice] Closing stream for 'qiu3onp7v7z25u5i.onion':
 hidden service is unavailable (try again later).
 Sep 26 00:07:40.912 [info] rend_client_note_connection_attempt_ended():
 Connection attempt for qiu3onp7v7z25u5i has ended; cleaning up temporary
 state.
 }}}

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

[tor-bugs] #23653 [Core Tor/Tor]: When accessing onion service with no fetchable descriptor, Tor sits around until timeout rather than hanging up

[Tor Bug Tracker & Wiki]

#23653: When accessing onion service with no fetchable descriptor, Tor sits 
around
until timeout rather than hanging up
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  regression
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Running Tor git master, and trying to connect to an onion address that I
 just made up (nothing has ever been there):
 {{{
 $ torify telnet qiu3onp7v7z25u5i.onion 80
 telnet: Unable to connect to remote host: Connection timed out
 }}}
 And on the Tor log I see
 {{{
 Sep 25 23:54:17.776 [notice] Tried for 120 seconds to get a connection to
 qiu3onp7v7z25u5i:80. Giving up. (waiting for rendezvous desc)
 }}}

 That is, it took 120 seconds to fail.

 Compare to when using Tor release-0.2.5:
 {{{
 $ torify telnet qiu3onp7v7z25u5i.onion 80
 telnet: Unable to connect to remote host: No route to host
 }}}

 and the Tor log says
 {{{
 Sep 26 00:06:37.515 [notice] Closing stream for 'qiu3onp7v7z25u5i.onion':
 hidden service is unavailable (try again later).
 }}}

 In the Tor 0.2.5 case, I got my answer in 5-10 seconds: it tried each of
 the hsdirs, and when the last one said 404, it hung up on the stream. In
 the Tor master case, it *knew* the answer in 5-10 seconds, but it just let
 my stream sit there doing nothing until the timeout arrived.

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

Re: [tor-bugs] #23653 [Core Tor/Tor]: When accessing onion service with no fetchable descriptor, Tor sits around until timeout rather than hanging up

[Tor Bug Tracker & Wiki]

#23653: When accessing onion service with no fetchable descriptor, Tor sits 
around
until timeout rather than hanging up
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arma):

 * cc: asn, dgoulet (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] #23652 [Internal Services/Service - trac]: I get this error every time I try to sign into trac.torptoject.org, using Safari Version 11.0 (13604.1.38.1.6)

[Tor Bug Tracker & Wiki]

#23652: I get this error every time I try to sign into trac.torptoject.org, 
using
Safari Version 11.0 (13604.1.38.1.6)
--+-
 Reporter:  Dbryrtfbcbhgf |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:4 arma]:
 > (I just tried logging in to trac with the wrong password, and I got that
 traceback.)
 Thanks arma, it looks like I was entering my old/wrong password. the wrong
 password error should be improved by showing that traceback when the wrong
 password is entered.

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

Re: [tor-bugs] #23652 [Internal Services/Service - trac]: I get this error every time I try to sign into trac.torptoject.org, using Safari Version 11.0 (13604.1.38.1.6)

[Tor Bug Tracker & Wiki]

#23652: I get this error every time I try to sign into trac.torptoject.org, 
using
Safari Version 11.0 (13604.1.38.1.6)
--+-
 Reporter:  Dbryrtfbcbhgf |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 (I just tried logging in to trac with the wrong password, and I got that
 traceback.)

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

Re: [tor-bugs] #23652 [Internal Services/Service - trac]: I get this error every time I try to sign into trac.torptoject.org, using Safari Version 11.0 (13604.1.38.1.6)

[Tor Bug Tracker & Wiki]

#23652: I get this error every time I try to sign into trac.torptoject.org, 
using
Safari Version 11.0 (13604.1.38.1.6)
--+-
 Reporter:  Dbryrtfbcbhgf |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by arma):

 * owner:  (none) => qbi
 * priority:  High => Medium
 * component:  Webpages/Website => Internal Services/Service - trac
 * severity:  Major => Normal


Comment:

 This is the traceback that people are getting when they put in the wrong
 password, right?

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

Re: [tor-bugs] #23651 [- Select a component]: ADDONS

[Tor Bug Tracker & Wiki]

#23651: ADDONS
--+
 Reporter:  dmeek94@… |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Dbryrtfbcbhgf):

 Try reinstalling TorBrowser completely, delete the torbrowser-data folder.
 Also make sure you DO NOT install any 3RD party ad-ons

 Check the FAQ to see a explanation of why you should not install add-ons.
 https://www.torproject.org/docs/faq.html.en#TBBOtherExtensions

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

Re: [tor-bugs] #23652 [Webpages/Website]: I get this error every time I try to sign into trac.torptoject.org, using Safari Version 11.0 (13604.1.38.1.6)

[Tor Bug Tracker & Wiki]

#23652: I get this error every time I try to sign into trac.torptoject.org, 
using
Safari Version 11.0 (13604.1.38.1.6)
--+
 Reporter:  Dbryrtfbcbhgf |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by Dbryrtfbcbhgf):

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


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

Re: [tor-bugs] #23652 [Webpages/Website]: I get this error every time I try to sign into trac.torptoject.org, using Safari Version 11.0 (13604.1.38.1.6)

[Tor Bug Tracker & Wiki]

#23652: I get this error every time I try to sign into trac.torptoject.org, 
using
Safari Version 11.0 (13604.1.38.1.6)
--+
 Reporter:  Dbryrtfbcbhgf |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Dbryrtfbcbhgf):

 I'm running macOS 10.13 (17A365)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23652 [Webpages/Website]: I get this error every time I try to sign into trac.torptoject.org, using Safari Version 11.0 (13604.1.38.1.6)

[Tor Bug Tracker & Wiki]

#23652: I get this error every time I try to sign into trac.torptoject.org, 
using
Safari Version 11.0 (13604.1.38.1.6)
--+
 Reporter:  Dbryrtfbcbhgf |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I get this error every time I try to sign into trac.torptoject.org, using
 Safari Version 11.0 (13604.1.38.1.6)
 I have to use Firefox just to sign-in.

 Traceback (most recent call last):
   File "/usr/lib/python2.7/dist-packages/trac/web/api.py", line 710, in
 send_error
 data, 'text/html')
   File "/usr/lib/python2.7/dist-packages/trac/web/chrome.py", line 1108,
 in render_template
 message = Markup(req.session.pop('chrome.%s.%d'
   File "/usr/lib/python2.7/dist-packages/trac/web/api.py", line 492, in
 __getattr__
 value = self.callbacks[name](self)
   File "/usr/lib/python2.7/dist-packages/trac/web/main.py", line 350, in
 _get_session
 return Session(self.env, req)
   File "/usr/lib/python2.7/dist-packages/trac/web/session.py", line 242,
 in __init__
 if req.authname == 'anonymous':
   File "/usr/lib/python2.7/dist-packages/trac/web/api.py", line 492, in
 __getattr__
 value = self.callbacks[name](self)
   File "/usr/lib/python2.7/dist-packages/trac/web/main.py", line 172, in
 authenticate
 authname = authenticator.authenticate(req)
   File "build/bdist.linux-x86_64/egg/acct_mgr/util.py", line 81, in wrap
 return func(self, *args, **kwds)
   File "build/bdist.linux-x86_64/egg/acct_mgr/web_ui.py", line 451, in
 authenticate
 username = self._remote_user(req)
   File "build/bdist.linux-x86_64/egg/acct_mgr/web_ui.py", line 766, in
 _remote_user
 if acctmgr.check_password(username, password) is True:
   File "build/bdist.linux-x86_64/egg/acct_mgr/api.py", line 287, in
 check_password
 valid = store.check_password(user, password)
   File "build/bdist.linux-x86_64/egg/acct_mgr/htfile.py", line 69, in
 check_password
 return self._check_userline(user, password, line)
   File "build/bdist.linux-x86_64/egg/acct_mgr/htfile.py", line 207, in
 _check_userline
 return suffix == htpasswd(password, suffix)
   File "build/bdist.linux-x86_64/egg/acct_mgr/pwhash.py", line 140, in
 htpasswd
 available."""))
 NotImplementedError: Neither are "sha2" hash algorithms supported by the
 "crypt" module on this platform nor is "passlib"
 available.

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

Re: [tor-bugs] #23650 [Core Tor/Tor]: Tor source code has many typos

[Tor Bug Tracker & Wiki]

#23650: Tor source code has many typos
--+--
 Reporter:  cypherpunks   |  Owner:  arma
 Type:  defect| Status:  assigned
 Priority:  Very Low  |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Big fan.

 I'll note that this anonymous person just picked me as the owner of the
 ticket, and that's not actually the same as making me the owner of the
 ticket.

 If somebody wants to do up a branch on master for these, that would be
 great.

 Also, we should make sure that we don't accidentally try to fix any typos
 that made it into the actual protocol, a la "Dependant" in control-
 spec.txt. Or at least, if we do we should fix them more thoroughly.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23651 [- Select a component]: ADDONS

[Tor Bug Tracker & Wiki]

#23651: ADDONS
--+
 Reporter:  dmeek94@… |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Some addons install but unable to open or run. Https everywhere randomly
 disappears.

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

Re: [tor-bugs] #23170 [Core Tor/Tor]: Include ed25519 relay id keys in the consensus

[Tor Bug Tracker & Wiki]

#23170: Include ed25519 relay id keys in the consensus
-+-
 Reporter:  asn  |  Owner:  nickm
 Type:  task | Status:
 |  accepted
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224 tor-dirauth tor-hs ed25519   |  Actual Points:
  needs-proposal |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-

Comment (by teor):

 Replying to [comment:6 arma]:
 > Hopefully useful thoughts:
 >
 > A) Is the only reason we need ed keys in the consensus for this hashring
 thing? That seems like a sad reason to put in all the overhead for every
 client for every hour forever.

 Consensus diffs will make this into a once-off addition for 0.3.1 and
 later clients.

 Also, if we're having trouble getting some descriptors for our primary
 guards, does this fix that issue as well?

 > A2) And if that is the only use, we could put like 4 characters of the
 key in, as just a hashring hint?

 No, because the key is hashed, so you need the entire key.

 > B) Is there a longer term plan for phasing out rsa keys entirely, and
 replacing them with ed keys?

 I hope so.

 > If not, maybe prop224 hashring should use rsa keys.

 No, it's too late to change this for 0.3.2.

 > C) Maybe the consensus overhead isn't so bad because of consensus diffs.
 Or maybe it is? Has anybody done any follow-up on the consensus diff
 deployment to see what effect it has had?

 Yes, ahf wrote an entire technical report on it. Search tor-project@ for
 Isabela's recent report.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23650 [Core Tor/Tor]: Tor source code has many typos

[Tor Bug Tracker & Wiki]

#23650: Tor source code has many typos
--+--
 Reporter:  cypherpunks   |  Owner:  arma
 Type:  defect| Status:  assigned
 Priority:  Very Low  |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 {{{
 $ go get -u github.com/client9/misspell/cmd/misspell
 $ misspell .
 .gitlab-ci.yml:23:14: "suspectible" is a misspelling of "susceptible"
 changes/bug23580:2:49: "mentionning" is a misspelling of "mentioning"
 contrib/operator-tools/linux-tor-prio.sh:90:59: "trafic" is a misspelling
 of "traffic"
 configure.ac:535:10: "targetting" is a misspelling of "targeting"
 doc/HACKING/GettingStartedRust.md:119:17: "targetting" is a misspelling of
 "targeting"
 doc/HACKING/Tracing.md:9:17: "seperated" is a misspelling of "separated"
 m4/pkg.m4:56:20: "occurence" is a misspelling of "occurrence"
 scripts/maint/redox.py:104:35: "alledgedly" is a misspelling of
 "allegedly"
 src/common/compat_openssl.h:15:10: "compatability" is a misspelling of
 "compatibility"
 src/common/address.c:1126:23: "comapre" is a misspelling of "compare"
 src/common/compat.c:2447:3: "successfull" is a misspelling of "successful"
 src/common/crypto_ed25519.c:228:28: "occured" is a misspelling of
 "occurred"
 src/common/crypto_ed25519.c:262:18: "successfuly" is a misspelling of
 "successfully"
 src/common/crypto_ed25519.c:526:30: "sucess" is a misspelling of "success"
 src/common/crypto_ed25519.c:716:13: "cannonical" is a misspelling of
 "canonical"
 src/common/crypto_ed25519.c:756:50: "neccessary" is a misspelling of
 "necessary"
 scripts/maint/updateFallbackDirs.py:214:52: "multipled" is a misspelling
 of "multiplied"
 scripts/maint/updateFallbackDirs.py:550:34: "bandwdith" is a misspelling
 of "bandwidth"
 scripts/maint/updateFallbackDirs.py:1553:35: "bandwdith" is a misspelling
 of "bandwidth"
 src/common/crypto.c:1527:3: "sucess" is a misspelling of "success"
 src/common/crypto.c:2835:35: "foward" is a misspelling of "forward"
 src/common/crypto.c:2848:5: "comparision" is a misspelling of "comparison"
 src/common/timers.c:66:39: "inefficent" is a misspelling of "inefficient"
 src/common/tortls.c:1941:34: "intial" is a misspelling of "initial"
 src/ext/curve25519_donna/README:9:0: "dependancies" is a misspelling of
 "dependencies"
 doc/tor.1.txt:2416:26: "simultanous" is a misspelling of "simultaneous"
 doc/tor.1.txt:2831:4: "decribing" is a misspelling of "describing"
 src/ext/ed25519/donna/README.md:59:25: "aginst" is a misspelling of
 "against"
 src/ext/ed25519/donna/README.md:76:25: "aginst" is a misspelling of
 "against"
 src/ext/ed25519/donna/ed25519_tor.c:135:45: "implementaion" is a
 misspelling of "implementation"
 src/common/util.c:3048:18: "sucess" is a misspelling of "success"
 src/common/util.c:3899:46: "accomodate" is a misspelling of "accommodate"
 src/common/util.c:3929:10: "processs" is a misspelling of "processes"
 src/or/bridges.c:354:40: "adress" is a misspelling of "address"
 src/or/circpathbias.c:1470:3: "transfered" is a misspelling of
 "transferred"
 src/or/circpathbias.c:1530:3: "transfered" is a misspelling of
 "transferred"
 src/or/circuitlist.c:739:24: "rendevous" is a misspelling of "rendezvous"
 src/or/circuitlist.c:741:24: "rendevous" is a misspelling of "rendezvous"
 src/or/circuitstats.c:167:58: "paramter" is a misspelling of "parameter"
 src/or/circuitstats.c:194:55: "paramter" is a misspelling of "parameter"
 src/or/circuitstats.c:221:55: "paramter" is a misspelling of "parameter"
 src/or/circuitstats.c:253:55: "paramter" is a misspelling of "parameter"
 src/or/circuitstats.c:277:60: "paramter" is a misspelling of "parameter"
 src/or/circuitstats.c:309:55: "paramter" is a misspelling of "parameter"
 src/or/circuitstats.c:356:61: "paramter" is a misspelling of "parameter"
 src/or/circuitstats.c:386:58: "paramter" is a misspelling of "parameter"
 src/or/connection.c:4129:46: "owernship" is a misspelling of "ownership"
 src/or/connection.c:4139:46: "owernship" is a misspelling of "ownership"
 src/or/config.c:2901:28: "occurances" is a misspelling of "occurrences"
 src/or/dirserv.c:46:13: "reponsible" is a misspelling of "responsible"
 src/or/dirserv.c:1089:18: "bandwith" is a misspelling of "bandwidth"
 src/or/dirserv.h:126:45: "encrytped" is a misspelling of "encrypted"
 src/or/dirvote.c:666:48: "accidently" is a misspelling of "accidentally"
 src/or/control.c:4695:5: "Succeded" is a misspelling of "Succeeded"
 src/or/dns.c:22:38: "rela" is a misspelling of "real"
 src/or/hs_cache.c:693:28: "explicitely" is a misspelling of "explicitly"
 src/or/hs_cache.c:778:28: "explicitely" is a misspelling of "explicitly"
 src/or/hs_client.c:540:5: "Explicitely" is a misspelling of "Explicitly"
 src/or/hs_config.c:553:38: 

Re: [tor-bugs] #23648 [Applications/Tor Browser]: I get this error on duckduckgo when using this exit node "8175A86D8896CEA37FDC67311F9BDC1DDCBE8136"

[Tor Bug Tracker & Wiki]

#23648: I get this error on duckduckgo when using this exit node
"8175A86D8896CEA37FDC67311F9BDC1DDCBE8136"
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Let us know what you learn from them!

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

Re: [tor-bugs] #16678 [Applications/Tor Browser]: Enhance KeyboardEvent fingerprinting protection for unusual characters

[Tor Bug Tracker & Wiki]

#16678: Enhance KeyboardEvent fingerprinting protection for unusual characters
-+-
 Reporter:  arthuredelstein  |  Owner:  sysrqb
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting,  |  Actual Points:
  TorBrowserTeam201709   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 I'm thinking about where ¢ (U+00A2, cent sign) should be mapped. It's on
 the French-Canadian, Dutch and Brazilian keyboards, but I don't think any
 of them are necessary the most likely to use it. I was attempting to cover
 a breadth with this patch, but maybe quantity isn't quality and we may be
 better off letting some characters fall-through to a sane default rather
 than choose between a few minor options. This is also difficult because
 I'm basing decisions on what I see and read on Wikipedia and some
 additional small amount of research; natives of the respective locales
 would likely provide better data points for making a decision.

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

Re: [tor-bugs] #23648 [Applications/Tor Browser]: I get this error on duckduckgo when using this exit node "8175A86D8896CEA37FDC67311F9BDC1DDCBE8136"

[Tor Bug Tracker & Wiki]

#23648: I get this error on duckduckgo when using this exit node
"8175A86D8896CEA37FDC67311F9BDC1DDCBE8136"
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:1 cypherpunks]:
 > This isn't Tor Project's fault, contact them at the address they gave
 you so that hopefully it gets fixed
 Thanks, I sent a message to Duckduckgo.

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

Re: [tor-bugs] #16678 [Applications/Tor Browser]: Enhance KeyboardEvent fingerprinting protection for unusual characters

[Tor Bug Tracker & Wiki]

#16678: Enhance KeyboardEvent fingerprinting protection for unusual characters
-+-
 Reporter:  arthuredelstein  |  Owner:  sysrqb
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting,  |  Actual Points:
  TorBrowserTeam201709   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:13 arthuredelstein]:
 > Replying to [comment:10 sysrqb]:
 > > I surveyed the different layouts shown on the QWERTY [0], QWERTZ [1],
 and AZERTY [2] pages on Wikipedia, and I documented (roughly) the
 different keys (attached). From this, the patch [3] contains 131 unicode
 characters, covering most Latin charset-based keyboard layouts.
 >
 > Thank you for the patch. I think this is a significant enhancement to
 our previous patch. I wrote some comments and suggested revisions on the
 github commit at
 > https://github.com/sysrqb/tor-
 browser/commit/52b021674c6885d30e851557b14a8d70b5702a75#diff-
 8e201eb85e7d7abe2bb6b78e12c5081aR411
 >

 Thanks for the review! There are still a few outstanding questions I need
 to answer. I'll improve the branch as much as possible before the
 deadline.

 > Additionally (though not necessarily for the deadline) I would suggest
 adding a comment for each key mentioning which keyboard layout each key
 came from. (All previous keys came from the US keyboard.) Once the
 annotations are added, it would be prudent to have another review to
 carefully check each of the mappings to make sure they are correct.

 Yes, agreed. I'll add these as I make changes, but there will likely be
 some that will need updating after the deadline.

 >
 > Could you also comment here for the record on AltGr vs Alt vs AltLeft?
 Is AltGr they expected modifier in KeyboardEvents from most modern
 keyboards? It doesn't seem to appear on my Mac, if I recall correctly.

 Complicated. On Windows, it seems AltGr (AltRight) is converted into two
 distinct keydown KeyboardEvents, one for key='Alt' and keyCode='AltRight'
 and a second event with key='Control' and keyCode='CtrlLeft', while in
 Gnome I see key='AltGraph' and keyCode='AltRight'. The Wikipedia page
 [WIKIALTGR] says the Option key on a Mac keyboard is similar, but I don't
 have a Mac availbale for testing so unfortunately I don't know how that
 translates into KeyEvents in the browser when using different keyboard
 layouts.

 [WIKIALTGR] https://en.wikipedia.org/wiki/AltGr_key

 >
 > > The patch falls back on code "IntlBackslash" and keycode 220, when a
 mapping does not exist for a key. Something unfortunate/annoying I found
 while working on this is that unicode provides more than one code for the
 same glyph (such as U+0110 (capital letter D with stroke) and U+00D0
 (capital letter eth) for Ð), so I am worried some keyboard
 drivers/platforms use different codes for characters that are visually the
 same, thus this patch may result in slightly strange behavior.
 >
 > I guess we can't do anything about that confusion, correct? Do you think
 it would somewhat to block the key codes or match them for those
 doppelganger characters?
 >

 I think it's better if every character codepoint is mapped to a key per
 language/locale. I was considering mapping all doppelgangers to the same
 key, but after our discussion this seems like the wrong behavior. Every
 doppelganger is coupled with a specific set of languages, if we add an
 explicit mapping for a character then it should be relative to that
 language. So, in the case of 'Ð', we can map U+0110 with (letter D with
 stroke) respect to its location on a Slovic keyboard, and we can map
 U+00D0 (letter Eth) to its location on the Norwegian or Finnish keyboard.

 > > The key-to-code mappings were decided by taking the results of the
 survey and choosing the most common keyboard key per character/symbol.
 There were many symbols that were in a unique location on different
 layouts, so I chose a key that seemed reasonable.
 >
 > That's an interesting shell one-liner. Could you post the instructions
 on what it does and how to reproduce it for future work? :)

 I'm adjusting the mappings so they are based on the locale that is most
 likely to use a key rather than mapping it based on the most common key
 used for that character across all the keyboard layouts. So, this one-
 liners, which counts the number of times a key is mapped to a specific
 location on the keyboard (used the file att

Re: [tor-bugs] #23170 [Core Tor/Tor]: Include ed25519 relay id keys in the consensus

[Tor Bug Tracker & Wiki]

#23170: Include ed25519 relay id keys in the consensus
-+-
 Reporter:  asn  |  Owner:  nickm
 Type:  task | Status:
 |  accepted
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224 tor-dirauth tor-hs ed25519   |  Actual Points:
  needs-proposal |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-

Comment (by arma):

 Hopefully useful thoughts:

 A) Is the only reason we need ed keys in the consensus for this hashring
 thing? That seems like a sad reason to put in all the overhead for every
 client for every hour forever.

 A2) And if that is the only use, we could put like 4 characters of the key
 in, as just a hashring hint?

 B) Is there a longer term plan for phasing out rsa keys entirely, and
 replacing them with ed keys? If not, maybe prop224 hashring should use rsa
 keys.

 C) Maybe the consensus overhead isn't so bad because of consensus diffs.
 Or maybe it is? Has anybody done any follow-up on the consensus diff
 deployment to see what effect it has had?

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

Re: [tor-bugs] #23170 [Core Tor/Tor]: Include ed25519 relay id keys in the consensus

[Tor Bug Tracker & Wiki]

#23170: Include ed25519 relay id keys in the consensus
-+-
 Reporter:  asn  |  Owner:  nickm
 Type:  task | Status:
 |  accepted
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224 tor-dirauth tor-hs ed25519   |  Actual Points:
  needs-proposal |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-
Changes (by dgoulet):

 * priority:  Medium => Very High


Comment:

 This "missing descriptors, waiting to download" problem is starting to be
 much more of an issue in terms of user experience and reachability. 032
 works fine but sometimes those delays are inevitable which we've seen gone
 up to 10 minutes.

 This would simplify massively everything and could be deploy as soon as
 0.3.3.

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

Re: [tor-bugs] #23621 [Core Tor/Tor]: prop224: Missing tons of mds over time with a lurking client

[Tor Bug Tracker & Wiki]

#23621: prop224: Missing tons of mds over time with a lurking client
--+
 Reporter:  asn   |  Owner:  dgoulet
 Type:  defect| Status:  needs_revision
 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   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_information => needs_revision


Comment:

 After discussing this with armadev on IRC, a possible avenue to try to fix
 this is investigate why it can take us up to 10 minutes to get up to min
 dirinfo?

 This ties into the global problem that prop224 needs a huge chunk of the
 total descriptors to function properly...

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

Re: [tor-bugs] #8001 [Core Tor/Tor]: obfsproxy makes tor warn when one bridge is down

[Tor Bug Tracker & Wiki]

#8001: obfsproxy makes tor warn when one bridge is down
-+-
 Reporter:  arma |  Owner:  isis
 Type:  defect   | Status:
 |  assigned
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, tor-bridge, tor-pt,  |  Actual Points:
  logging easy   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorS-can
-+-

Comment (by arma):

 Replying to [comment:15 nickm]:

 Nick added the keyword easy, but asn noted "implementation-wise, this does
 not look like a trivial change". I think asn is right. We need to put
 flags on each bridge about whether it's been tried and failed, and do a
 warn when the last one gets the flag set.

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

Re: [tor-bugs] #9516 [Applications/Tor Launcher]: Show Tor log in TorBrowser

[Tor Bug Tracker & Wiki]

#9516: Show Tor log in TorBrowser
---+---
 Reporter:  bastik |  Owner:  brade
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Blocker| Resolution:
 Keywords:  tbb-usability  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * severity:   => Blocker


Comment:

 One case where this would be helpful: In #22730, a smart user had a
 warning about a bogus torrc option, but apparently didn't see it, and
 therefore thought that Tor hadn't given them a warning at all.

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

Re: [tor-bugs] #22730 [Core Tor/Tor]: Restricting exit nodes in torrc fails silently

[Tor Bug Tracker & Wiki]

#22730: Restricting exit nodes in torrc fails silently
--+
 Reporter:  saint |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Closing as worksforme, and see #9516 for the usability issue in TB, but
 please reopen if I'm wrong about any of 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] #22355 [Core Tor/Tor]: Update dir-spec with client fallback directory mirror attempt and timeout behaviour

[Tor Bug Tracker & Wiki]

#22355: Update dir-spec with client fallback directory mirror attempt and 
timeout
behaviour
+
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-spec, spec  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+
Changes (by catalyst):

 * cc: catalyst (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] #14633 [Applications/Tor Browser]: Default NoScript settings says "Allow Scripts Globally" is "dangerous"

[Tor Bug Tracker & Wiki]

#14633: Default NoScript settings says "Allow Scripts Globally" is "dangerous"
+--
 Reporter:  arthuredelstein |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Blocker | Resolution:
 Keywords:  tbb-usability uxsprint2015  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by cypherpunks):

 * severity:   => Blocker


Comment:

 Replying to [comment:6 intrigeri]:
 > Once the security slider controls the global NoScript behavior, maybe
 NoScript's own "Allow scripts globally" UI should simply be hidden instead
 of rephrased? Or did I miss a usecase for this button?

 Yes, see here:
 https://trac.torproject.org/projects/tor/ticket/22985#comment:3

 This doesn't apply if the proposed solution there is implemented, in which
 case hiding NoScript may be a great idea.

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

Re: [tor-bugs] #23397 [Applications/Tor Browser]: NoScript is totally broken in the way it handles URLs (with e.g. https:// inside)

[Tor Bug Tracker & Wiki]

#23397: NoScript is totally broken in the way it handles URLs (with e.g. 
https://
inside)
---+--
 Reporter:  cypherpunks|  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-security-slider, noscript  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 Relevant noscript.net forum thread:
 https://forums.informaction.com/viewtopic.php?f=10&t=23274

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

Re: [tor-bugs] #21311 [Core Tor/Tor]: Exits should resolve IPv6 addresses, regardless of IPv6Exit

[Tor Bug Tracker & Wiki]

#21311: Exits should resolve IPv6 addresses, regardless of IPv6Exit
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, 031-deferred-20170425  |  Actual Points:  0.1
Parent ID:  #17811   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.3.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] #16678 [Applications/Tor Browser]: Enhance KeyboardEvent fingerprinting protection for unusual characters

[Tor Bug Tracker & Wiki]

#16678: Enhance KeyboardEvent fingerprinting protection for unusual characters
-+-
 Reporter:  arthuredelstein  |  Owner:  sysrqb
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting,  |  Actual Points:
  TorBrowserTeam201709   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  tbb-fingerprinting, TorBrowserTeam201709R => tbb-
 fingerprinting, TorBrowserTeam201709
 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:10 sysrqb]:
 > I surveyed the different layouts shown on the QWERTY [0], QWERTZ [1],
 and AZERTY [2] pages on Wikipedia, and I documented (roughly) the
 different keys (attached). From this, the patch [3] contains 131 unicode
 characters, covering most Latin charset-based keyboard layouts.

 Thank you for the patch. I think this is a significant enhancement to our
 previous patch. I wrote some comments and suggested revisions on the
 github commit at
 https://github.com/sysrqb/tor-
 browser/commit/52b021674c6885d30e851557b14a8d70b5702a75#diff-
 8e201eb85e7d7abe2bb6b78e12c5081aR411

 Additionally (though not necessarily for the deadline) I would suggest
 adding a comment for each key mentioning which keyboard layout each key
 came from. (All previous keys came from the US keyboard.) Once the
 annotations are added, it would be prudent to have another review to
 carefully check each of the mappings to make sure they are correct.

 Could you also comment here for the record on AltGr vs Alt vs AltLeft? Is
 AltGr they expected modifier in KeyboardEvents from most modern keyboards?
 It doesn't seem to appear on my Mac, if I recall correctly.

 > The patch falls back on code "IntlBackslash" and keycode 220, when a
 mapping does not exist for a key. Something unfortunate/annoying I found
 while working on this is that unicode provides more than one code for the
 same glyph (such as U+0110 (capital letter D with stroke) and U+00D0
 (capital letter eth) for Ð), so I am worried some keyboard
 drivers/platforms use different codes for characters that are visually the
 same, thus this patch may result in slightly strange behavior.

 I guess we can't do anything about that confusion, correct? Do you think
 it would somewhat to block the key codes or match them for those
 doppelganger characters?

 > The key-to-code mappings were decided by taking the results of the
 survey and choosing the most common keyboard key per character/symbol.
 There were many symbols that were in a unique location on different
 layouts, so I chose a key that seemed reasonable.
 >
 > {{{
 > $ sort -t, -k 3 unicode_keyboard_keys | sed 's/, /,/g' | awk -F, '{
 print $3", "$2", "$5; }' | sort | uniq -c | less
 > }}}

 That's an interesting shell one-liner. Could you post the instructions on
 what it does and how to reproduce it for future work? :)

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

Re: [tor-bugs] #22605 [Core Tor/Tor]: sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.d/

[Tor Bug Tracker & Wiki]

#22605: sandbox_intern_string(): Bug: No interned sandbox parameter found for
/etc/tor/torrc.d/
-+-
 Reporter:  toralf   |  Owner:  dgoulet
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, regression, review- |  Actual Points:
  group-23   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 Ok, I think this lgtm. Thanks Jigsaw52!

 Nick, you want to keep that for 031... I mean the stable has been
 released? What about early merge 033?

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

Re: [tor-bugs] #23159 [Core Tor/Tor]: Bug: Non-fatal assertion ei failed in launch_intro_point_circuits at src/or/hs_service.c:1784

[Tor Bug Tracker & Wiki]

#23159: Bug: Non-fatal assertion ei failed in launch_intro_point_circuits at
src/or/hs_service.c:1784
-+
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+

Comment (by dgoulet):

 We aren't running it on the testnet and it was actually triggered on the
 real network.

 We've been running a custom patch with many more asserts() to catch this
 and since 12 days ago, still nothing. I'm optimistic.

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

Re: [tor-bugs] #23207 [Internal Services/Service - trac]: Registration on trac seems to be counterintuitive

[Tor Bug Tracker & Wiki]

#23207: Registration on trac seems to be counterintuitive
--+--
 Reporter:  mail@…|  Owner:  qbi
 Type:  enhancement   | Status:  reopened
 Priority:  Very Low  |  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 Seems like it's not working as expected again...

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

Re: [tor-bugs] #23159 [Core Tor/Tor]: Bug: Non-fatal assertion ei failed in launch_intro_point_circuits at src/or/hs_service.c:1784

[Tor Bug Tracker & Wiki]

#23159: Bug: Non-fatal assertion ei failed in launch_intro_point_circuits at
src/or/hs_service.c:1784
-+
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 Is it appropriate to merge that in 0.3.2 if it doesn't trigger on your
 testnet?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23649 [Applications/Tor Browser]: Adapt the design of the Tor Launcher, Torbutton, ...etc and even the about:tor page to the new Firefox Photon UX

[Tor Bug Tracker & Wiki]

#23649: Adapt the design of the Tor Launcher, Torbutton, ...etc and even the
about:tor page to the new Firefox Photon UX
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ux-team, ff59-esr
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 Photon UX guidelines are available here  http://design.firefox.com/photon/
 e.g.

 * colors:  http://design.firefox.com/photon/visual/color.html
 * fonts: http://design.firefox.com/photon/visual/typography.html

 ...etc

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

Re: [tor-bugs] #23253 [Core Tor/Tor]: BridgeAuth goes offline when it has an expired ed25519_signing_cert

[Tor Bug Tracker & Wiki]

#23253: BridgeAuth goes offline when it has an expired ed25519_signing_cert
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  not a
 Keywords:  tor-bridgeauth, tor-dirauth, tor-|  bug
  ed25519-keys   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorM-can
-+-
Changes (by nickm):

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


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

Re: [tor-bugs] #22771 [Core Tor/Tor]: Determine Rust support levels for our targeted platforms

[Tor Bug Tracker & Wiki]

#22771: Determine Rust support levels for our targeted platforms
+
 Reporter:  isis|  Owner:  (none)
 Type:  task| Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  worksforme
 Keywords:  rust, SponsorZ  |  Actual Points:
Parent ID:  | Points:  .5
 Reviewer:  |Sponsor:  SponsorZ
+
Changes (by nickm):

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


Comment:

 It seems we took this as far as it can go.  In summary: rust seems to work
 anecdotally approximately everywhere that we work anecdotally, and to work
 testedly where we work testedly.

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

Re: [tor-bugs] #23603 [Core Tor/Tor]: hs: Cleanup race between circuit close and free with the HS circuitmap

[Tor Bug Tracker & Wiki]

#23603: hs: Cleanup race between circuit close and free with the HS circuitmap
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 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|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  accepted => needs_review


Comment:

 See branch `bug23603_032_01` for the cleanup fix.

 I haven't touched the `circuit_retries` counter here, I'll document the
 issue in a ticket 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] #23648 [Applications/Tor Browser]: I get this error on duckduckgo when using this exit node "8175A86D8896CEA37FDC67311F9BDC1DDCBE8136"

[Tor Bug Tracker & Wiki]

#23648: I get this error on duckduckgo when using this exit node
"8175A86D8896CEA37FDC67311F9BDC1DDCBE8136"
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 This isn't Tor Project's fault, contact them at the address they gave you
 so that hopefully it gets 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

[tor-bugs] #23648 [Applications/Tor Browser]: I get this error on duckduckgo when using this exit node "8175A86D8896CEA37FDC67311F9BDC1DDCBE8136"

[Tor Bug Tracker & Wiki]

#23648: I get this error on duckduckgo when using this exit node
"8175A86D8896CEA37FDC67311F9BDC1DDCBE8136"
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 I keep geting this error on duckduckgo when using this exit node.
 "We've detected that you have connected over Tor. There appears to be an
 issue with the Tor Exit Node you are currently using. Please recreate your
 Tor circuit or restart your Tor browser in order to fix this. If this
 error persists, please let us know: error-lite-...@duckduckgo.com"
 TorBrowser 7.0.5
 exit node
 "8175A86D8896CEA37FDC67311F9BDC1DDCBE8136"

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

Re: [tor-bugs] #23228 [Applications/Tor Browser]: Build a Windows 64 toolchain based on mingw-w64

[Tor Bug Tracker & Wiki]

#23228: Build a Windows 64 toolchain based on mingw-w64
---+---
 Reporter:  boklm  |  Owner:  tbb-team
 Type:  task   | Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201709  |  Actual Points:
Parent ID:  #20636 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 We could fix ld, if you wish.

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

Re: [tor-bugs] #23643 [Core Tor/Tor]: Type-check struct members that are passed to confparse

[Tor Bug Tracker & Wiki]

#23643: Type-check struct members that are passed to confparse
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  catalyst  |Sponsor:
--+

Comment (by catalyst):

 Something like this?

 {{{
 union dummyaddrs {
 char **a_str;
 int *a_int;
 double *a_double;
 const char **a_cstr;
 };

 typedef struct {
 const char *name;
 int typenum;
 union dummyaddrs _;
 } config_var_t;

 typedef struct {
 char *foostr;
 int fooint;
 const char *foocstr;
 } some_opts;

 #define optline(name, tnum, checktype) \
 { #name, tnum, { .checktype = &opts0.name } }

 static some_opts opts0;

 config_var_t cvars[];

 config_var_t cvars[] = {
 optline(fooint, 0, a_int),
 optline(foostr, 0, a_str),
 optline(foocstr, 0, a_cstr),
 };
 }}}

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

Re: [tor-bugs] #23645 [Core Tor/Tor]: hs: Continue to improve logging in both HS and circuit subsystems

[Tor Bug Tracker & Wiki]

#23645: hs: Continue to improve logging in both HS and circuit subsystems
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, tor-circuit, logging  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  assigned => needs_review


Comment:

 See branch: `ticket23645_032_01`.

 That `n_circ_id` and `globale_identifier` needs to be a pair in the logs
 so we can match from allocation to freeing it correctly else it's a
 guessing game.

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

Re: [tor-bugs] #7707 [Core Tor/Tor]: Impose a minimum write size for TLS writes

[Tor Bug Tracker & Wiki]

#7707: Impose a minimum write size for TLS writes
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, performance, bwbug,   |  Actual Points:
  bandwidth sponsor8-maybe tls nagle,|
  032-unreached  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by nickm):

 * keywords:  tor-relay, performance, bwbug, bandwidth sponsor8-maybe tls
 nagle =>
 tor-relay, performance, bwbug, bandwidth sponsor8-maybe tls nagle,
 032-unreached
 * milestone:  Tor: 0.3.2.x-final => Tor: unspecified


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

Re: [tor-bugs] #23647 [Applications/Tor Browser]: Indicator to show Security Slider level at a glance (maybe on Tor Button icon?)

[Tor Bug Tracker & Wiki]

#23647: Indicator to show Security Slider level at a glance (maybe on Tor Button
icon?)
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  Security Slider,  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * Attachment "sec_setting_indicator.png" added.

 Mock up example of indicator

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23647 [Applications/Tor Browser]: Indicator to show Security Slider level at a glance (maybe on Tor Button icon?)

[Tor Bug Tracker & Wiki]

#23647: Indicator to show Security Slider level at a glance (maybe on Tor Button
icon?)
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  Security Slider,
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 As changes to the security slider are persistent across re-launches of
 TorBrowser could we get an indicator that displays what the current
 security slider level is?
 Its tedious to have navigate to the security slider settings every time to
 check especially if you change this setting a lot for different sites.


 I mocked up some examples where the the TorButton color changes from green
 to yellow to red? Perhaps red, yellow green is too dramatic?

 Maybe something more sublte might be to vary the saturation of the green
 color on the Tor button? Brighter green = higher security.
 Or maybe a small letter beside the TorButton? Or a combination of both? or
 something else entirely?

 It would be helpful to see at a glance what level the Security Slider is
 set to.

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

Re: [tor-bugs] #23643 [Core Tor/Tor]: Type-check struct members that are passed to confparse

[Tor Bug Tracker & Wiki]

#23643: Type-check struct members that are passed to confparse
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  catalyst  |Sponsor:
--+

Comment (by nickm):

 I'm not sure I quite understand what you're suggesting; could you sketch
 out what it would look like a little?

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

Re: [tor-bugs] #23646 [Applications/Tor Browser]: Undefined References to Panning functions (for Tom Ritter)

[Tor Bug Tracker & Wiki]

#23646: Undefined References to Panning functions (for Tom Ritter)
--+--
 Reporter:  cypherpunks   |  Owner:  tom
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  new => assigned
 * owner:  (none) => tom
 * component:  - Select a component => Applications/Tor Browser


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

Re: [tor-bugs] #23643 [Core Tor/Tor]: Type-check struct members that are passed to confparse

[Tor Bug Tracker & Wiki]

#23643: Type-check struct members that are passed to confparse
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  catalyst  |Sponsor:
--+

Comment (by catalyst):

 Oh, a close reading of C99 §6.6 does imply that could be a problem.
 Address constants should be OK, though, so making `var_type_dummy` an
 instance of a union of pointers to all possible types and using named
 member assignment with the address of the member of the static object
 might work?

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

Re: [tor-bugs] #23643 [Core Tor/Tor]: Type-check struct members that are passed to confparse

[Tor Bug Tracker & Wiki]

#23643: Type-check struct members that are passed to confparse
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  catalyst  |Sponsor:
--+

Comment (by nickm):

 > Instead of using a null pointer, use the address of a static object of
 the appropriate type. We presumably don't care too much about the extra
 memory footprint if we're building test code.

 Hm. This part might be harder to do.  When I try to do this approach, I
 get an error: "initializer element is not computable at load time".
 Apparently comparing the addresses of members of two static objects is not
 something I can stick into an initializer?

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

Re: [tor-bugs] #8557 [Applications/Tor Browser]: Audit and possibly enable safebrowsing

[Tor Bug Tracker & Wiki]

#8557: Audit and possibly enable safebrowsing
-+--
 Reporter:  mikeperry|  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-pref, tbb-firefox-patch  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by fmarier):

 * severity:  Blocker => Normal


Comment:

 Looks like I accidentally changed the priority while adding comment 9.

 Not sure what the original priority was so I'll just reset it to normal.

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

Re: [tor-bugs] #8557 [Applications/Tor Browser]: Audit and possibly enable safebrowsing

[Tor Bug Tracker & Wiki]

#8557: Audit and possibly enable safebrowsing
-+--
 Reporter:  mikeperry|  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Blocker  | Resolution:
 Keywords:  tbb-pref, tbb-firefox-patch  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by groovecoder):

 * cc: luke.crouch@… (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] #23322 [Applications/Tor Browser]: HTTPS Everywhere Import Settings is Missing From Preferences (was: HTTPS Everywhere Preferences has visible File Upload)

[Tor Bug Tracker & Wiki]

#23322: HTTPS Everywhere Import Settings is Missing From Preferences
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * owner:  (none) => tbb-team
 * component:  HTTPS Everywhere => Applications/Tor Browser


Comment:

 In Firefox there is an "Import Settings" heading and Import button that
 are missing in TBB.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23646 [- Select a component]: Undefined References to Panning functions (for Tom Ritter)

[Tor Bug Tracker & Wiki]

#23646: Undefined References to Panning functions (for Tom Ritter)
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 This is https://bugzilla.mozilla.org/show_bug.cgi?id=1402385.
 The reason is https://bugzilla.mozilla.org/show_bug.cgi?id=1391164.
 Now C functions are called as C++ (without `extern "C"`).

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

Re: [tor-bugs] #23636 [Applications/rbm]: can not 'upload' build system rbm fedora

[Tor Bug Tracker & Wiki]

#23636: can not 'upload' build system rbm fedora
---+---
 Reporter:  fedora0penchaos@…  |  Owner:  boklm
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/rbm   |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by fedora0penchaos@…):

 this is the log:
 git submodule update --init
 ./rbm/rbm build release --target release --target torbrowser-all
 Building project tor-browser - tor-browser-7.5a5-linux-x86_64-a44f4d
 Building project container-image - container-image_wheezy-
 amd64-df3a332e7b34.tar.gz
 Building project debootstrap-image - container-image_wheezy-amd64.tar.gz
 Using file $TRB/out/debootstrap-image/container-image_ubuntu-base-17.04
 -base-amd64.tar.gz
 [sudo] password for <$USER>:
 prebuildpost#!/bin/sh
 set -e
 apt-get update -y
 apt-get install -y debian-archive-keyring ubuntu-keyring debootstrap
 debootstrap --arch=amd64  wheezy base-image
 tar -C ./base-image -czf $TRB/sudo runc run -b $TRB/tmp/rbm-uhDAX2/rbm-
 containers/872251921cd201d05ce140da2d87aa3024a3ba62e86440714f89a6dc1ac0f662
 rbm-872251921cd201d05ce140da2d87aa3024a3ba62e86440714f89a6dc1ac0f662
 /container-image_wheezy-amd64.tar.gz .

 #!/bin/sh
 set -e
 # Doing nothing

 Build log: $TRB/logs/debootstrap-image-.log
 sudo runc run -b $TRB/tmp/rbm-uhDAX2/rbm-
 containers/872251921cd201d05ce140da2d87aa3024a3ba62e86440714f89a6dc1ac0f662
 rbm-872251921cd201d05ce140da2d87aa3024a3ba62e86440714f89a6dc1ac0f662
 Error: Error uploading container-image_ubuntu-base-17.04-base-amd64.tar.gz
 make: *** [Makefile:6: release] Error 1

 END OF THE LOG
 I replaced my path to the directory I invoked make release with $TRB
 also I let the rbm program output some scripts before executing

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

Re: [tor-bugs] #23643 [Core Tor/Tor]: Type-check struct members that are passed to confparse

[Tor Bug Tracker & Wiki]

#23643: Type-check struct members that are passed to confparse
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  catalyst  |Sponsor:
--+

Comment (by catalyst):

 Suggestions:

 * Instead of using a null pointer, use the address of a static object of
 the appropriate type.  We presumably don't care too much about the extra
 memory footprint if we're building test code.
 * Use an equality operator instead of pointer subtraction.  The equality
 operators (with both operands being pointers) have the same constraints
 about type compatibility as subtraction, but don't have the requirement
 that both pointers point to members of the same array.

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

Re: [tor-bugs] #23636 [Applications/rbm]: can not 'upload' build system rbm fedora

[Tor Bug Tracker & Wiki]

#23636: can not 'upload' build system rbm fedora
---+---
 Reporter:  fedora0penchaos@…  |  Owner:  boklm
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/rbm   |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by boklm):

 Yes, the text on the console after running the make command to start the
 build.

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

Re: [tor-bugs] #23636 [Applications/rbm]: can not 'upload' build system rbm fedora

[Tor Bug Tracker & Wiki]

#23636: can not 'upload' build system rbm fedora
---+---
 Reporter:  fedora0penchaos@…  |  Owner:  boklm
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/rbm   |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by fedora0penchaos@…):

 I did use d972152
 the text I see on the console?

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

Re: [tor-bugs] #23636 [Applications/rbm]: can not 'upload' build system rbm fedora

[Tor Bug Tracker & Wiki]

#23636: can not 'upload' build system rbm fedora
---+---
 Reporter:  fedora0penchaos@…  |  Owner:  boklm
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/rbm   |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by boklm):

 Could you paste the full logs you have before the error when you try to do
 a build?

 Also, which `tor-browser-build.git` commit have you been using?

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

Re: [tor-bugs] #7176 [Core Tor/Tor]: Adapt and update AccessLabs' patches for reduced Tor memory consumption for embedded devices (was: Adapt and update AccessLabs' patches for reduced TOR memory cons

[Tor Bug Tracker & Wiki]

#7176: Adapt and update AccessLabs' patches for reduced Tor memory consumption 
for
embedded devices
-+-
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, embedded, low-memory,|  Actual Points:
  sponsor8-maybe |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

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

Re: [tor-bugs] #23643 [Core Tor/Tor]: Type-check struct members that are passed to confparse

[Tor Bug Tracker & Wiki]

#23643: Type-check struct members that are passed to confparse
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  catalyst  |Sponsor:
--+
Changes (by catalyst):

 * status:  needs_review => needs_revision
 * reviewer:   => catalyst


Comment:

 This is a nifty idea.

 I'm trying to analyze the standards conformance aspects of it.  Doing
 pointer arithmetic on a null pointer isn't a great idea (and probably non-
 conforming; `offsetof()` is allowed to do that because it's part of the
 implementation).  Also pointer subtraction has to be between members of
 the same array (or a fictitious member one past the end), so subtracting a
 pointer to a member from a pointer to a member of an included structure
 doesn't work.

 I think it can be salvaged in a standards-conforming way, but I'll have to
 think about it a bit.

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

Re: [tor-bugs] #16678 [Applications/Tor Browser]: Enhance KeyboardEvent fingerprinting protection for unusual characters

[Tor Bug Tracker & Wiki]

#16678: Enhance KeyboardEvent fingerprinting protection for unusual characters
-+-
 Reporter:  arthuredelstein  |  Owner:  sysrqb
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting,  |  Actual Points:
  TorBrowserTeam201709R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 https://github.com/sysrqb/tor-browser/tree/bug16678_1a now contains a
 commit that uses the constant values defined by nsIDOMKeyEvent
 (dom/interfaces/events/nsIDOMKeyEvent.idl) and replaces the existing magic
 numbers. Unfortunately, this touches nearly every line in
 dom/events/KeyCodeConsensus.h, so the code review will be a little
 tedious.

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

Re: [tor-bugs] #23092 [Core Tor/Tor]: Stop ignoring CircuitIdleTimeout when it's lower than IDLE_TIMEOUT_WHILE_LEARNING

[Tor Bug Tracker & Wiki]

#23092: Stop ignoring CircuitIdleTimeout when it's lower than
IDLE_TIMEOUT_WHILE_LEARNING
--+
 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.2.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 I think this is okay. Could you add a changes file, and maybe a comment?

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

Re: [tor-bugs] #22109 [Core Tor/Tor]: Test that own version passes directory authority checks

[Tor Bug Tracker & Wiki]

#22109: Test that own version passes directory authority checks
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Thanks! 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] #22109 [Core Tor/Tor]: Test that own version passes directory authority checks

[Tor Bug Tracker & Wiki]

#22109: Test that own version passes directory authority checks
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Looks good to me!

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

Re: [tor-bugs] #21404 [Applications/Quality Assurance and Testing]: Run the Tor Browser testsuite on rbm based nightly builds

[Tor Bug Tracker & Wiki]

#21404: Run the Tor Browser testsuite on rbm based nightly builds
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201709 |  Actual Points:
Parent ID:  #17379   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * keywords:   => TorBrowserTeam201709


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

Re: [tor-bugs] #23603 [Core Tor/Tor]: hs: Cleanup race between circuit close and free with the HS circuitmap

[Tor Bug Tracker & Wiki]

#23603: hs: Cleanup race between circuit close and free with the HS circuitmap
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  accepted
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by asn):

 Agreed on only doing cleanup in `cleanup_intro_points()`.

 Not sure about the `circuit_retries` counter situation. A real hibernation
 callback is probably not easy to do in a cross-platform way, and resetting
 the retries count is a recipe for guard discovery attacks. However, IIUC
 this bug is not as impotant as the cleanup 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

[tor-bugs] #23645 [Core Tor/Tor]: hs: Continue to improve logging in both HS and circuit subsystems

[Tor Bug Tracker & Wiki]

#23645: hs: Continue to improve logging in both HS and circuit subsystems
--+--
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs, tor-circuit, logging
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Having #23604 merged has already paid off big time.

 This ticket is about going for a second iteration on improving logging
 overall with circuits and hidden service.

 There are actually two bugs with #23604 (nothing serious) so this ticket
 will also address it.

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

Re: [tor-bugs] #23603 [Core Tor/Tor]: hs: Cleanup race between circuit close and free with the HS circuitmap

[Tor Bug Tracker & Wiki]

#23603: hs: Cleanup race between circuit close and free with the HS circuitmap
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  accepted
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * owner:  (none) => dgoulet
 * status:  new => accepted


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

Re: [tor-bugs] #23603 [Core Tor/Tor]: hs: Cleanup race between circuit close and free with the HS circuitmap

[Tor Bug Tracker & Wiki]

#23603: hs: Cleanup race between circuit close and free with the HS circuitmap
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Ok, those latest logs were enlightening and 99.9% certainty now :)

 The offending function is `hs_service_intro_circ_has_closed()` called in
 `circuit_about_to_free()`.

 Same scenario has above but just simpler for the sake of the example:

 1. mark for close intro circuits
 2. launch new ones to same intro points.
 3. `about_to_free()` the circuits in step (1).
  --> This calls `has_closed()` which removes the intro point object if it
 has been retried too many times.
 4. New circuit opens, boom no intro point object and we get the warning of
 `Unknown auth key...`.

 From asn's log, which suspend/wakeup many times his tor, we happen to try
 intro points many times (successfully) and in their 18h-24h lifetime, it
 was done more than 3 times which triggered this condition in the has
 closed function:

 {{{
   if (ip->circuit_retries > MAX_INTRO_POINT_CIRCUIT_RETRIES) {
 remember_failing_intro_point(ip, desc, approx_time());
 service_intro_point_remove(service, ip);
 service_intro_point_free(ip);
 }}}

 This can only happen if the service launch the new circuits *before* the
 free() of the previous circuits happens *and* the circuit retry counter
 has reached > 3.

 Couple of possible fixes here. First, we should NOT clean anything in that
 function. We should ONLY do that in `cleanup_intro_points()` which would
 have cleanup everything properly (circuit included). For this, we need to
 move the "remember failing intro point" logic in there in case we've tried
 too many times.

 Second, this `circuit_retries` counter should probably not be incremented
 when we just go out of hibernation and `tor` is assuming at that point
 that all circuits are not working. We either do a callback from
 hibernation into the HS subsystem to cleanup those counters or another
 possible option would be to reset to 0 the counter on a successful intro
 point establishment.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23644 [Applications/Quality Assurance and Testing]: Fix the https-everywhere test in Tor Browser testsuite

[Tor Bug Tracker & Wiki]

#23644: Fix the https-everywhere test in Tor Browser testsuite
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance   |Version:
  and Testing|   Keywords:
 Severity:  Normal   |  TorBrowserTeam201709
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 In the Tor Browser test suite, we have an https-everywhere test that is
 checking that the URL http://www.freedomboxfoundation.org/thanks/ is
 redirected to its https version when https-everywhere is enabled.

 However https-everywhere rules have been updated to add
 `platform="mixedcontent"` to this host, which make it disabled by default:
 https://github.com/EFForg/https-everywhere/pull/11438

 We should update the test to use an other URL for checking that https-
 everywhere is working.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  High   |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.6
 Severity:  Normal | Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID: | Points:  1.5
 Reviewer: |Sponsor:  SponsorU
---+---
Changes (by asn):

 * status:  assigned => needs_information
 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.3.x-final


Comment:

 Deferring this to 0.3.3 since we are getting less instances of this these
 days. Let's reexamine when we learn more info.

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

Re: [tor-bugs] #23551 [Core Tor/Tor]: src/common/compress.c:576: tor_compress_process: Non-fatal assertion

[Tor Bug Tracker & Wiki]

#23551: src/common/compress.c:576: tor_compress_process: Non-fatal assertion
+
 Reporter:  cypherpunks |  Owner:  ahf
 Type:  defect  | Status:  assigned
 Priority:  High|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.1.5-alpha
 Severity:  Normal  | Resolution:
 Keywords:  0.3.2.2-alpha-must  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

 * keywords:   => 0.3.2.2-alpha-must


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

Re: [tor-bugs] #23630 [Applications/Tor Browser]: Clarify README.HACKING

[Tor Bug Tracker & Wiki]

#23630: Clarify README.HACKING
+--
 Reporter:  tom |  Owner:  tbb-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201709R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by boklm):

 * keywords:  tbb-rbm => tbb-rbm, TorBrowserTeam201709R
 * status:  new => needs_review


Comment:

 The branch `bug_23630` has a patch that should clarify the README.HACKING
 file:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_23630&id=dd09e0d57edc1017c5f2b158b0b19e8ab25220d9

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

Re: [tor-bugs] #23642 [Applications/Tor Browser]: Tor Browser has stopped working

[Tor Bug Tracker & Wiki]

#23642: Tor Browser has stopped working
--+---
 Reporter:  paul@…|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 Try the workaround mentioned in #8337,

 > Workaround: Stop Trusteer, run TBB, start Trusteer again when done.

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

Re: [tor-bugs] #8337 [Applications/Tor Browser]: Trusteer crashes Tor Browser

[Tor Bug Tracker & Wiki]

#8337: Trusteer crashes Tor Browser
--+
 Reporter:  mo|  Owner:  mikeperry
 Type:  defect| Status:
  |  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash,  tbb-7.0-frequent  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Recent duplicate: #23642

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

Re: [tor-bugs] #23643 [Core Tor/Tor]: Type-check struct members that are passed to confparse

[Tor Bug Tracker & Wiki]

#23643: Type-check struct members that are passed to confparse
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 I have a neat hack that does this; Using it, I found a few mistyped values
 in or_config_t, or_state_t, and sr_disk_state_t.  Those appear to be
 harmless.

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

Re: [tor-bugs] #23643 [Core Tor/Tor]: Type-check struct members that are passed to confparse

[Tor Bug Tracker & Wiki]

#23643: Type-check struct members that are passed to confparse
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 Please review branch `typecheck2`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23643 [Core Tor/Tor]: Type-check struct members that are passed to confparse

[Tor Bug Tracker & Wiki]

#23643: Type-check struct members that are passed to confparse
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+


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

Re: [tor-bugs] #23643 [Core Tor/Tor]: Type-check struct members that are passed to confparse

[Tor Bug Tracker & Wiki]

#23643: Type-check struct members that are passed to confparse
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:  (none) => nickm
 * status:  new => accepted


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

Re: [tor-bugs] #23539 [Core Tor/Tor]: We've defined "don't use kist" as a negative interval, so don't check for -1

[Tor Bug Tracker & Wiki]

#23539: We've defined "don't use kist" as a negative interval, so don't check 
for
-1
-+
 Reporter:  pastly   |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-sched, easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  pastly   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 merged! let's keep an eye on jenkins for 32-bit errors

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

Re: [tor-bugs] #23642 [Applications/Tor Browser]: Tor Browser has stopped working

[Tor Bug Tracker & Wiki]

#23642: Tor Browser has stopped working
--+---
 Reporter:  paul@…|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

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


Comment:

 Duplicate of #8337

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

Re: [tor-bugs] #23539 [Core Tor/Tor]: We've defined "don't use kist" as a negative interval, so don't check for -1

[Tor Bug Tracker & Wiki]

#23539: We've defined "don't use kist" as a negative interval, so don't check 
for
-1
-+
 Reporter:  pastly   |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  pastly   |Sponsor:
-+

Comment (by pastly):

 Updated my branch making it an int; initialized `sched_run_interval` with
 `KIST_SCHED_RUN_INTERVAL_DEFAULT` instead of just 10.

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

Re: [tor-bugs] #23642 [Applications/Tor Browser]: Tor Browser has stopped working

[Tor Bug Tracker & Wiki]

#23642: Tor Browser has stopped working
--+--
 Reporter:  paul@…|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * keywords:   => tbb-crash
 * owner:  (none) => tbb-team
 * component:  - Select a component => Applications/Tor Browser


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

Re: [tor-bugs] #23642 [- Select a component]: Tor Browser has stopped working

[Tor Bug Tracker & Wiki]

#23642: Tor Browser has stopped working
--+
 Reporter:  paul@…|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by paul@…):

 I reinstalled Mozilla FireFox and tried both stable and beta or install
 for windows 64 bit

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

Re: [tor-bugs] #23539 [Core Tor/Tor]: We've defined "don't use kist" as a negative interval, so don't check for -1

[Tor Bug Tracker & Wiki]

#23539: We've defined "don't use kist" as a negative interval, so don't check 
for
-1
-+
 Reporter:  pastly   |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  pastly   |Sponsor:
-+

Comment (by nickm):

 problem here -- INTERVAL types in the configuration _must_ be `int` in the
 options.  I bet this has caused somebody a problem somewhere.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23642 [- Select a component]: Tor Browser has stopped working

[Tor Bug Tracker & Wiki]

#23642: Tor Browser has stopped working
--+
 Reporter:  paul@…|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Problem signature:
   Problem Event Name:   APPCRASH
   Application Name: firefox.exe
   Application Version:  52.3.0.6242
   Application Timestamp:
   Fault Module Name:KERNELBASE.dll
   Fault Module Version: 6.1.7601.23889
   Fault Module Timestamp:   598d4d26
   Exception Code:   c06d007f
   Exception Offset: c54f
   OS Version:   6.1.7601.2.1.0.256.48
   Locale ID:2057
   Additional Information 1: 0a9e
   Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
   Additional Information 3: 0a9e
   Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

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

Re: [tor-bugs] #23539 [Core Tor/Tor]: We've defined "don't use kist" as a negative interval, so don't check for -1

[Tor Bug Tracker & Wiki]

#23539: We've defined "don't use kist" as a negative interval, so don't check 
for
-1
-+
 Reporter:  pastly   |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  pastly   |Sponsor:
-+

Comment (by pastly):

 Looks good. I did

 - Change KISTSchedRunInterval from int32_t to uint32_t
 - Lint the changes file
 - Minor comment/log message changes

 See bug23539_032_01 on my gitweb.

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

Re: [tor-bugs] #23420 [Core Tor/Tor]: prop224: Pad RENDEZVOUS1 cell to match legacy cell length

[Tor Bug Tracker & Wiki]

#23420: prop224: Pad RENDEZVOUS1 cell to match legacy cell length
+--
 Reporter:  asn |  Owner:  dgoulet
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  implemented
 Keywords:  prop224, prop224-extra, tor-hs  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

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


Comment:

 lgtm; tests pass.  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