Re: [tor-bugs] #22377 [Core Tor/Tor]: Rip out AUTHDIR_NEWDESCS event?

[Tor Bug Tracker & Wiki]

#22377: Rip out AUTHDIR_NEWDESCS event?
--+
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 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 teor):

 Replying to [comment:1 arma]:
 > (Maybe the test network, or chutney, would still enjoy having it
 though?)

 If I were testing relay descriptor checks in chutney, I'd want 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] #22371 [Core Tor/Tor]: Always send AUTHDIR_NEWDESC events in response to new descriptors

[Tor Bug Tracker & Wiki]

#22371: Always send AUTHDIR_NEWDESC events in response to new descriptors
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  030-backport-maybe, 029-backport-|  Actual Points:  0.2
  maybe  |
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 I don't object to fixing this one.

 But see also #22377 for the now-competing proposal. :)

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

Re: [tor-bugs] #22377 [Core Tor/Tor]: Rip out AUTHDIR_NEWDESCS event?

[Tor Bug Tracker & Wiki]

#22377: Rip out AUTHDIR_NEWDESCS event?
--+
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 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 arma):

 (Maybe the test network, or chutney, would still enjoy having it 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

[tor-bugs] #22377 [Core Tor/Tor]: Rip out AUTHDIR_NEWDESCS event?

[Tor Bug Tracker & Wiki]

#22377: Rip out AUTHDIR_NEWDESCS event?
--+
 Reporter:  arma  |  Owner:
 Type:  enhancement   | 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:|
--+
 I vaguely remember that weasel added this feature back when the directory
 authorities were running the Naming scripts?

 Now all of those scripts are gone.

 I don't know of any directory authorities who run with their control port
 open now.

 Maybe this is a great time to just get rid of it?

 Motivated by the bug in #22371.

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

Re: [tor-bugs] #22349 [Core Tor/Tor]: dir auth attempts to fetch a descriptor every minute for every relay with mismatched rsa/ed key

[Tor Bug Tracker & Wiki]

#22349: dir auth attempts to fetch a descriptor every minute for every relay 
with
mismatched rsa/ed key
+--
 Reporter:  arma|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.0.7
 Severity:  Normal  | Resolution:
 Keywords:  029-backport, 030-backport  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by teor):

 * keywords:   => 029-backport, 030-backport
 * milestone:   => Tor: 0.3.1.x-final


Comment:

 I think this is something we should fix in 0.3.1, and then backport to
 0.2.9.

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

Re: [tor-bugs] #22348 [Core Tor/Tor]: 16 relays have mismatched rsa/ed keys currently

[Tor Bug Tracker & Wiki]

#22348: 16 relays have mismatched rsa/ed keys currently
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * milestone:   => Tor: 0.3.1.x-final


Comment:

 We need to do this before a majority of authorities key pin, which means
 the 0.3.1 timeframe.

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

Re: [tor-bugs] #21926 [Core Tor/Tor]: Still had 1 address policies cached at shutdown

[Tor Bug Tracker & Wiki]

#21926: Still had 1 address policies cached at shutdown
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.6
 Severity:  Minor | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arma):

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


Comment:

 Closing since #22370 looks like the root cause.

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

Re: [tor-bugs] #22370 [Core Tor/Tor]: Stop leaking routerinfos that are rejected due to keypinning

[Tor Bug Tracker & Wiki]

#22370: Stop leaking routerinfos that are rejected due to keypinning
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.2-alpha
 Severity:  Major| Resolution:  fixed
 Keywords:  memory-leak, 029-backport,   |  Actual Points:  0.1
  030-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:3 arma]:
 > Looks like the cause of #21926 perhaps?

 Yes! I think #21926 is resolved now.

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

Re: [tor-bugs] #22368 [Core Tor/Tor]: double-free of MyFamily lines

[Tor Bug Tracker & Wiki]

#22368: double-free of MyFamily lines
+--
 Reporter:  arma|  Owner:
 Type:  defect  | Status:
|  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.1.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  regression memory-safety tor-relay  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arma):

 Here are two fun log lines from the relay when it triggered:
 {{{
 May 24 20:52:30.264 [warn] There is a router named  in my declared
 family, but that isn't a legal nickname. Skipping it.
 May 24 20:52:30.462 [warn] There is a router named ""\340\254U\013"" in my
 declared family, but that isn't a legal nickname. Skipping 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] #22368 [Core Tor/Tor]: double-free of MyFamily lines

[Tor Bug Tracker & Wiki]

#22368: double-free of MyFamily lines
+--
 Reporter:  arma|  Owner:
 Type:  defect  | Status:
|  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.1.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  regression memory-safety tor-relay  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 Replying to [comment:7 arma]:
 > Speaking of just about anything, it is distantly possible that relays
 who hit this bug will print little pieces of arbitrary memory, if they are
 valid nicknames or hexes, into the Family line of their descriptor. Good
 times.

 Since the smallest valid nickname is 1 character, it discloses 1 byte with
 probability 62/256, 2 bytes with probability (62/256)^2, ...

 Unless it needs to be a valid continuation of a nickname list?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22376 [Core Tor/Chutney]: Make the chutney README less scary

[Tor Bug Tracker & Wiki]

#22376: Make the chutney README less scary
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Chutney works decently well now.
 We should edit the README intro to reflect 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

[tor-bugs] #22375 [Core Tor/Stem]: Can tor-prompt optionally wait for tor to start on a port, rather than failing straight away?

[Tor Bug Tracker & Wiki]

#22375: Can tor-prompt optionally wait for tor to start on a port, rather than
failing straight away?
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 When I start a chutney network and want to run tor-prompt on it, I have to
 wait until the relays are running before I start tor-prompt.

 It would be nicer to just start tor-prompt, and have it tell me when the
 relays are up.

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

Re: [tor-bugs] #22368 [Core Tor/Tor]: double-free of MyFamily lines

[Tor Bug Tracker & Wiki]

#22368: double-free of MyFamily lines
+--
 Reporter:  arma|  Owner:
 Type:  defect  | Status:
|  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.1.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  regression memory-safety tor-relay  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arma):

 Speaking of just about anything, it is distantly possible that relays who
 hit this bug will print little pieces of arbitrary memory, if they are
 valid nicknames or hexes, into the Family line of their descriptor. Good
 times.

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

Re: [tor-bugs] #22368 [Core Tor/Tor]: double-free of MyFamily lines

[Tor Bug Tracker & Wiki]

#22368: double-free of MyFamily lines
+--
 Reporter:  arma|  Owner:
 Type:  defect  | Status:
|  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.1.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  regression memory-safety tor-relay  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arma):

 Replying to [ticket:22368 arma]:
 > ==33656== Invalid read of size 8
 > ==33656==at 0x58E41E1: EVP_MD_CTX_cleanup (in /lib/x86_64-linux-
 gnu/libcrypto.so.1.0.0)
 >[...]
 > Once we've resolved this ticket, we should take a closer look at that
 last "Invalid read of size 8" stanza, and open a new ticket for it if
 needed.

 I think this weird stack trace is a side effect of the bug. I got another
 trace, when I was triggering the bug on my relay, that looked like this:
 {{{
 ==35332== Invalid read of size 1
 ==35332==at 0x198624: is_legal_nickname_or_hexdigest (router.c:3419)
 ==35332==by 0x19CAFA: router_build_fresh_descriptor (router.c:2296)
 ==35332==by 0x19CD47: router_rebuild_descriptor (router.c:2445)
 ==35332==by 0x19CF1E: router_get_my_routerinfo (router.c:2013)
 ==35332==by 0x19DEF4: check_descriptor_ipaddress_changed
 (router.c:2589)
 ==35332==by 0x1528E1: check_descriptor_callback (main.c:1878)
 ==35332==by 0x171BFF: periodic_event_dispatch (periodic.c:52)
 ==35332==by 0x2EA12F: event_process_active_single_queue (in
 /home/tord/git/src/or/tor)
 ==35332==by 0x2EA6FF: event_process_active (in
 /home/tord/git/src/or/tor)
 ==35332==by 0x2EAE63: event_base_loop (in /home/tord/git/src/or/tor)
 ==35332==by 0x154C81: do_main_loop (main.c:2594)
 ==35332==by 0x155DA4: tor_main (main.c:3745)
 ==35332==  Address 0x72fd640 is 0 bytes inside a block of size 8 free'd
 ==35332==at 0x4A06430: free (vg_replace_malloc.c:446)
 ==35332==by 0x5594E1C: CRYPTO_free (in /usr/lib64/libcrypto.so.1.0.1e)
 ==35332==by 0x55D17C1: bn_expand2 (in /usr/lib64/libcrypto.so.1.0.1e)
 ==35332==by 0x55CE702: BN_div (in /usr/lib64/libcrypto.so.1.0.1e)
 ==35332==by 0x55D42C6: BN_nnmod (in /usr/lib64/libcrypto.so.1.0.1e)
 ==35332==by 0x55D728E: BN_mod_inverse (in
 /usr/lib64/libcrypto.so.1.0.1e)
 ==35332==by 0x55DE366: BN_MONT_CTX_set (in
 /usr/lib64/libcrypto.so.1.0.1e)
 ==35332==by 0x55DE5AF: BN_MONT_CTX_set_locked (in
 /usr/lib64/libcrypto.so.1.0.1e)
 ==35332==by 0x55EF6FA: ??? (in /usr/lib64/libcrypto.so.1.0.1e)
 ==35332==by 0x55F1879: int_rsa_verify (in
 /usr/lib64/libcrypto.so.1.0.1e)
 ==35332==by 0x55F1C38: RSA_verify (in /usr/lib64/libcrypto.so.1.0.1e)
 ==35332==by 0x55F62DB: ??? (in /usr/lib64/libcrypto.so.1.0.1e)
 }}}

 So I think "once you start freeing memory and then using it again, just
 about anything could happen" is the right explanation for that other stack
 trace.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22374 [Core Tor/Stem]: tor-prompt should handle /events even after tor has died

[Tor Bug Tracker & Wiki]

#22374: tor-prompt should handle /events even after tor has died
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 I set up a chutney network using:
 {{{
 }}}

 Then ran tor-prompt using:
 {{{
 ./tor-prompt -i 8000
 }}}

 Then issued:
 {{{
 SETEVENTS AUTHDIR_NEWDESCS
 }}}

 When chutney finishes, it kills the tor instances it started.

 And then I tried to get the events from tor-prompt:
 {{{
 /events
 }}}

 But it quit, probably because tor had died.

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

Re: [tor-bugs] #22370 [Core Tor/Tor]: Stop leaking routerinfos that are rejected due to keypinning

[Tor Bug Tracker & Wiki]

#22370: Stop leaking routerinfos that are rejected due to keypinning
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.2-alpha
 Severity:  Major| Resolution:  fixed
 Keywords:  memory-leak, 029-backport,   |  Actual Points:  0.1
  030-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by arma):

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


