Re: [tor-bugs] #20482 [Internal Services/Tor Sysadmin Team]: Please make a ldap account for Silvia

[Tor Bug Tracker & Wiki]

#20482: Please make a ldap account for Silvia
-+
 Reporter:  isabela  |  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


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

Re: [tor-bugs] #20496 [Applications/Tor Browser]: Website causes tor to become unresponsive.

[Tor Bug Tracker & Wiki]

#20496: Website causes tor to become unresponsive.
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * owner:   => 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] #20496 [Applications/Tor Browser]: Website causes tor to become unresponsive.

[Tor Bug Tracker & Wiki]

#20496: Website causes tor to become unresponsive.
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * status:  new => assigned
 * keywords:   => tbb-crash


Comment:

 After doing duty cycles during being unresponsive (w/o detecting
 unresponsive scripts) and showing something like "RIP TOR luv u" at the
 end, TBB has exited itself with all opened tabs. Nice.
 (TBB latest stable :) on Medium-High)
 (Why did that guy disclose such wonderful old features of FF?)

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

Re: [tor-bugs] #18319 [Core Tor/Tor]: Exclude relays that don't match pinned RSA/Ed key pairs

[Tor Bug Tracker & Wiki]

#18319: Exclude relays that don't match pinned RSA/Ed key pairs
-+-
 Reporter:  teor |  Owner:  andrea
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ed25519-proto, nickm-|  Actual Points:
  deferred-20160905  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorU-can
-+-

Comment (by teor):

 I suggest that we email these operators (or these operators filtered by
 some characteristic, like "bandwidth over 1MByte/second"), and let them
 know their relay is misconfigured, and they will soon be excluded from the
 consensus.

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

Re: [tor-bugs] #20284 [Core Tor/Tor]: consensus weight case 2b3 does not follow dir-spec

[Tor Bug Tracker & Wiki]

#20284: consensus weight case 2b3 does not follow dir-spec
-+
 Reporter:  pastly   |  Owner:  pastly
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-11  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 I am concerned that we are turning off the unit tests for
 networkstatus_compute_bw_weights_v10 for consensus methods < 27, when we
 will continue to use consensus methods < 27 in the live network for some
 time to come.

 I suggest that you run the unit test at least twice: once for a consensus
 method < 27, and another for >= 27. You could use the arg parameter to
 test_dir_networkstatus_compute_bw_weights_v10 to do this.

 There is a passthrough setup method you can add to the unit test table at
 the end of the file. It will let you declare two tests that run the same
 function, and pass them different values for the argument.

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

Re: [tor-bugs] #18319 [Core Tor/Tor]: Exclude relays that don't match pinned RSA/Ed key pairs

[Tor Bug Tracker & Wiki]

#18319: Exclude relays that don't match pinned RSA/Ed key pairs
-+-
 Reporter:  teor |  Owner:  andrea
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ed25519-proto, nickm-|  Actual Points:
  deferred-20160905  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorU-can
-+-

Comment (by Sebastian):

 One of these is a dirauth (dizum). How will this all work, by the way? My
 key pinning journal goes back one year and has more entries than what is
 written above, including more than just the dirauth above.

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

Re: [tor-bugs] #18319 [Core Tor/Tor]: Exclude relays that don't match pinned RSA/Ed key pairs

[Tor Bug Tracker & Wiki]

#18319: Exclude relays that don't match pinned RSA/Ed key pairs
-+-
 Reporter:  teor |  Owner:  andrea
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ed25519-proto, nickm-|  Actual Points:
  deferred-20160905  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorU-can
-+-

Comment (by Sebastian):

 Should we maybe throw away all the journals and email those above anyway,
 informing them that they would be excluded in the future if they kept
 doing 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] #10681 [Applications/Tor Browser]: New Identity may temporarily leak state

[Tor Bug Tracker & Wiki]

#10681: New Identity may temporarily leak state
+--
 Reporter:  mikeperry   |  Owner:  tbb-team
 Type:  defect  | Status:  closed
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Blocker | Resolution:  fixed
 Keywords:  tbb-linkability, tbb-torbutton  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by fem):

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


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

Re: [tor-bugs] #10681 [Applications/Tor Browser]: New Identity may temporarily leak state

[Tor Bug Tracker & Wiki]

#10681: New Identity may temporarily leak state
+--
 Reporter:  mikeperry   |  Owner:  tbb-team
 Type:  defect  | Status:  closed
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-linkability, tbb-torbutton  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by fem):

 * severity:  Blocker => Normal


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

Re: [tor-bugs] #18873 [Core Tor/Tor]: Refactor circuit_predict_and_launch_new()

[Tor Bug Tracker & Wiki]

#18873: Refactor circuit_predict_and_launch_new()
--+
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  refactoring   |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+

Comment (by chelseakomlo):

 Thanks for these notes- I agree on all of these. I'll submit these changes
 here today.

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

Re: [tor-bugs] #18080 [Applications/Tor Browser]: Firefox bug - CORS header 'Access-Control-Allow-Origin' missing

[Tor Bug Tracker & Wiki]

#18080: Firefox bug - CORS header 'Access-Control-Allow-Origin' missing
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by bugzilla):

 Replying to [comment:8 gk]:
 > That said, while testing I did not encounter the "Cross-Origin Request
 Blocked:"-message.
 When redirect in comment:11 transforms into an endless loop, maybe,
 because of #18222, the message isn't shown in Console too. But it appears
 only once in the loop after clicking Clear, and 403 Forbidden isn't shown
 at all after it, probably, because of #19921. So, this all looks like
 previous craziness of Torbutton.

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

Re: [tor-bugs] #18222 [Applications/Tor Browser]: Tor Browser sets different Guard for one of the tabs when goes crazy (was: Circuit visualizer shows different Guard for one of the tabs!)

[Tor Bug Tracker & Wiki]

#18222: Tor Browser sets different Guard for one of the tabs when goes crazy
--+--
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bugzilla):

 Takes part in ticket:18080#comment:14.

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

Re: [tor-bugs] #19969 [Core Tor/Tor]: tor client does not immediately open new circuits after standby

[Tor Bug Tracker & Wiki]

#19969: tor client does not immediately open new circuits after standby
--+
 Reporter:  weasel|  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.6
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by arma):

 * points:   => 2


Comment:

 Ok, I spent a while investigating this ticket yesterday. For context, the
 Tor client on my travel laptop is still stuck in this bug, so I can poke
 it in various ways to help debug if we think of useful ways. Here is a
 checkpoint of my thinking process.

 There are two mysteries here:

 Mystery 1) Why does my Tor client not care to get any new directory
 information?

 It's October 29 now, and my tor's datadirectory contains:
 {{{
 -rw---  1 arma arma 1405537 Oct 21 12:14 cached-microdesc-consensus
 -rw---  1 arma arma 3473955 Oct 21 12:43 cached-microdescs
 -rw---  1 arma arma   0 Oct 21 12:43 cached-microdescs.new
 }}}
 After one of the clock jump events, my Tor tried to fetch a consensus from
 a relay in the fallbackdir list, then it fell back to trying to fetch a
 consensus from each of the directory authorities, and when one attempt
 failed for each of those, it seems to have permanently given up -- and
 that was days ago. I'm going to leave this mystery for later -- somebody
 please feel free to pick it up in the meantime.

 Mystery 2) Why does my Tor client not recognize the new application
 (socks) requests and jumpstart itself into trying to fetch new directory
 stuff, make new circuits, and so on?

 My investigations led me to be suspicious of Tor commit {{{b1d56fc58}}}.

 Background: in the past a new socks request would come in, and
 {{{connection_ap_handshake_rewrite_and_attach()}}} would get called on it,
 which would call {{{connection_ap_handshake_attach_circuit()}}}, which
 would call {{{circuit_get_open_circ_or_launch()}}}, and that function is
 the one that does the "omg I don't have enough directory information and I
 just got a socks request, I should reset everything so we can try again"
 logic.

 But in commit {{{b1d56fc58}}}, we made
 {{{connection_ap_handshake_rewrite_and_attach()}}} no longer attach it,
 but rather it now calls {{{connection_ap_mark_as_pending_circuit()}}},
 which effectively queues the stream for handling the next time the main
 loop runs. That function adds the stream to the
 {{{pending_entry_connections}}} smartlist, and sets
 {{{untried_pending_connections}}} to 1, and returns.

 Then {{{run_main_loop_once()}}} calls
 {{{connection_ap_attach_pending(0)}}}, which goes through and calls
 {{{connection_ap_handshake_attach_circuit()}}} on each stream that needs
 it.

 But when I gdb attach to my unhappy Tor client and set a breakpoint on
 {{{connection_ap_attach_pending}}} and then do a new socks request, it
 seems that it never calls the function!

 The earlier parts of {{{connection_ap_handshake_rewrite_and_attach()}}}
 *are* being called, for example {{{rep_hist_note_used_port()}}} gets
 called just fine. So I think the stream is being added to
 {{{pending_entry_connections}}}, and then somehow things aren't working
 after that.

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