Comment:

 I have merged, to 0.2.9 and up.

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

Re: [tor-bugs] #22373 [Core Tor/Chutney]: Add LogTimeGranularity 1 to chutney logs

[Tor Bug Tracker & Wiki]

#22373: Add LogTimeGranularity 1 to chutney logs
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:  0.1
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * type:  defect => enhancement


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

Re: [tor-bugs] #22373 [Core Tor/Chutney]: Add LogTimeGranularity 1 to chutney logs

[Tor Bug Tracker & Wiki]

#22373: Add LogTimeGranularity 1 to chutney logs
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:  0.1
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


Comment:

 Closed by committing c3b5e39 to master.

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

Re: [tor-bugs] #22212 [Core Tor/Tor]: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padding timeout scheduled 164729ms in the past. Did the monotonic clock just jump?

[Tor Bug Tracker & Wiki]

#22212: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel
padding timeout scheduled 164729ms in the past. Did the monotonic clock
just jump?
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:6 arma]:
 > ...
 > Also, you might enjoy "LogTimeGranularity 1" in your chutney torrc
 files. :)

 Added in #22373.

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

Re: [tor-bugs] #22302 [Core Tor/Chutney]: test-network.sh uses a deprecated arithmetic syntax

[Tor Bug Tracker & Wiki]

#22302: test-network.sh uses a deprecated arithmetic syntax
--+--
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

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


Comment:

 Closed by merging 9e48988 into master.

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

[tor-bugs] #22373 [Core Tor/Chutney]: Add LogTimeGranularity 1 to chutney logs

[Tor Bug Tracker & Wiki]

#22373: Add LogTimeGranularity 1 to chutney logs
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:
Actual Points:  0.1   |  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+--
 Because arma said so in #22212.

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

Re: [tor-bugs] #22370 [Core Tor/Tor]: Stop leaking routerinfos that are rejected due to keypinning

[Tor Bug Tracker & Wiki]

#22370: Stop leaking routerinfos that are rejected due to keypinning
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.2-alpha
 Severity:  Major| Resolution:
 Keywords:  memory-leak, 029-backport,   |  Actual Points:  0.1
  030-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 Looks fine to me.
 Remember we want to backport this to 0.2.9 and later.
 But we don't have to do that right now.

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

Re: [tor-bugs] #22212 [Core Tor/Tor]: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padding timeout scheduled 164729ms in the past. Did the monotonic clock just jump?

[Tor Bug Tracker & Wiki]

#22212: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel
padding timeout scheduled 164729ms in the past. Did the monotonic clock
just jump?
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [comment:5 teor]:
 > This happened to me once when I was using chutney.
 > Since I am using a VM, there might have been an actual clock jump.

 You have log lines for that second, the second before it, and the second
 after it. So I am tempted to think there was no clock jump.

 Also, you might enjoy "LogTimeGranularity 1" in your chutney torrc files.
 :)

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

Re: [tor-bugs] #22212 [Core Tor/Tor]: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padding timeout scheduled 164729ms in the past. Did the monotonic clock just jump?

[Tor Bug Tracker & Wiki]

#22212: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel
padding timeout scheduled 164729ms in the past. Did the monotonic clock
just jump?
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * version:   => Tor: 0.3.1.1-alpha


Comment:

 This happened to me once when I was using chutney.
 Since I am using a VM, there might have been an actual clock jump.

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

Re: [tor-bugs] #22370 [Core Tor/Tor]: Stop leaking routerinfos that are rejected due to keypinning

[Tor Bug Tracker & Wiki]

#22370: Stop leaking routerinfos that are rejected due to keypinning
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.2-alpha
 Severity:  Major| Resolution:
 Keywords:  memory-leak, 029-backport,   |  Actual Points:  0.1
  030-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 I made a {{{bug22370-029-2}}} branch that fixes a typo in your commit
 message, removes a "tor-" from the changes file, and expands the function
 comment a bit. I'm afraid it's rebased since I don't know how to change
 commit messages otherwise. Do you like 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] #22368 [Core Tor/Tor]: double-free of MyFamily lines

[Tor Bug Tracker & Wiki]

#22368: double-free of MyFamily lines
+--
 Reporter:  arma|  Owner:
 Type:  defect  | Status:
|  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.1.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  regression memory-safety tor-relay  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arma):

 * status:  new => needs_review


Comment:

 My {{{bug22368}}} branch fixes it.

 I reproduced the bug on my freeBogatov relay, then applied this branch and
 I couldn't reproduce it anymore.

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

Re: [tor-bugs] #22369 [Metrics/Censorship analysis]: Increase of users in Ukraine due to block of Russia-based services

[Tor Bug Tracker & Wiki]

#22369: Increase of users in Ukraine due to block of Russia-based services
-+--
 Reporter:  dcf  |  Owner:  metrics-team
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ua  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Description changed by dcf:

Old description:

> There was a large and sudden increase in users from Ukraine, both relay
> and bridge, on 2017-05-16.
>
> It is probably related to a blockage by Ukraine of some Russia-based
> sites including VKontakte and Mail.ru:
>  * https://www.rt.com/business/388502-ukraine-bans-vk-yandex/
> ([https://web.archive.org/web/20170524224004/https://www.rt.com/business/388502
> -ukraine-bans-vk-yandex/ archive link])
>
> Other links:
>  * [https://www.reddit.com/r/TOR/comments/6c9ig1 reddit post]
>  * [https://lists.torproject.org/pipermail/tor-talk/2017-May/043205.html
> tor-talk thread]
>
> [[Image(userstats-relay-country-
> ua-2017-05-01-2017-05-24-off.png)]][https://metrics.torproject.org
> /userstats-relay-
> country.html?start=2017-05-01=2017-05-24=ua=off link]
>
> [[Image(userstats-bridge-country-ua-2017-05-01-2017-05-24.png)]]
> [https://metrics.torproject.org/userstats-bridge-
> country.html?start=2017-05-01=2017-05-24=ua=off link]
>
> [[Image(userstats-bridge-combined-ua-2017-05-01-2017-05-24.png)]]
> [https://metrics.torproject.org/userstats-bridge-
> combined.html?start=2017-05-01=2017-05-24=ua=off link]

New description:

 There was a large and sudden increase in users from Ukraine, both relay
 and bridge, on 2017-05-16.

 It is probably related to a blockage by Ukraine of some Russia-based sites
 including VKontakte and Mail.ru:
  * https://www.rt.com/business/388502-ukraine-bans-vk-yandex/
 ([https://web.archive.org/web/20170524224004/https://www.rt.com/business/388502
 -ukraine-bans-vk-yandex/ archive link])

 Other links:
  * [https://www.reddit.com/r/TOR/comments/6c9ig1 reddit post]
  * [https://lists.torproject.org/pipermail/tor-talk/2017-May/043205.html
 tor-talk thread]

 [[Image(userstats-relay-country-
 ua-2017-05-01-2017-05-24-off.png)]][https://metrics.torproject.org
 /userstats-relay-
 country.html?start=2017-05-01=2017-05-24=ua=off link]

 [[Image(userstats-bridge-country-ua-2017-05-01-2017-05-24.png)]]
 [https://metrics.torproject.org/userstats-bridge-
 country.html?start=2017-05-01=2017-05-24=ua=off link]

 [[Image(userstats-bridge-combined-ua-2017-05-01-2017-05-24.png)]]
 [https://metrics.torproject.org/userstats-bridge-
 combined.html?start=2017-05-01=2017-05-24=ua=off link]

 There was also a spike in Tor Browser downloads for the en-US and ru
 locales.
 [[Image(webstats-tb-locale-2017-05-01-2017-05-24.png)]]
 [https://metrics.torproject.org/webstats-tb-
 locale.html?start=2017-05-01=2017-05-24 link]

--

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

Re: [tor-bugs] #22370 [Core Tor/Tor]: Stop leaking routerinfos that are rejected due to keypinning

[Tor Bug Tracker & Wiki]

#22370: Stop leaking routerinfos that are rejected due to keypinning
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.2-alpha
 Severity:  Major| Resolution:
 Keywords:  memory-leak, 029-backport,   |  Actual Points:  0.1
  030-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 #22349 probably makes this way worse. :)

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

Re: [tor-bugs] #21926 [Core Tor/Tor]: Still had 1 address policies cached at shutdown

[Tor Bug Tracker & Wiki]

#21926: Still had 1 address policies cached at shutdown
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.6
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Wonder if #22370 is related.

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

Re: [tor-bugs] #22371 [Core Tor/Tor]: Always send AUTHDIR_NEWDESC events in response to new descriptors

[Tor Bug Tracker & Wiki]

#22371: Always send AUTHDIR_NEWDESC events in response to new descriptors
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  030-backport-maybe, 029-backport-|  Actual Points:  0.2
  maybe  |
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 (Oh, that branch includes the memory leak fix from #22370, because they
 are next to each other.)

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

Re: [tor-bugs] #22370 [Core Tor/Tor]: Stop leaking routerinfos that are rejected due to keypinning

[Tor Bug Tracker & Wiki]

#22370: Stop leaking routerinfos that are rejected due to keypinning
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.2-alpha
 Severity:  Major| Resolution:
 Keywords:  memory-leak, 029-backport,   |  Actual Points:  0.1
  030-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Looks like the cause of #21926 perhaps?

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

Re: [tor-bugs] #22371 [Core Tor/Tor]: Always send AUTHDIR_NEWDESC events in response to new descriptors

[Tor Bug Tracker & Wiki]

#22371: Always send AUTHDIR_NEWDESC events in response to new descriptors
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  030-backport-maybe, 029-backport-|  Actual Points:  0.2
  maybe  |
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Please see my branch bug22371-029.
 We might want to backport this to 0.2.9 because it's LTS, but for a
 rarely-used feature, I'm not sure.

 Opened #22372 to try to make sure we don't do this 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

[tor-bugs] #22372 [Core Tor/Tor]: Refactor dirserv_add_descriptor so we always free routerinfos and send events

[Tor Bug Tracker & Wiki]

#22372: Refactor dirserv_add_descriptor so we always free routerinfos and send
events
--+--
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  refactor
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+--
 dirserv_add_descriptor tries to do too many things, and we tend to forget
 to free memory (#22370), and send events (#22371, commit 77502ac in
 0.2.0.1-alpha).

 We should split the function into two:
 * one that does the rejections and frees the descriptor at the end, and
 * another that adds to the routerlist

 And we should make sure (somehow) that we always call
 control_event_or_authdir_new_descriptor(), as it's easy to miss one of the
 cases.

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

Re: [tor-bugs] #22370 [Core Tor/Tor]: Stop leaking routerinfos that are rejected due to keypinning

[Tor Bug Tracker & Wiki]

#22370: Stop leaking routerinfos that are rejected due to keypinning
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.2-alpha
 Severity:  Major| Resolution:
 Keywords:  memory-leak, 029-backport,   |  Actual Points:  0.1
  030-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Opened #22372 to try to make sure we don't do this 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

[tor-bugs] #22371 [Core Tor/Tor]: Always send AUTHDIR_NEWDESC events in response to new descriptors

[Tor Bug Tracker & Wiki]

#22371: Always send AUTHDIR_NEWDESC events in response to new descriptors
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core |Version:  Tor: 0.2.7.2-alpha
  Tor/Tor|   Keywords:  030-backport-maybe, 029-backport-
 Severity:  Normal   |  maybe
Actual Points:  0.2  |  Parent ID:
   Points:  0.2  |   Reviewer:
  Sponsor:   |
-+-
 There are two cases where we don't send an AUTHDIR_NEWDESCS event:
 * when we reject a descriptor due to keypinning, and
 * when we drop a descriptor, but not due to cosmetic differences

 This is a bug on tor-0.2.0.1-alpha and tor-0.2.7.2-alpha.

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

Re: [tor-bugs] #22370 [Core Tor/Tor]: Stop leaking routerinfos that are rejected due to keypinning

[Tor Bug Tracker & Wiki]

#22370: Stop leaking routerinfos that are rejected due to keypinning
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.2-alpha
 Severity:  Major| Resolution:
 Keywords:  memory-leak, 029-backport,   |  Actual Points:  0.1
  030-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * priority:  Medium => High
 * status:  new => needs_review
 * severity:  Normal => Major


Comment:

 Please see my branch bug22370-029 on github.
 Key pinning was turned on by default in 0.3.0.2-alpha.
 3/8 directory authorities are running versions > 0.3.0.2-alpha.

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

[tor-bugs] #22370 [Core Tor/Tor]: Stop leaking routerinfos that are rejected due to keypinning

[Tor Bug Tracker & Wiki]

#22370: Stop leaking routerinfos that are rejected due to keypinning
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core |Version:  Tor: 0.2.7.2-alpha
  Tor/Tor|   Keywords:  memory-leak, 029-backport,
 Severity:  Normal   |  030-backport
Actual Points:  0.1  |  Parent ID:
   Points:  0.1  |   Reviewer:
  Sponsor:   |
-+-
 When we added the keypinning code to dirserv_add_descriptor, we forgot to
 free rejected routerinfos.

 We should backport this to 0.2.9, because it is the earliest version run
 by the public directory authorities. (And it's LTS.)

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

Re: [tor-bugs] #22368 [Core Tor/Tor]: double-free of MyFamily lines

[Tor Bug Tracker & Wiki]

#22368: double-free of MyFamily lines
+--
 Reporter:  arma|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.1.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  regression memory-safety tor-relay  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arma):

 See #4998 for where the bug crept in.

 I think that means bugfix on 0.3.1.1-alpha. Does that mean it's still a
 regression? What does regression mean anyway? :)

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

Re: [tor-bugs] #22369 [Metrics/Censorship analysis]: Increase of users in Ukraine due to block of Russia-based services

[Tor Bug Tracker & Wiki]

#22369: Increase of users in Ukraine due to block of Russia-based services
-+--
 Reporter:  dcf  |  Owner:  metrics-team
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ua  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 Replying to [comment:4 dcf]:
 > cacahuatl wrote a deobfuscator and produced this output:
 >  * attachment:blckd.json.decoded

 Each of the `host`s has an associated `endpoint` and `hash`. There are
 only two distinct values of `endpoint` and `hash`:
 {{{
   "records": [
 {
   "host": "vk.com",
   "endpoint": "http://vk.com/ping.txt;,
   "hash": "b5b607d573e6a901ef215db6b1247404c92bb9ce"
 },
 ...
 {
   "host": "ok.ru",
   "endpoint": "http://ok.ru/google55e918a7d2970a76.html;,
   "hash": "526aabc2501699fdcfe5c58f98db82eed849c904"
 },
 ...
 }}}

 The `hash` is the sha1sum of what you get if you fetch those two URLs.

 http://vk.com/ping.txt
 {{{
 WulbqygHXe
 idjxMb2pJF
 qORaQtmSWo
 SF32HldC2U
 dMVhUpEEbt
 LwBNJubmVq
 j03L2D3Lyp
 z9z76x6caZ
 z2Vv7uVT1M
 phZwKcVHVT
 }}}

 http://ok.ru/google55e918a7d2970a76.html
 {{{
 google-site-verification: google55e918a7d2970a76.html
 }}}

 cacahuatl found a verifyDomain function that seems related:
  * attachment:verifyDomain.js

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

Re: [tor-bugs] #22369 [Metrics/Censorship analysis]: Increase of users in Ukraine due to block of Russia-based services

[Tor Bug Tracker & Wiki]

#22369: Increase of users in Ukraine due to block of Russia-based services
-+--
 Reporter:  dcf  |  Owner:  metrics-team
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ua  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 cacahuatl wrote a deobfuscator and produced this output:
  * attachment:blckd.json.decoded

 Deobfuscator source code:
 {{{
 #!/usr/bin/env python3
 import requests
 hosts = ['updtbrwsr.com', 'updtapi.com', 'brwsrapi.com', 'mrbrwsr.com',
 'savebrwsr.com', 'svbrwsr.com']
 salt = 1234567890
 for host in hosts:
 r = requests.get('https://update.{}/blckd.json'.format(host))
 j = b""
 for c in r.text:
 j += bytes([(ord(c) ^ salt) & 0xff])
 print("%s" % j.decode('utf-8'))
 }}}

 The decoded file looks like this (abridged):
 {{{
 {
   "records": [
 {
   "host": "vk.com",
   "endpoint": "http://vk.com/ping.txt;,
   "hash": "b5b607d573e6a901ef215db6b1247404c92bb9ce"
 },
   ...
 "mail.ru"
   ],
   "defaults": {
 "endpoint": "http://vk.com/ping.txt;,
 "hash": "b5b607d573e6a901ef215db6b1247404c92bb9ce"
   }
 }
 }}}

 The list of `host`s in the lone `"mail.ru"` record contains these domains:
  * vk.com
  * vkontakte.ru
  * vk.me
  * vk.cc
  * ok.ru
  * odnoklassniki.ru
  * odnoklassniki.ua
  * ok.me
  * vk-cdn.net
  * userapi.com

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

Re: [tor-bugs] #22368 [Core Tor/Tor]: double-free of MyFamily lines

[Tor Bug Tracker & Wiki]

#22368: double-free of MyFamily lines
+--
 Reporter:  arma|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.1.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  regression memory-safety tor-relay  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arma):

 * keywords:   => regression memory-safety tor-relay


Comment:

 (trac fail)

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

Re: [tor-bugs] #22368 [Core Tor/Tor]: double-free of MyFamily lines

[Tor Bug Tracker & Wiki]

#22368: double-free of MyFamily lines
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arma):

 * keywords:  regression memory-safety tor-relay =>