Re: [tor-bugs] #20476 [Core Tor/Stem]: stem exit policy tests fail on master

[Tor Bug Tracker & Wiki]

#20476: stem exit policy tests fail on master
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Thanks teor! Actually, unit tests are Stem testing itself (tor changes
 don't impact them). The integ tests are what exercise tor.

 Took a little head scratching but found the issue. Thanks for the catch!

 https://gitweb.torproject.org/stem.git/commit/?id=3cf6949

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

Re: [tor-bugs] #18873 [Core Tor/Tor]: Refactor circuit_predict_and_launch_new()

[Tor Bug Tracker & Wiki]

#18873: Refactor circuit_predict_and_launch_new()
--+
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  refactoring   |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+

Comment (by chelseakomlo):

 Ok, so here are the updates from teor's review. I couldn't think of how to
 extract add_flags in a clean way, so I kept this as it was before the
 refactor. I also added the recommended defines.

 See branch `circuituse`, `g...@github.com:chelseakomlo/tor_patches.git`

 I added a separate commit for the refactor to remove the check for
 CIRCUIT_IS_ORIGIN in circuit_is_available_for_use. The refactor is because
 we first check the purpose of the circuit to see if it is an origin
 circuit, but then we later reject all cicuits that do not have the purpose
 CIRCUIT_PURPOSE_C_GENERAL.

 We shouldn't need to use the BUG macro because
 circuit_is_available_for_use should be able to accept both origin and non-
 origin circuits, and silently return if the circuit's purpose is not
 CIRCUIT_PURPOSE_C_GENERAL (which I believe also entails that it is an
 origin circuit).

 `#define CIRCUIT_PURPOSE_IS_ORIGIN(p) ((p)>CIRCUIT_PURPOSE_OR_MAX_)`
 `#define CIRCUIT_PURPOSE_OR_MAX_ 4`
 `#define CIRCUIT_PURPOSE_C_GENERAL 5`

 If this is the case, we shouldn't be able to crash in TO_ORIGIN_CIRCUIT()
 as all circuits that reach this point will have the purpose
 CIRCUIT_PURPOSE_C_GENERAL and therefore (I think) are origin circuits.

 Let me know what you think!

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

Re: [tor-bugs] #20477 [Core Tor/Stem]: stem cwd tests fail on macOS Sierra

[Tor Bug Tracker & Wiki]

#20477: stem cwd tests fail on macOS Sierra
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Interesting! Stem's cwd util certainly should work on OSX. Iirc pwdx isn't
 present but lsof should work. What do you get when you run the following?

 {{{
 % pwdx [tor_pid]
 % lsof -a -p [tor_pid] -d cwd -Fn
 }}}

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

Re: [tor-bugs] #19680 [Core Tor/Stem]: Pep8 renamed to pycodestyle

[Tor Bug Tracker & Wiki]

#19680: Pep8 renamed to pycodestyle
---+-
 Reporter:  atagar |  Owner:  atagar
 Type:  enhancement| Status:  closed
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  | Resolution:  implemented
 Keywords:  testing, easy  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by atagar):

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


Comment:

 Thanks neel! Pushed with a few small changes to fix our testing
 configuration and provide backward compatibility.

 Patch is much appreciated!

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

Re: [tor-bugs] #20493 [Core Tor/Stem]: Stem Documentation Wrong?

[Tor Bug Tracker & Wiki]