Comment:

 Here's the patch I'm testing:
 {{{
 diff --git a/src/or/router.c b/src/or/router.c
 index 642f415..f2741b7 100644
 --- a/src/or/router.c
 +++ b/src/or/router.c
 @@ -2289,7 +2289,7 @@ router_build_fresh_descriptor(routerinfo_t **r,
 extrainfo_
 char *name = family->value;
 const node_t *member;
 if (!strcasecmp(name, options->Nickname))
 - goto skip; /* Don't list ourself, that's redundant */
 + continue; /* Don't list ourself, that's redundant */
 else
   member = node_get_by_nickname(name, 1);
 if (!member) {
 @@ -2308,7 +2308,7 @@ router_build_fresh_descriptor(routerinfo_t **r,
 extrainfo_
 smartlist_add_strdup(warned_nonexistent_family, name);
   }
   if (is_legal) {
 -   smartlist_add(ri->declared_family, name);
 +   smartlist_add_strdup(ri->declared_family, name);
 name = NULL;
   }
 } else if (router_digest_is_me(member->identity)) {
 @@ -2323,8 +2323,6 @@ router_build_fresh_descriptor(routerinfo_t **r,
 extrainfo_
   if (smartlist_contains_string(warned_nonexistent_family, name))
 smartlist_string_remove(warned_nonexistent_family, name);
 }
 -skip:
 -   tor_free(name);
  }

  /* remove duplicates from the list */
 }}}

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

Re: [tor-bugs] #22368 [Core Tor/Tor]: double-free of MyFamily lines

[Tor Bug Tracker & Wiki]

#22368: double-free of MyFamily lines
+--
 Reporter:  arma|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.1.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  regression memory-safety tor-relay  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * keywords:   => regression memory-safety tor-relay


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

Re: [tor-bugs] #4998 [Core Tor/Tor]: MyFamily as a list

[Tor Bug Tracker & Wiki]

#4998: MyFamily as a list
+--
 Reporter:  weasel  |  Owner:  Jigsaw52
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.3.11-alpha
 Severity:  Normal  | Resolution:  implemented
 Keywords:  tor-relay lorax easy intro  |  Actual Points:
Parent ID:  #15060  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arma):

 Alas, this patch seems to have caused #22368 (a double free 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] #22369 [Metrics/Censorship analysis]: Increase of users in Ukraine due to block of Russia-based services

[Tor Bug Tracker & Wiki]

#22369: Increase of users in Ukraine due to block of Russia-based services
-+--
 Reporter:  dcf  |  Owner:  metrics-team
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ua  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 cachuatl found code that looks like it's fetching an obfuscated whitelist
 of sites to proxy through tor, and deobfuscating it:
  * attachment:fetchBlackListJson.js\\
Retrieves !https://update. ''host'' /blckd.json for values of ''host''
 in `['updtbrwsr.com', 'updtapi.com', 'brwsrapi.com', 'mrbrwsr.com',
 'savebrwsr.com', 'svbrwsr.com']`.

 {{{
 var decryptJson = function decryptJson(str) {
   var xorc = (0, _xorc2.default)(1234567890);
   return JSON.parse(xorc.decrypt(str));
 };

 exports.default = function (salt) {
   var randomMin = arguments.length > 1 && arguments[1] !== undefined ?
 arguments[1] : 100;
   var randomMax = arguments.length > 2 && arguments[2] !== undefined ?
 arguments[2] : 100;

   var saltInt = parseInt(salt);

   if (salt) {
 if (!saltInt) {
   throw new Error('Salt is not a Number');
 }
 salt = saltInt;
   } else {
 salt = Math.round(Math.random() * (randomMax - randomMin) +
 randomMin);
   }

   return {
 encrypt: function encrypt(str) {
   var result = '';
   for (var i = 0, n = str.length; i < n; i++) {
 result += String.fromCharCode(salt ^ str.charCodeAt(i));
   }
   return result;
 },
 decrypt: function decrypt(hash) {
   var result = '';
   for (var i = 0, n = hash.length; i < n; i++) {
 result += String.fromCharCode(salt ^ hash.charCodeAt(i));
   }
   return result;
 }
   };
 };
 }}}

 A sample obfuscated download:
  * https://update.updtbrwsr.com/blckd.json
 
([https://web.archive.org/web/20170524234418/https://update.updtbrwsr.com/blckd.json
 archive link])\\
(https://updtbrwsr.com/blckd.json
 ([https://web.archive.org/web/20170524233844/https://updtbrwsr.com/blckd.json
 archive link]) also works).
  * attachment:blckd.json

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

Re: [tor-bugs] #22369 [Metrics/Censorship analysis]: Increase of users in Ukraine due to block of Russia-based services

[Tor Bug Tracker & Wiki]

#22369: Increase of users in Ukraine due to block of Russia-based services
-+--
 Reporter:  dcf  |  Owner:  metrics-team
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ua  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 Replying to [comment:1 dcf]:
 > A large fraction of the increase may be attributable to the use of
 [https://freeu.online/ FreeU Browser], a browser containing Tor. The
 browser was produced by Mail.ru and prominently featured on VKontakte
 starting 2017-05-20.
 >  * https://tjournal.ru/44669-vkontakte-predlozhila-ukraincam-
 peredelannii-brauzer-amigo-s-tor-dlya-obhoda-blokirovok
 ([https://web.archive.org/web/20170524221422/https://tjournal.ru/44669
 -vkontakte-predlozhila-ukraincam-peredelannii-brauzer-amigo-s-tor-dlya-
 obhoda-blokirovok archive link])
 > > Approximately on May 20, "VKontakte" began to offer users from Ukraine
 to install a desktop FreeU browser to bypass the locks of Russian social
 networks. ... The browser was also promoted with advertising posts in
 "VKontakte", "Twitter" and "Classmates", as well as through banners on
 YouTube. ... On its website FreeU is positioned as a browser "with access
 to blocked sites and social networks". ... As explained by TJ developer
 from a major Russian company, the code for FreeU shows that this is
 actually a reworked browser "Amigo" with built-in technology Tor.
 >
 > valdikss inspected the bundle and found a tor executable renamed to
 `freeu_helper`, along with `torrc` and other dependencies:
 > [[Image(11pW7Vg.png)]]
 >
 > The article also says that the browser only unblocks some sites (maybe
 those operated by Mail.ru) and not others. Presumably they have a proxy
 configuration that only sends some domains through the tor proxy.
 > > FreeU gives access only to blocked sites in Ukraine. If you use it in
 Russia, it does not give you access to resources included in the
 Roskomnadzor blacklist. In the "Amigo" function there is no circumvention
 of the restriction of access to sites and blocker advertising.

 cacahuatl found a script that generates a PAC file to send certain domains
 through the SOCKS proxy at 127.0.0.1:9050 and do others DIRECT:
  * freeu_setup.exe
* Chrome.7z
  * Chrome-bin/56.1.2924.38/amigo_resources.pak/background.js
 {{{
 var BASE_PROXY_CONFIG = { scope: 'regular' };

 var JSON_HOSTS = ['updtbrwsr.com', 'updtapi.com', 'brwsrapi.com',
 'mrbrwsr.com', 'savebrwsr.com', 'svbrwsr.com'];

 var generateProxyConfig = function generateProxyConfig(hostnames) {
   return {
 mode: 'pac_script',
 pacScript: {
   data: '\n  function FindProxyForURL(url, host) {\nconst
 blackList = [' + hostnames.map(function (i) {
 return '"' + i + '"';
   }).join(',') + '];\nfor (let item of blackList) {\n
 if (dnsDomainIs(host, item))\nreturn \'SOCKS5 ' + '127.0.0.1'
 + ':' + 9050 + '\';\n}\nreturn \'DIRECT\';\n  }\n'
 }
   };
 };
 }}}

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

Re: [tor-bugs] #22369 [Metrics/Censorship analysis]: Increase of users in Ukraine due to block of Russia-based services

[Tor Bug Tracker & Wiki]

#22369: Increase of users in Ukraine due to block of Russia-based services
-+--
 Reporter:  dcf  |  Owner:  metrics-team
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ua  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by arma):

 Replying to [comment:1 dcf]:
 > A large fraction of the increase may be attributable to the use of
 [https://freeu.online/ FreeU Browser], a browser containing Tor

 Three observations:

 A) If many of the new users are because of this browser, and if the
 browser only sends requests for a few domains through Tor, then we have a
 lot of new Tor clients that mostly aren't adding load to the network.
 Sounds fine to me.

 B) I'm happy, not sad, that they aren't shouting "and this browser uses
 Tor!" along with the release. This way nobody gets confused about what
 security properties they do or don't get, since the browser side doesn't
 contain any of the privacy fixes done by Tor Browser:
 https://www.torproject.org/projects/torbrowser/design/

 C) Does this mean that mail.ru is committing to supporting connections via
 Tor? So when people ask for good free webmail services that work with Tor,
 we should point them to mail.ru? :)

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

Re: [tor-bugs] #22369 [Metrics/Censorship analysis]: Increase of users in Ukraine due to block of Russia-based services

[Tor Bug Tracker & Wiki]