#20493: Stem Documentation Wrong?
---+
 Reporter:  tom|  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Thanks Tom! Took a quick peek at the
 [https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2012 spec]
 and you're right.
 [https://gitweb.torproject.org/stem.git/commit/?id=aec24a2 Pushed a fix],
 feel free to reopen if there's any other issues.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20497 [Applications/Tor Browser]: Add --enable-tor-browser-data-in-home-dir configure option and code

[Tor Bug Tracker & Wiki]

#20497: Add --enable-tor-browser-data-in-home-dir configure option and code
--+--
 Reporter:  attila|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  TBB
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 The attached patch adds a new configure option called `--enable-tor-
 browser-data-in-home-dir` and code to honor it.

 This is effectively a special case of `--enable-tor-browser-data-outside-
 app-dir`.  I developed this patch for the port of TBB to
 [http://www.openbsd.org OpenBSD] because we need to solve the problem of
 where the `TorBrowser-Data` directory goes.  Under Linux it lives in the
 bundle.  On Win/Mac there are canonical places for it to go.  Under
 OpenBSD (and the other BSDs, at least), the logical place is the user's
 home directory, so I added this option and use it in
 [https://github.com/torbsd/openbsd-ports/blob/master/www/tbb/tor-
 browser/Makefile my port's Makefile].

 After discussion on `#tor-dev` I'm proposing this as a new feature to make
 it easier for other BSD/non-MacWinLin porting efforts.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20498 [Obfuscation/BridgeDB]: bridgedb's key is expired?

[Tor Bug Tracker & Wiki]

#20498: bridgedb's key is expired?
--+--
 Reporter:  arma  |  Owner:  isis
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 https://bridges.torproject.org/keys
 shows an expiration date of {{{2015-09-11}}}.

 Is there a newer key? Is this key used for signing or encrypting or
 something bridgedb responses?

 (I don't have a gmail or yahoo or riseup account so I can't, or at least
 don't know how to, get bridgedb to respond to me in any way, to confirm
 whether it's really using this key for something.)

 Reported by a user on #tor who said "The Public key is expired for the
 bridge emailer, can whoever is incharge update the key pair please."

 Thanks!

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

Re: [tor-bugs] #18873 [Core Tor/Tor]: Refactor circuit_predict_and_launch_new()

[Tor Bug Tracker & Wiki]

#18873: Refactor circuit_predict_and_launch_new()
--+
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  refactoring   |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+

Comment (by teor):

 Replying to [comment:8 chelseakomlo]:
 > ...
 > I added a separate commit for the refactor to remove the check for
 CIRCUIT_IS_ORIGIN in circuit_is_available_for_use. The refactor is because
 we first check the purpose of the circuit to see if it is an origin
 circuit, but then we later reject all cicuits that do not have the purpose
 CIRCUIT_PURPOSE_C_GENERAL.
 >
 > We shouldn't need to use the BUG macro because
 circuit_is_available_for_use should be able to accept both origin and non-
 origin circuits, and silently return if the circuit's purpose is not
 CIRCUIT_PURPOSE_C_GENERAL (which I believe also entails that it is an
 origin circuit).
 >
 > `#define CIRCUIT_PURPOSE_IS_ORIGIN(p) ((p)>CIRCUIT_PURPOSE_OR_MAX_)`
 > `#define CIRCUIT_PURPOSE_OR_MAX_ 4`
 > `#define CIRCUIT_PURPOSE_C_GENERAL 5`
 >
 > If this is the case, we shouldn't be able to crash in
 TO_ORIGIN_CIRCUIT() as all circuits that reach this point will have the
 purpose CIRCUIT_PURPOSE_C_GENERAL and therefore (I think) are origin
 circuits.

 I think you are confusing CIRCUIT_PURPOSE_IS_ORIGIN() and
 CIRCUIT_IS_ORIGIN().

 And while I agree that is the current logic, I have seen too many cases
 like this where calling code breaks an assumption, and then the called
 code crashes.

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

Re: [tor-bugs] #20284 [Core Tor/Tor]: consensus weight case 2b3 does not follow dir-spec

[Tor Bug Tracker & Wiki]

#20284: consensus weight case 2b3 does not follow dir-spec
-+
 Reporter:  pastly   |  Owner:  pastly
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-11  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by teor):

 Also, let's make sure we include a unit test case where the output is
 different before and after this change. We don't appear to have one at the
 moment.

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

Re: [tor-bugs] #20414 [Applications/Tor Browser]: Donation banner on about:tor page for 2016 campaign

[Tor Bug Tracker & Wiki]

#20414: Donation banner on about:tor page for 2016 campaign
-+-
 Reporter:  arthuredelstein  |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201610R, crowdfunding  |  Actual Points:
Parent ID:  #20413   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Replying to [comment:5 mcs]:
 > Replying to [comment:3 arthuredelstein]:
 > > I'm working on the banner, and it's getting there, but it still needs
 some polishing. In the meantime, here are the strings (for review) we are
 going to use for the banner text. (This text was suggested by Shari, with
 minor revisions.) If these strings look OK, I would like to get these
 added to the repository ASAP so we can give the translators a chance to do
 the translation ahead of our deadline for the next release.
 > >
 > > https://github.com/arthuredelstein/torbutton/commit/20414+2
 >
 > The strings look okay to me. I am old school, so I would capitalize
 Internet... but I suspect that is not something the cool kids do these
 days.

 At the risk of losing my Cool Kid status, I think I prefer it capitalized
 as well. Here's my new version:

 https://github.com/arthuredelstein/torbutton/commit/20414+4

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

Re: [tor-bugs] #20477 [Core Tor/Stem]: stem cwd tests fail on macOS Sierra

[Tor Bug Tracker & Wiki]

#20477: stem cwd tests fail on macOS Sierra
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by teor):

 {{{
 $ lsof -a -p 92599 -d cwd -Fn
 p92599
 fcwd
 n/Users/twilsonb
 }}}

 Where the 3rd line shows the correct cwd.

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

Re: [tor-bugs] #20477 [Core Tor/Stem]: stem cwd tests fail on macOS Sierra

[Tor Bug Tracker & Wiki]

#20477: stem cwd tests fail on macOS Sierra
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by teor):

 (pwdx does not exist)

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

Re: [tor-bugs] #18873 [Core Tor/Tor]: Refactor circuit_predict_and_launch_new()

[Tor Bug Tracker & Wiki]

#18873: Refactor circuit_predict_and_launch_new()
--+
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  refactoring   |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+

Comment (by teor):

 Replying to [comment:9 teor]:
 > Replying to [comment:8 chelseakomlo]:
 > > ...
 > > I added a separate commit for the refactor to remove the check for
 CIRCUIT_IS_ORIGIN in circuit_is_available_for_use. The refactor is because
 we first check the purpose of the circuit to see if it is an origin
 circuit, but then we later reject all cicuits that do not have the purpose
 CIRCUIT_PURPOSE_C_GENERAL.
 > >
 > > We shouldn't need to use the BUG macro because
 circuit_is_available_for_use should be able to accept both origin and non-
 origin circuits, and silently return if the circuit's purpose is not
 CIRCUIT_PURPOSE_C_GENERAL (which I believe also entails that it is an
 origin circuit).
 > >
 > > `#define CIRCUIT_PURPOSE_IS_ORIGIN(p) ((p)>CIRCUIT_PURPOSE_OR_MAX_)`
 > > `#define CIRCUIT_PURPOSE_OR_MAX_ 4`
 > > `#define CIRCUIT_PURPOSE_C_GENERAL 5`
 > >
 > > If this is the case, we shouldn't be able to crash in
 TO_ORIGIN_CIRCUIT() as all circuits that reach this point will have the
 purpose CIRCUIT_PURPOSE_C_GENERAL and therefore (I think) are origin
 circuits.
 >
 > I think you are confusing CIRCUIT_PURPOSE_IS_ORIGIN() and
 CIRCUIT_IS_ORIGIN().

 Oops, no, I am confusing them:

 CIRCUIT_PURPOSE_IS_ORIGIN() and CIRCUIT_IS_ORIGIN() are equivalent - one
 tests the purpose itself, the other tests the circuit.

 But TO_ORIGIN_CIRCUIT does `tor_assert(x->magic ==
 ORIGIN_CIRCUIT_MAGIC);`, and does not check the purpose. So it is not
 equivalent to either of those other macros.

 > And while I agree that is the current logic, I have seen too many cases
 like this where calling code breaks an assumption, and then the called
 code crashes.

 In particular, the assumption that if a circuit satisfies `purpose ==
 CIRCUIT_PURPOSE_C_GENERAL`, it will also have the right magic number.

 But in the end, I think you're right, because assert_circuit_ok() checks
 that invariant. So we can skip that check.

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

Re: [tor-bugs] #19969 [Core Tor/Tor]: tor client does not immediately open new circuits after standby

[Tor Bug Tracker & Wiki]

#19969: tor client does not immediately open new circuits after standby
--+
 Reporter:  weasel|  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.6
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:10 arma]:
 > Ok, I spent a while investigating this ticket yesterday. For context,
 the Tor client on my travel laptop is still stuck in this bug, so I can
 poke it in various ways to help debug if we think of useful ways. Here is
 a checkpoint of my thinking process.
 >
 > There are two mysteries here:
 >
 > Mystery 1) Why does my Tor client not care to get any new directory
 information?
 >
 > It's October 29 now, and my tor's datadirectory contains:
 > {{{
 > -rw---  1 arma arma 1405537 Oct 21 12:14 cached-microdesc-consensus
 > -rw---  1 arma arma 3473955 Oct 21 12:43 cached-microdescs
 > -rw---  1 arma arma   0 Oct 21 12:43 cached-microdescs.new
 > }}}
 > After one of the clock jump events, my Tor tried to fetch a consensus
 from a relay in the fallbackdir list, then it fell back to trying to fetch
 a consensus from each of the directory authorities, and when one attempt
 failed for each of those, it seems to have permanently given up -- and
 that was days ago. I'm going to leave this mystery for later -- somebody
 please feel free to pick it up in the meantime.

 This sounds like an issue with the consensus download implementation. Here
 are my questions:
 * has your tor has marked each of the directory authorities down?
 * has it marked all of the fallback directories down?
 * has it exceeded the download schedule for downloading consensuses?

 There are two kinds of download_status_t in 0.2.8, one retries on a
 schedule regardless of success or failure, and the other retries on
 failure. It seems there might be a problem with the first kind (which is
 new in 0.2.8, and used to download the consensus).

 I'd like to know what your consensus download_status_t has for all its
 fields, particularly the attempt and failure counts. It may well have
 exceeded the 255 failure count limit.

 I also wonder how #8625 (commit 09a0f2d) affects this, but it is only in
 0.2.9, and I'm not sure it would make it any better.

 > Mystery 2) Why does my Tor client not recognize the new application
 (socks) requests and jumpstart itself into trying to fetch new directory
 stuff, make new circuits, and so on?
 >
 > My investigations led me to be suspicious of Tor commit {{{b1d56fc58}}}.
 >
 > Background: in the past a new socks request would come in, and
 {{{connection_ap_handshake_rewrite_and_attach()}}} would get called on it,
 which would call {{{connection_ap_handshake_attach_circuit()}}}, which
 would call {{{circuit_get_open_circ_or_launch()}}}, and that function is
 the one that does the "omg I don't have enough directory information and I
 just got a socks request, I should reset everything so we can try again"
 logic.
 >
 > But in commit {{{b1d56fc58}}}, we made
 {{{connection_ap_handshake_rewrite_and_attach()}}} no longer attach it,
 but rather it now calls {{{connection_ap_mark_as_pending_circuit()}}},
 which effectively queues the stream for handling the next time the main
 loop runs. That function adds the stream to the
 {{{pending_entry_connections}}} smartlist, and sets
 {{{untried_pending_connections}}} to 1, and returns.
 >
 > Then {{{run_main_loop_once()}}} calls
 {{{connection_ap_attach_pending(0)}}}, which goes through and calls
 {{{connection_ap_handshake_attach_circuit()}}} on each stream that needs
 it.
 >
 > But when I gdb attach to my unhappy Tor client and set a breakpoint on
 {{{connection_ap_attach_pending}}} and then do a new socks request, it
 seems that it never calls the function!
 >
 > The earlier parts of {{{connection_ap_handshake_rewrite_and_attach()}}}
 *are* being called, for example {{{rep_hist_note_used_port()}}} gets
 called just fine. So I think the stream is being added to
 {{{pending_entry_connections}}}, and then somehow things aren't working
 after that.

 This might be related to the above bug, or it might not be.
 This code would need to reset the authority and fallback failures, and
 also the download status for the consensus.

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

Re: [tor-bugs] #20497 [Applications/Tor Browser]: Add --enable-tor-browser-data-in-home-dir configure option and code

[Tor Bug Tracker & Wiki]

#20497: Add --enable-tor-browser-data-in-home-dir configure option and code
--+--
 Reporter:  attila|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TBB   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yawning):

 nb: Not really a Tor Browser developer, though I sometimes play one on tv.

 While this is sort of a Linux-ism, any thoughts on using XDG Base
 Directories (https://specifications.freedesktop.org/basedir-spec/basedir-
 spec-latest.html).  In this case something like
 `$XDG_DATA_HOME//`, with a default of `~/.local/share/` if the env
 var isn't set (`~/.local/share/tor-browser/` for example).

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

Re: [tor-bugs] #20477 [Core Tor/Stem]: stem cwd tests fail on macOS Sierra

[Tor Bug Tracker & Wiki]

#20477: stem cwd tests fail on macOS Sierra
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Thanks!
 
[https://gitweb.torproject.org/stem.git/commit/?id=dc9b874bdc8bcf5556ba8a03e98beb50221fae41
 Fix pushed], feel free to reopen if that doesn't do the trick.

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