#22369: Increase of users in Ukraine due to block of Russia-based services
-+--
 Reporter:  dcf  |  Owner:  metrics-team
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ua  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 A large fraction of the increase may be attributable to the use of
 [https://freeu.online/ FreeU Browser], a browser containing Tor. The
 browser was produced by Mail.ru and prominently featured on VKontakte
 starting 2017-05-20.
  * https://tjournal.ru/44669-vkontakte-predlozhila-ukraincam-peredelannii-
 brauzer-amigo-s-tor-dlya-obhoda-blokirovok
 ([https://web.archive.org/web/20170524221422/https://tjournal.ru/44669
 -vkontakte-predlozhila-ukraincam-peredelannii-brauzer-amigo-s-tor-dlya-
 obhoda-blokirovok archive link])
 > Approximately on May 20, "VKontakte" began to offer users from Ukraine
 to install a desktop FreeU browser to bypass the locks of Russian social
 networks. ... The browser was also promoted with advertising posts in
 "VKontakte", "Twitter" and "Classmates", as well as through banners on
 YouTube. ... On its website FreeU is positioned as a browser "with access
 to blocked sites and social networks". ... As explained by TJ developer
 from a major Russian company, the code for FreeU shows that this is
 actually a reworked browser "Amigo" with built-in technology Tor.

 valdikss inspected the bundle and found a tor executable renamed to
 `freeu_helper`, along with `torrc` and other dependencies:
 [[Image(11pW7Vg.png)]]

 The article also says that the browser only unblocks some sites (maybe
 those operated by Mail.ru) and not others. Presumably they have a proxy
 configuration that only sends some domains through the tor proxy.
 > FreeU gives access only to blocked sites in Ukraine. If you use it in
 Russia, it does not give you access to resources included in the
 Roskomnadzor blacklist. In the "Amigo" function there is no circumvention
 of the restriction of access to sites and blocker advertising.

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

Re: [tor-bugs] #22343 [Applications/Tor Browser]: Save as... in the context menu results in using the catch-all circuit

[Tor Bug Tracker & Wiki]

#22343: Save as... in the context menu results in using the catch-all circuit
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-linkability, ff52-esr,   |  Actual Points:
  tbb-7.0-must, TorBrowserTeam201705 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 I also see the catch-all circuit being used when I choose `File > Save
 As`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22369 [Metrics/Censorship analysis]: Increase of users in Ukraine due to block of Russia-based services

[Tor Bug Tracker & Wiki]

#22369: Increase of users in Ukraine due to block of Russia-based services
-+-
 Reporter:  dcf  |  Owner:  metrics-team
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   |   Keywords:  censorship
 |  block ua
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 There was a large and sudden increase in users from Ukraine, both relay
 and bridge, on 2017-05-16.

 It is probably related to a blockage by Ukraine of some Russia-based sites
 including VKontakte and Mail.ru:
  * https://www.rt.com/business/388502-ukraine-bans-vk-yandex/
 ([https://web.archive.org/web/20170524224004/https://www.rt.com/business/388502
 -ukraine-bans-vk-yandex/ archive link])

 Other links:
  * [https://www.reddit.com/r/TOR/comments/6c9ig1 reddit post]
  * [https://lists.torproject.org/pipermail/tor-talk/2017-May/043205.html
 tor-talk thread]

 [[Image(userstats-relay-country-
 ua-2017-05-01-2017-05-24-off.png)]][https://metrics.torproject.org
 /userstats-relay-
 country.html?start=2017-05-01=2017-05-24=ua=off link]

 [[Image(userstats-bridge-country-ua-2017-05-01-2017-05-24.png)]]
 [https://metrics.torproject.org/userstats-bridge-
 country.html?start=2017-05-01=2017-05-24=ua=off link]

 [[Image(userstats-bridge-combined-ua-2017-05-01-2017-05-24.png)]]
 [https://metrics.torproject.org/userstats-bridge-
 combined.html?start=2017-05-01=2017-05-24=ua=off link]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22368 [Core Tor/Tor]: double-free of MyFamily lines

[Tor Bug Tracker & Wiki]

#22368: double-free of MyFamily lines
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Run a relay under valgrind with "myfamily moria1", and then ctrl-C it once
 it bootstraps. Upon exit, you'll get:
 {{{
 ==17604== Invalid free() / delete / delete[] / realloc()
 ==17604==at 0x4C29E90: free (in /usr/lib/valgrind/vgpreload_memcheck-
 amd64-linux.so)
 ==17604==by 0x277E75: config_free_lines (confline.c:323)
 ==17604==by 0x1F56F2: or_options_free (config.c:898)
 ==17604==by 0x1F6583: config_free_all (config.c:907)
 ==17604==by 0x157CCC: tor_free_all (main.c:3238)
 ==17604==by 0x157DB0: tor_cleanup (main.c:3310)
 ==17604==by 0x2614E5: hibernate_begin (hibernate.c:818)
 ==17604==by 0x1584E9: process_signal (main.c:2686)
 ==17604==by 0x1584E9: signal_callback (main.c:2663)
 ==17604==by 0x5361A14: event_base_loop (in /usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5.1.9)
 ==17604==by 0x156E23: run_main_loop_once (main.c:2594)
 ==17604==by 0x156E23: run_main_loop_until_done (main.c:2648)
 ==17604==by 0x156E23: do_main_loop (main.c:2561)
 ==17604==by 0x15A664: tor_main (main.c:3745)
 ==17604==by 0x152628: main (tor_main.c:34)
 ==17604==  Address 0x668f9a0 is 0 bytes inside an unallocated block of
 size 16 in arena "client"
 }}}

 User DeS originally found this bug on #22255, with this stack trace:
 {{{
 ==33656== Invalid free() / delete / delete[] / realloc()
 ==33656==at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-
 amd64-linux.so)
 ==33656==by 0x1A4378: routerinfo_free (routerlist.c:3172)
 ==33656==by 0x199BF6: router_rebuild_descriptor (router.c:2449)
 ==33656==by 0x199CD2: router_get_my_routerinfo (router.c:2013)
 ==33656==by 0x1D183E: channel_tls_process_netinfo_cell
 (channeltls.c:1679)
 ==33656==by 0x1D183E: channel_tls_handle_cell (channeltls.c:1133)
 ==33656==by 0x2137A0: connection_or_process_cells_from_inbuf
 (connection_or.c:2085)
 ==33656==by 0x20ABE4: connection_handle_read_impl (connection.c:3451)
 ==33656==by 0x153CB0: conn_read_callback (main.c:736)
 ==33656==by 0x5363F23: event_base_loop (in /usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5.1.9)
 ==33656==by 0x154DDC: run_main_loop_once (main.c:2594)
 ==33656==by 0x154DDC: run_main_loop_until_done (main.c:2648)
 ==33656==by 0x154DDC: do_main_loop (main.c:2561)
 ==33656==by 0x158594: tor_main (main.c:3745)
 ==33656==by 0x1507C8: main (tor_main.c:34)
 ==33656==  Address 0x6453720 is 0 bytes inside a block of size 42 free'd
 ==33656==at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-
 amd64-linux.so)
 ==33656==by 0x1995BC: router_build_fresh_descriptor (router.c:2327)
 ==33656==by 0x199BE2: router_rebuild_descriptor (router.c:2445)
 ==33656==by 0x199CD2: router_get_my_routerinfo (router.c:2013)
 ==33656==by 0x1D183E: channel_tls_process_netinfo_cell
 (channeltls.c:1679)
 ==33656==by 0x1D183E: channel_tls_handle_cell (channeltls.c:1133)
 ==33656==by 0x2137A0: connection_or_process_cells_from_inbuf
 (connection_or.c:2085)
 ==33656==by 0x20ABE4: connection_handle_read_impl (connection.c:3451)
 ==33656==by 0x153CB0: conn_read_callback (main.c:736)
 ==33656==by 0x5363F23: event_base_loop (in /usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5.1.9)
 ==33656==by 0x154DDC: run_main_loop_once (main.c:2594)
 ==33656==by 0x154DDC: run_main_loop_until_done (main.c:2648)
 ==33656==by 0x154DDC: do_main_loop (main.c:2561)
 ==33656==by 0x158594: tor_main (main.c:3745)
 ==33656==by 0x1507C8: main (tor_main.c:34)
 ==33656==
 ==33656== Invalid free() / delete / delete[] / realloc()
 ==33656==at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-
 amd64-linux.so)
 ==33656==by 0x1995BC: router_build_fresh_descriptor (router.c:2327)
 ==33656==by 0x199BE2: router_rebuild_descriptor (router.c:2445)
 ==33656==by 0x199CD2: router_get_my_routerinfo (router.c:2013)
 ==33656==by 0x19A358: router_my_exit_policy_is_reject_star
 (router.c:1963)
 ==33656==by 0x247025: dns_resolve_impl.constprop.9 (dns.c:720)
 ==33656==by 0x249A68: dns_resolve (dns.c:614)
 ==33656==by 0x2101BA: connection_exit_begin_conn
 (connection_edge.c:3292)
 ==33656==by 0x17B4A0: connection_edge_process_relay_cell
 (relay.c:1648)
 ==33656==by 0x17CCD8: circuit_receive_relay_cell (relay.c:328)
 ==33656==by 0x1EF725: command_process_relay_cell (command.c:542)
 ==33656==by 0x1EF725: command_process_cell 

Re: [tor-bugs] #3698 [Core Tor/Tor]: Multi-line torrc options conflict with Windows paths

[Tor Bug Tracker & Wiki]

#3698: Multi-line torrc options conflict with Windows paths
-+--
 Reporter:  karsten  |  Owner:  Jigsaw52
 Type:  defect   | Status:  assigned
 Priority:  Low  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  windows tor-relay torrc  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by Jigsaw52):

 * keywords:  windows tor-relay => windows tor-relay torrc
 * owner:   => Jigsaw52
 * status:  new => assigned
 * severity:   => Normal
 * cc: danielpinto52@… (added)


Comment:

 I ran into a problem similar to this while implementing #1922.

 Currently there are two syntaxes for configuration values on torrc:
  - values enclosed by double quotes are read as C escaped strings
  - values not enclosed by quotes are read as is and a backslash can be
 used as a line continuation character

 Neither are good for Windows paths ending with a backslash and those are
 useful because they provide an easy way to tell the path is a directory.

 I thought of adding a third syntax: values enclosed in single quotes would
 be read as it is, without any escaping. The changes needed to support this
 are fairly simple and I do not think this would break any existing torrc.

 What do you guys 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] #22363 [Core Tor/Tor]: Make our test network public

[Tor Bug Tracker & Wiki]

#22363: Make our test network public
--+--
 Reporter:  dgoulet   |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  test-network  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tom):

 * cc: tom (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] #22320 [Applications/Tor Browser]: Referrer not hidden when comming from a .onion address

[Tor Bug Tracker & Wiki]

#22320: Referrer not hidden when comming from a .onion address
-+-
 Reporter:  pege |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Replying to [comment:7 gk]:
 > Could you correct the comment in `all.js` as well (see comment:1) (in
 the Mozilla patch, too)? Apart from that looks good to me.

 Good point. The comment was already corrected in
 https://bugzilla.mozilla.org/show_bug.cgi?id=1357247 but I didn't backport
 it until now.

 New patch with both comment and implementation fixed:
 https://github.com/arthuredelstein/tor-browser/commit/22320+1

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

Re: [tor-bugs] #22320 [Applications/Tor Browser]: Referrer not hidden when comming from a .onion address

[Tor Bug Tracker & Wiki]

#22320: Referrer not hidden when comming from a .onion address
-+-
 Reporter:  pege |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: mcs, brade (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] #22320 [Applications/Tor Browser]: Referrer not hidden when comming from a .onion address

[Tor Bug Tracker & Wiki]

#22320: Referrer not hidden when comming from a .onion address
-+-
 Reporter:  pege |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Could you correct the comment in `all.js` as well (see comment:1) (in the
 Mozilla patch, too)? Apart from that 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] #22320 [Applications/Tor Browser]: Referrer not hidden when comming from a .onion address

[Tor Bug Tracker & Wiki]

#22320: Referrer not hidden when comming from a .onion address
-+-
 Reporter:  pege |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 The Mozilla bug is at
 https://bugzilla.mozilla.org/show_bug.cgi?id=1367564

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

Re: [tor-bugs] #22301 [Core Tor/Stem]: make test-stem doesn't work

[Tor Bug Tracker & Wiki]

#22301: make test-stem doesn't work
---+
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
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:

 Hi catalyst, think I'm gonna resolve this in favor of the child tickets
 you filed.

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

Re: [tor-bugs] #22366 [Core Tor/Stem]: run_tests.py can't find tor via relative pathname if cwd not the top of the stem tree

[Tor Bug Tracker & Wiki]

#22366: run_tests.py can't find tor via relative pathname if cwd not the top of 
the
stem tree
---+
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID:  #22301 | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Wonderful! Thanks for pointing these out catalyst - all great catches. :P

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

Re: [tor-bugs] #22366 [Core Tor/Stem]: run_tests.py can't find tor via relative pathname if cwd not the top of the stem tree

[Tor Bug Tracker & Wiki]

#22366: run_tests.py can't find tor via relative pathname if cwd not the top of 
the
stem tree
---+
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22301 | Points:
 Reviewer: |Sponsor:
---+

Comment (by catalyst):

 Looks like it works.  Thanks!

 {{{
 tlyu@arcadia:~/src/tor$ STEM_SOURCE_DIR=../stem make test-stem
 }}}

 {{{
 613 TESTS WERE SKIPPED
 TESTING PASSED (56 seconds)
 }}}

 `make test-stem-full` seems to have some problems but I can open separate
 tickets about those.

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

Re: [tor-bugs] #22320 [Applications/Tor Browser]: Referrer not hidden when comming from a .onion address

[Tor Bug Tracker & Wiki]

#22320: Referrer not hidden when comming from a .onion address
-+-
 Reporter:  pege |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Here's the patch:
 https://github.com/arthuredelstein/tor-browser/commit/22320

 I manually tested this and confirmed that when the pref
 "network.http.referer.hideOnionSource" is true, no referer is sent in the
 headers when leaving an onion site. But when the pref is false, a referer
 containing the .onion domain is sent.

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

Re: [tor-bugs] #22327 [Applications/Tor Browser]: First party isolation of Page Info

[Tor Bug Tracker & Wiki]

#22327: First party isolation of Page Info
+--
 Reporter:  arthuredelstein |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-7.0-must TorBrowserTeam201705R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * cc: mcs, brade (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] #22327 [Applications/Tor Browser]: First party isolation of Page Info

[Tor Bug Tracker & Wiki]

#22327: First party isolation of Page Info
+--
 Reporter:  arthuredelstein |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-7.0-must TorBrowserTeam201705R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * status:  needs_information => needs_review


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

Re: [tor-bugs] #22362 [Applications/Tor Browser]: Tor Browser freezes when loading http://zeit.de

[Tor Bug Tracker & Wiki]

#22362: Tor Browser freezes when loading http://zeit.de
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #22366 [Core Tor/Stem]: run_tests.py can't find tor via relative pathname if cwd not the top of the stem tree

[Tor Bug Tracker & Wiki]

#22366: run_tests.py can't find tor via relative pathname if cwd not the top of 
the
stem tree
---+
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22301 | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Sorry about all the back-and-forth. Change pushed. Mind giving it a whirl?

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

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

Re: [tor-bugs] #22366 [Core Tor/Stem]: run_tests.py can't find tor via relative pathname if cwd not the top of the stem tree

[Tor Bug Tracker & Wiki]

#22366: run_tests.py can't find tor via relative pathname if cwd not the top of 
the
stem tree
---+
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22301 | Points:
 Reviewer: |Sponsor:
---+

Comment (by catalyst):

 {{{
 tlyu@arcadia:~/src/tor$ ../stem/run_tests.py --tor ./src/or/tor --all
 --log notice --target RUN_ALL
 }}}

 now produces several instances of

 {{{
 Starting /home/tlyu/src/stem/src/or/tor...

   failed to start tor: '/home/tlyu/src/stem/src/or/tor' doesn't exist
 }}}

 which seems to be making some progress.

 Given your most recent comment I tried limiting to only
 `test.integ.process`, which succeeded, so there is some evidence to
 support your hypothesis.

 {{{
 tlyu@arcadia:~/src/tor$ ../stem/run_tests.py --tor ./src/or/tor --all
 --log notice --target RUN_ALL --test test.integ.process
 }}}

 {{{
 50 TESTS WERE SKIPPED
 TESTING PASSED (37 seconds)
 }}}

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

Re: [tor-bugs] #22366 [Core Tor/Stem]: run_tests.py can't find tor via relative pathname if cwd not the top of the stem tree

[Tor Bug Tracker & Wiki]

#22366: run_tests.py can't find tor via relative pathname if cwd not the top of 
the
stem tree
---+
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22301 | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Oh! On thinking about this some more I think I know why I got the
 inconsistent failures earlier. To improve test performance we prepare for
 the installation test in parallel. That preparation calls chdir so if we
 start tor while in the middle of that context we'd fail this way.

 Ick. Gonna look into a fix for 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] #22366 [Core Tor/Stem]: run_tests.py can't find tor via relative pathname if cwd not the top of the stem tree

[Tor Bug Tracker & Wiki]

#22366: run_tests.py can't find tor via relative pathname if cwd not the top of 
the
stem tree
---+
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22301 | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Pushed a fix for the scenario I was able to repro. Mind giving it a whirl?

 https://gitweb.torproject.org/stem.git/commit/?id=0d6212e

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

Re: [tor-bugs] #22364 [Applications/Tor Browser]: nexusmods.com broken in Tor Browser

[Tor Bug Tracker & Wiki]

#22364: nexusmods.com broken in Tor Browser
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 Hm, this works for me in a freshly installed Tor Browser 6.5.2 on a 64bit
 Linux machine. How can I reproduce 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] #22366 [Core Tor/Stem]: run_tests.py can't find tor via relative pathname if cwd not the top of the stem tree

[Tor Bug Tracker & Wiki]

#22366: run_tests.py can't find tor via relative pathname if cwd not the top of 
the
stem tree
---+
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22301 | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Still little puzzled but I did manage to get a repro *if* the RELATIVE
 target is invoked. I'll go ahead and fix that and we'll see if it
 addresses the issue for you.

 {{{
 % PATH="/usr/bin" ../stem/run_tests.py --tor ./tor/src/or/tor --all --log
 notice --target RELATIVE
 ==
  INITIALISING
 ==

   checking stem version... 1.5.4-dev
   checking tor version...  0.3.1.0-alpha-dev
   checking python version...   2.7.3
   checking cryptography version... 1.7.2
   checking pynacl version...   1.0.1
   checking mock version... 1.3.0
   checking pyflakes version... 1.0.0
   checking pycodestyle version...  2.3.1
   checking for orphaned .pyc files...  done
   checking for unused tests... done
   running pyflakes...  done (1.8s)
   running pycodestyle...   done (6.4s)

 ==
   UNIT TESTS
 ==

 ...

 ==
   INTEGRATION TESTS
 ==

 Setting up a test instance...
   making test directory (/home/atagar/Desktop/stem/test/data)... skipped
   configuring logger (/home/atagar/Desktop/stem/test/data/log)... done
   writing torrc (/home/atagar/Desktop/stem/test/data/torrc)... done
 # configuration for stem integration tests
 DataDirectory ./data
 SocksPort 1112
 DownloadExtraInfo 1
 Log notice stdout
 Log notice file ./data/tor_log
 ControlPort 

 Starting ./tor/src/or/tor...

   failed to start tor: './tor/src/or/tor' doesn't exist


 Shutting down tor... done

 TESTING FAILED (10 seconds)

 You can re-run just these tests with:

 }}}

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

Re: [tor-bugs] #22366 [Core Tor/Stem]: run_tests.py can't find tor via relative pathname if cwd not the top of the stem tree

[Tor Bug Tracker & Wiki]

#22366: run_tests.py can't find tor via relative pathname if cwd not the top of 
the
stem tree
---+
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22301 | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 This is strange. I've been able to repro this twice but every time I get a
 successful repro the subsequent invocation passes. Maybe some caching I
 don't yet grok. Still digging.

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

Re: [tor-bugs] #22367 [Core Tor/Stem]: test.integ.process seems to expect a tor binary in $PATH

[Tor Bug Tracker & Wiki]

#22367: test.integ.process seems to expect a tor binary in $PATH
---+
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID:  #22301 | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Fix pushed: https://gitweb.torproject.org/stem.git/commit/?id=b21d590

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

Re: [tor-bugs] #22366 [Core Tor/Stem]: run_tests.py can't find tor via relative pathname if cwd not the top of the stem tree

[Tor Bug Tracker & Wiki]

#22366: run_tests.py can't find tor via relative pathname if cwd not the top of 
the
stem tree
---+
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22301 | Points:
 Reviewer: |Sponsor:
---+

Comment (by catalyst):

 Oh!  After experimenting a bit more, this bug also seems dependent on the
 lack of a system `tor` binary in `$PATH` for reasons I don't yet
 understand.

 {{{
 tlyu@arcadia:~/src/tor$ PATH=/tmp/tor-stem:$PATH ../stem/run_tests.py
 --tor ./src/or/tor --all --log notice
 }}}

 successfully finds `./src/or/tor` and runs it.

 {{{
 Starting ./src/or/tor...

   May 24 15:36:09.928 [notice] Tor 0.3.1.1-alpha (git-af98b862a51c001e)
 running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8,
 Liblzma N/A, and Libzstd N/A.
 }}}

 `/tmp/tor-stem/tor` is a shell script that just runs `kill -ABRT $$`, so
 it's clearly not producing the quoted output.  Of course, now
 `test.integ.version` fails because of the unusual execution properties of
 the "system" `tor`.

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

Re: [tor-bugs] #22367 [Core Tor/Stem]: test.integ.process seems to expect a tor binary in $PATH

[Tor Bug Tracker & Wiki]

#22367: test.integ.process seems to expect a tor binary in $PATH
---+
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22301 | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Interesting. I'm not sure why this isn't reproing for me but I definitely
 see the issue. One sec, whipping up a fix.

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

[tor-bugs] #22367 [Core Tor/Stem]: test.integ.process seems to expect a tor binary in $PATH

[Tor Bug Tracker & Wiki]

#22367: test.integ.process seems to expect a tor binary in $PATH
---+
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #22301
   Points: |   Reviewer:
  Sponsor: |
---+
 `test.integ.process` seems to expect to find a system `tor` binary in
 `$PATH`.  This is probably not intended (and if it is, it should be
 clearly documented).  This prevents the tests from working on a system
 with no `tor` binary in the `$PATH`, which is a configuration I think we
 should support.

 I tried to create an alternative way to replicate this failure by putting
 a shell script called `tor` in a directory by itself at the head of my
 `$PATH` that just does a `kill -ABRT $$` but that caused
 `test.integ.version.TestVersion` to fail instead (and `test.integ.process`
 to succeed, oddly enough).  Maybe the only way to reliably replicate this
 is by removing (or renaming) the system `tor`.

 {{{
 tlyu@arcadia:~/src/stem$ ./run_tests.py --tor `pwd`/../tor/src/or/tor
 --all --log notice --target RUN_ALL
 }}}

 produces errors like

 {{{
 ==
 ERROR: test_no_orphaned_process
 --
 Traceback (most recent call last):
   File "/home/tlyu/src/stem/test/require.py", line 58, in wrapped
 return func(self, *args, **kwargs)
   File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 1305, in
 patched
 return func(*args, **keywargs)
   File "/home/tlyu/src/stem/test/integ/process.py", line 210, in
 test_no_orphaned_process
 stem.process.launch_tor()
   File "/home/tlyu/src/stem/stem/process.py", line 98, in launch_tor
 raise OSError("'%s' isn't available on your system. Maybe it's not in
 your PATH?" % tor_cmd)
 OSError: 'tor' isn't available on your system. Maybe it's not in your
 PATH?

 --
 Ran 21 tests in 0.972s

 FAILED (errors=1, skipped=7)
 }}}

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

Re: [tor-bugs] #22366 [Core Tor/Stem]: run_tests.py can't find tor via relative pathname if cwd not the top of the stem tree

[Tor Bug Tracker & Wiki]

#22366: run_tests.py can't find tor via relative pathname if cwd not the top of 
the
stem tree
---+
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22301 | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Hmmm, I'm having trouble reproing this one...

 {{{
 % env -i ../stem/run_tests.py --tor ./tor/src/or/tor --all --log notice

 ...

 Starting ./tor/src/or/tor...

   May 24 12:29:31.192 [notice] Tor 0.3.1.0-alpha-dev (git-
 44102714460aafe5) running on Linux with Libevent 2.0.16-stable, OpenSSL
 1.0.1, Zlib 1.2.3.4, Liblzma N/A, and Libzstd N/A.
   May 24 12:29:31.192 [notice] Tor can't help you if you use it wrong!
 Learn how to be safe at
 https://www.torproject.org/download/download#warning
   May 24 12:29:31.192 [notice] This version is not a stable Tor release.
 Expect more bugs than usual.
   May 24 12:29:31.192 [notice] Read configuration file
 "/home/atagar/Desktop/stem/test/data/torrc".
   May 24 12:29:31.197 [warn] ControlPort is open, but no authentication
 method has been configured.  This means that any program on your computer
 can reconfigure your Tor.  That's bad!  You should upgrade your Tor
 controller as soon as possible.
   May 24 12:29:31.198 [notice] Opening Socks listener on 127.0.0.1:1112
   May 24 12:29:31.198 [notice] Opening Control listener on 127.0.0.1:
   May 24 12:29:31.000 [notice] Bootstrapped 0%: Starting
   May 24 12:29:32.000 [notice] Starting with guard context "default"
   May 24 12:29:32.000 [notice] Bootstrapped 80%: Connecting to the Tor
 network
   done (1 seconds)

 Running tests...

 ... everything passes...
 }}}

 Per chance any chroots or other interesting twists?

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

Re: [tor-bugs] #22365 [Core Tor/Stem]: test.integ.installation expects cwd to be the top of the stem source tree

[Tor Bug Tracker & Wiki]

#22365: test.integ.installation expects cwd to be the top of the stem source 
tree
---+
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID:  #22301 | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Fix pushed - thanks for the catch!

 https://gitweb.torproject.org/stem.git/commit/?id=2c239e2

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22366 [Core Tor/Stem]: run_tests.py can't find tor via relative pathname if cwd not the top of the stem tree

[Tor Bug Tracker & Wiki]

#22366: run_tests.py can't find tor via relative pathname if cwd not the top of 
the
stem tree
---+
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #22301
   Points: |   Reviewer:
  Sponsor: |
---+
 When running `run_tests.py` with a current working directory that's not
 the top of the stem source tree, it can't find a `tor` binary via a
 relative pathname.  This prevents `make test-stem` from working in the tor
 source tree.  (`run_tests.py` seems to mostly work if given a relative
 pathname to `tor` when run from the top of the stem source tree.)

 {{{
 tlyu@arcadia:~/src/tor$ ../stem/run_tests.py --tor ./src/or/tor --all
 --log notice --target RUN_ALL
 }}}

 produces many errors such as

 {{{
 Starting ./src/or/tor...

   failed to start tor: './src/or/tor' doesn't exist
 }}}

 A workaround is to provide an absolute pathname for the `tor` binary, like

 {{{
 tlyu@arcadia:~/src/tor$ ../stem/run_tests.py --tor `pwd`/src/or/tor --all
 --log notice --target RUN_ALL
 }}}

 but it would be nice if the relative pathname also worked.  (Adapting the
 `make test-stem` rule in tor is also a possibility.)

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

Re: [tor-bugs] #22365 [Core Tor/Stem]: test.integ.installation expects cwd to be the top of the stem source tree

[Tor Bug Tracker & Wiki]

#22365: test.integ.installation expects cwd to be the top of the stem source 
tree
---+
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22301 | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Ahhh! I see what I was doing wrong. Got a repro now - thanks for reporting
 this!

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

[tor-bugs] #22365 [Core Tor/Stem]: test.integ.installation expects cwd to be the top of the stem source tree

[Tor Bug Tracker & Wiki]

#22365: test.integ.installation expects cwd to be the top of the stem source 
tree
---+
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #22301
   Points: |   Reviewer:
  Sponsor: |
---+
 Running `run_tests.py` from a current working directory that isn't the top
 of the stem source tree appears to cause `test.integ.installation` to
 fail.  `test.integ.installation` does succeed when run from the top of the
 stem source tree.

 It should work when run from the top of the tor source tree, as required
 by the `make test-stem` rules in tor.  Alternatively, clearly document
 that the tests only work properly when run from the top of the stem source
 tree and adjust the `make test-stem` rules in tor to compensate.  (It
 seems that almost all of the other tests work when run with a working
 directory outside of the stem source tree, so it would be nice if this one
 did as well.)

 {{{
 tlyu@arcadia:~/src/tor$ ../stem/run_tests.py --tor `pwd`/src/or/tor --all
 --log notice --target RUN_ALL --test test.integ.installation
 }}}

 (note that the
 {{{
 --tor `pwd`/src/or/tor`
 }}}
 is needed to work around another issue with relative pathnames)

 {{{
 TESTING FAILED (11 seconds)
   [RUN_NONE] test_sdist (test.integ.installation.TestInstallation) ...
 FAIL
 }}}

 I can provide more complete logs if needed, but it seems like it should be
 easy enough to replicate the failure condition.  (Please let me know if
 you're having trouble replicating 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] #22301 [Core Tor/Stem]: make test-stem doesn't work

[Tor Bug Tracker & Wiki]

#22301: make test-stem doesn't work
---+
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 > make test-stem (and thus make test-full) still fails from the top of the
 tor source tree

 Gotcha. I tried running the tests from various relative paths when making
 these patches but couldn't repro the issue...

 {{{
 % env -i ./stem/run_tests.py --all --tor tor/tor/src/or/tor
 % env -i ../run_tests.py --all --tor ../../tor/tor/src/or/tor
 }}}

 Maybe a bug with the make target rather than stem?

 > ... expects its working directory to be the top of the stem source tree
 and not anywhere else

 Hmmm, the test calls os.chdir() in an effort to avoid these issues...

 https://gitweb.torproject.org/stem.git/tree/test/integ/installation.py#n34

 Are you able to come up with a repro invoking run_tests.py directly rather
 than tor's make target?

 > Not having a system tor installed might be unusual but I think we should
 support that use case.

 Absolutely agreed, and this is a miss on my side. Puzzled though. I'm
 expecting the 'env -i' to allow me to repro this...

 > I'm sorry if I misspoke about the $PATH issue. I meant that I don't have
 a tor binary installed on this system, and somehow the tests were trying
 to look for a tor binary in my $PATH, not that I had an empty or missing
 $PATH environment variable.

 Oh no, you didn't misspeak. I'm dropping my PATH in an effort to repro the
 issue you mentioned. That's all.

 > I think I will make separate child tickets because these issues are
 partially separable.

 Sounds good!

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

Re: [tor-bugs] #22255 [Core Tor/Tor]: Frequent OOM kills of tor process

[Tor Bug Tracker & Wiki]

#22255: Frequent OOM kills of tor process
--+
 Reporter:  DeS   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by DeS):

 As proposed by arma I ran this command on a fresh compiled alpha tor.

 nohup valgrind --leak-check=yes --error-limit=no --undef-value-errors=no
 src/or/tor geoipfile src/config/geoip -f /etc/tor/torrc2 &>valgrind.out &

 Somewhere during the last day this process stopped for no know reason. I
 attach the output:
 https://trac.torproject.org/projects/tor/attachment/ticket/22255/valgrind.txt

 Hope that helps.

 Frankly our tor serivce is almost not maintainable anymore. I will try a
 last think and check for processes by script and restart. But this problem
 is serious.

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

Re: [tor-bugs] #22301 [Core Tor/Stem]: make test-stem doesn't work

[Tor Bug Tracker & Wiki]

#22301: make test-stem doesn't work
---+
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by catalyst):

 Thanks for looking into these and working on patches.

 I tried your latest changes and unfortunately still see all the failures
 that I reported above.  The tests indeed almost all work when I run from
 the top of the stem source tree, but that wasn't the problem that toby_
 initially reported.

 * `make test-stem` (and thus `make test-full`) still fails from the top of
 the tor source tree, failing to find `./src/or/tor`.  This should not be
 an unusual situation because `CodingStandards.md` recommends that people
 run `make test-full` to test their changes.  (If we don't expect `make
 test-full` to work, we should update `CodingStandards.md`.)
 * Applying the workaround of specifying an absolute path to the `tor`
 binary in the source tree when running `make test-stem` still produces the
 same errors in `test.integ.install` and `test.integ.process`.  I infer
 that `test.integ.install` expects its working directory to be the top of
 the stem source tree and not anywhere else, but this can't work with the
 current `make test-stem` rules in the tor source tree.
 * Running `./run_tests.py` from the top of the stem source tree (and
 giving it an absolute path to the `tor` binary in the tor source tree)
 clears the install problem but not the process problem.  Not having a
 system tor installed might be unusual but I think we should support that
 use case.  (Also we shouldn't be testing the system tor unless we
 specifically intend to.  Do we actually intend to test the system tor
 here?)

 I'm sorry if I misspoke about the `$PATH` issue.  I meant that I don't
 have a `tor` binary installed on this system, and somehow the tests were
 trying to look for a `tor` binary in my `$PATH`, not that I had an empty
 or missing `$PATH` environment variable.

 I saw that Jenkins runs automated tests in the stem source tree, but I
 didn't see anything that runs `make test-stem` or `make test-full` from
 the tor source tree, which is something that we should make sure works if
 we're recommending that developers run that when testing proposed changes
 to tor.

 I think I will make separate child tickets because these issues are
 partially separable.

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

Re: [tor-bugs] #22302 [Core Tor/Chutney]: test-network.sh uses a deprecated arithmetic syntax

[Tor Bug Tracker & Wiki]

#22302: test-network.sh uses a deprecated arithmetic syntax
--+-
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by catalyst):

 I labeled it WIP partly to prevent accidental click-merge and partly to
 indicate it needed review.  Feel free to ignore that, or I can delete the
 WIP notation if you want.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #584, #925, #1075, #1099, ...

[Tor Bug Tracker & Wiki]

Batch modification to #584, #925, #1075, #1099, #1136, #1247, #2149, #2506, 
#2681, #2878, #2915 by nickm:
keywords to sponsor8-maybe

--
Tickets URL: 

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

Re: [tor-bugs] #1270 [Core Tor/Tor]: Spec conformance issues on get_next_token() reported by outofwords (was: Spec conformance issues reported by outofwords)

[Tor Bug Tracker & Wiki]

#1270: Spec conformance issues on get_next_token() reported by outofwords
+--
 Reporter:  Sebastian   |  Owner:  nickm
 Type:  defect  | Status:  needs_revision
 Priority:  Low |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:  0.2.1.22
 Severity:  Normal  | Resolution:  None
 Keywords:  tor-client parser tor-spec  |  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] #22364 [Applications/Tor Browser]: nexusmods.com broken in Tor Browser

[Tor Bug Tracker & Wiki]

#22364: nexusmods.com broken in Tor Browser
--+--
 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:
--+--

Comment (by cypherpunks):

 Switching tabs uses XHR which returns `403 Forbidden` which what looks
 like a Cloudflare captcha page. This can be verified by using the Network
 tab in the Firefox Developer Tools and switching tabs.

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

Re: [tor-bugs] #21769 [Webpages/Website]: CSP blocks Tor Debian Instructions' Javascript

[Tor Bug Tracker & Wiki]

#21769: CSP blocks Tor Debian Instructions' Javascript
--+--
 Reporter:  tom   |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arthuredelstein):

 FWIW, here is a list of inline scripts I found by grepping the website
 source code. These are presumably all getting blocked by our CSP. None of
 these scripts seems particularly important, but if someone has time these
 would probably be good to clean up.

 {{{
 // Offers search provider for torbutton (probably not needed):
 ./docs/torbutton/index.html.en:

Re: [tor-bugs] #22019 [Webpages/Website]: Integrate a Captcha and Honeypot

[Tor Bug Tracker & Wiki]

#22019: Integrate a Captcha and Honeypot
--+
 Reporter:  hiro  |  Owner:  hiro
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:  #22013| Points:
 Reviewer:|Sponsor:
--+
Changes (by hiro):

 * 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] #22018 [Webpages/Blog]: Prevent users from being individually tracked in Drupal’s logs.

[Tor Bug Tracker & Wiki]

#22018: Prevent users from being individually tracked in Drupal’s logs.
---+
 Reporter:  hiro   |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+
Changes (by hiro):

 * 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] #22016 [Webpages/Blog]: Create a calendar widget

[Tor Bug Tracker & Wiki]

#22016: Create a calendar widget
---+
 Reporter:  hiro   |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+
Changes (by hiro):

 * 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] #22327 [Applications/Tor Browser]: First party isolation of Page Info

[Tor Bug Tracker & Wiki]

#22327: First party isolation of Page Info
+--
 Reporter:  arthuredelstein |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_information
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-7.0-must TorBrowserTeam201705R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arthuredelstein):

 Replying to [comment:3 gk]:
 > Replying to [comment:2 gk]:
 > > Hm, looking at that branch it seems we need
 32287fdd336a9ed2bbd52e71595fcb7e61394dc5 as well? Or am I missing
 something?

 Yes, sorry, I should have also mentioned that I backported that patch.

 > It seems you are missing the
 > {{{
 > +#include "nsSerializationHelper.h"
 > }}}
 > in that backported patch? I somehow doubt it would compile without it
 looking at the code.

 You're right. The branch builds, but the #include line somehow migrated
 from Ehsan's patch onto my patch. I have put it back into his patch and I
 have rebased the two patches onto the latest tor-browser-52.1.1esr-7.0-1
 branch. Here is the new result:
 https://github.com/arthuredelstein/tor-browser/commits/22327+1

 I rebuilt this new branch and ran the following manual test:

 1. add torbutton
 2. set extensions.torbutton.loglevel to 3
 3. open the Browser Console
 4. visit http://html5demo.com/video
 5. open Page Info
 6. observe "tor SOCKS" messages in the Browser Console

 When I ran this test, videos and images in the "media preview" box were
 correctly isolated to the content document's first party.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22364 [Applications/Tor Browser]: nexusmods.com broken in Tor Browser

[Tor Bug Tracker & Wiki]

#22364: nexusmods.com broken in Tor Browser
--+--
 Reporter:  cypherpunks   |  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:|
--+--
 A few weeks ago it was fine, however now there is a problem with loading
 pages on nexusmods.com. For example:

 www.nexusmods.com/skyrim/mods/83467/

 When you click on the tabs such as Files, Images, etc. the tab doesn't
 load and returns the letter "E"

 I wonder if this is caused by a bug or some hardening feature in Tor
 Browser

 Tested with Tor Browser 6.5.2 + Low Security Level

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

Re: [tor-bugs] #21915 [Core Tor/DirAuth]: Add a new directory authority: Nicholas Merrill

[Tor Bug Tracker & Wiki]

#21915: Add a new directory authority: Nicholas Merrill
--+
 Reporter:  dgoulet   |  Owner:
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ln5):

 * cc: ln5 (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] #22345 [Applications/Tor Browser]: Something wrong with NoScript 5.0.4

[Tor Bug Tracker & Wiki]

#22345: Something wrong with NoScript 5.0.4
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #22341 [Applications/Tor Browser]: Make sure to pick up zstd+lzma support for tor in Tor Browser

[Tor Bug Tracker & Wiki]

#22341: Make sure to pick up zstd+lzma support for tor in Tor Browser
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian, TorBrowserTeam201705  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #22320 [Applications/Tor Browser]: Referrer not hidden when comming from a .onion address

[Tor Bug Tracker & Wiki]

#22320: Referrer not hidden when comming from a .onion address
-+-
 Reporter:  pege |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by tokotoko):

 * cc: fdsfgs@… (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] #21862 [Applications/Tor Browser]: Make rust code in ESR 52 proxy safe

[Tor Bug Tracker & Wiki]

#21862: Make rust code in ESR 52 proxy safe
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201705R, |  Actual Points:
  tbb-7.0-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by gk):

 * status:  new => needs_review
 * keywords:  ff52-esr, TorBrowserTeam201705, tbb-7.0-must => ff52-esr,
 TorBrowserTeam201705R, tbb-7.0-must


Comment:

 `bug_21862` (https://gitweb.torproject.org/user/gk/tor-
 browser.git/commit/?h=bug_21862=44fc4b2675d36b79d6d0cf374d4fcc74aebb1f1f)
 has a patch for review.

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

Re: [tor-bugs] #3056 [Core Tor/Tor]: tor/vidalia, debian libevent-2.0-5 eventdns: Address mismatch? etc.

[Tor Bug Tracker & Wiki]

#3056: tor/vidalia, debian libevent-2.0-5 eventdns: Address mismatch? etc.
-+-
 Reporter:  freeeveryone4ever|  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.3.10-alpha
 Severity:  Normal   | Resolution:
 Keywords:  libevent eventdns tor-relay logging  |  Actual Points:  0
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_information => needs_review
 * actualpoints:   => 0
 * milestone:  Tor: unspecified => Tor: 0.3.2.x-final


Comment:

 See my branch `bug3056`.  It just rate-limits the message, rewrites it,
 and tries to apply SafeLogging.

 I'm not sure SafeLogging is correct here -- these are the IP addresses of
 our apparent DNS spoofers, not of our clients

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

Re: [tor-bugs] #3056 [Core Tor/Tor]: tor/vidalia, debian libevent-2.0-5 eventdns: Address mismatch? etc.

[Tor Bug Tracker & Wiki]

#3056: tor/vidalia, debian libevent-2.0-5 eventdns: Address mismatch? etc.
-+-
 Reporter:  freeeveryone4ever|  Owner:
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.3.10-alpha
 Severity:  Normal   | Resolution:
 Keywords:  libevent eventdns tor-relay logging  |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  libevent eventdns tor-relay => libevent eventdns tor-relay
 logging
 * points:   => 2
 * severity:   => Normal


Comment:

 Our solution here should probably be to rate-limit the message and scrub
 the IP, while making it clear that the actual problem is "these are indeed
 not from configured resolvers"

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