Re: [tor-bugs] #20419 [Metrics/Censorship analysis]: iran has banned tor successfully

[Tor Bug Tracker & Wiki]

#20419: iran has banned tor successfully
-+-
 Reporter:  ufd33|  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ufd33):

 Replying to [comment:1 ufd33]:
 > [[BR]]iran is the No. 2 in Top-10 countries by possible censorship
 events:
 >
 > https://metrics.torproject.org/userstats-censorship-events.html

 and now iran is the No. 1 :

 https://metrics.torproject.org/userstats-censorship-events.html

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

Re: [tor-bugs] #20419 [Metrics/Censorship analysis]: iran has banned tor successfully

[Tor Bug Tracker & Wiki]

#20419: iran has banned tor successfully
-+-
 Reporter:  ufd33|  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ufd33):

 new reports shows disaster in iran :

 https://metrics.torproject.org/userstats-relay-
 country.html?start=2016-09-01=2016-11-02=ir=points

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20532 [Core Tor/Tor]: Make sure directory_initiate_command_rend handles pluggable transports correctly

[Tor Bug Tracker & Wiki]

#20532: Make sure directory_initiate_command_rend handles pluggable transports
correctly
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  bridge-client, bridge-bypass
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 When a relay is configured as a bridge, a user reports this can lead to
 direct connections being made to the relay/bridge, even when a pluggable
 transport is configured. We have been unable to confirm this.

 ​https://lists.torproject.org/pipermail/tor-dev/2016-November/011618.html

 We should check directory_initiate_command_rend (the linked connection
 case), and connection_or_connect to make sure it is not possible for a
 connection to go directly to a configured bridge when a transport is set
 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] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [comment:14 rubiate]:
 > I set up two new relays:
 > [...]
 > Rough timeline:
 >
 > 10:36 Both start up
 > [...] both request the consensus every minute
 > 10:41 they reach a fail count of 10

 What is wrong with your relay set-up such that they both failure to get a
 consensus at bootstrap? :)

 Are you firewalled in some weird way? Are they trying to fetch it from
 fallbackdirs and those are surprisingly faily? Are they trying from
 directory authorities and our authorities are no good?

 Anyway, it looks like 'revert' is the winner, but it would still be great
 to learn what is so helpful about your test environment that it triggers
 this bug so well.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20531 [Core Tor/Tor]: rewrite_node_address_for_bridge and networkstatus_set_current_consensus can conflict

[Tor Bug Tracker & Wiki]

#20531: rewrite_node_address_for_bridge and networkstatus_set_current_consensus 
can
conflict
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  bridge-client, bridge-bypass
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+--
 When a relay is configured as a bridge, both
 rewrite_node_address_for_bridge and networkstatus_set_current_consensus
 update that relay's node, as do any descriptor downloads.

 This can be problematic if the details they use differ.

 One user reports this can lead to direct connections being made to the
 relay/bridge, even when a pluggable transport is configured. We have been
 unable to confirm this.

 https://lists.torproject.org/pipermail/tor-dev/2016-November/011618.html

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

Re: [tor-bugs] #20528 [Core Tor/Tor]: Defend against bridge bypass with misconfigured bridges

[Tor Bug Tracker & Wiki]

#20528: Defend against bridge bypass with misconfigured bridges
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bridge-client, bridge-bypass  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * milestone:  Tor: 0.3.0.x-final => Tor: 0.2.???


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

Re: [tor-bugs] #20530 [Core Tor/Tor]: undefined reference to 'munmap' and 'mmap' building tor on Windows

[Tor Bug Tracker & Wiki]

#20530: undefined reference to 'munmap' and 'mmap' building tor on Windows
+-
 Reporter:  ice |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  windows, mingw  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by teor):

 * keywords:   => windows, mingw


Comment:

 configure might be setting HAVE_SYS_MMAN_H incorrectly.

 When you run configure, do you have any configure lines that mention
 mman.h, mmap, munmap, or getpagesize?

 Clearly you have some header than mentions mmap and munmap.
 Do you need to link to a special library to get access to mmap and munmap?

 Do any of your headers mention getpagesize?

 What happens when you disable HAVE_SYS_MMAN_H in orconfig.h?

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

Re: [tor-bugs] #20530 [Core Tor/Tor]: undefined reference to 'munmap' and 'mmap' building tor on Windows

[Tor Bug Tracker & Wiki]

#20530: undefined reference to 'munmap' and 'mmap' building tor on Windows
--+-
 Reporter:  ice   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by arma):

 * component:  - Select a component => Core Tor/Tor


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

[tor-bugs] #20530 [- Select a component]: undefined reference to 'munmap' and 'mmap' building tor on Windows

[Tor Bug Tracker & Wiki]

#20530: undefined reference to 'munmap' and 'mmap' building tor on Windows
--+-
 Reporter:  ice   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Using MinGW64 version 4.7.3-- thread model win32-- running naively (no
 cross-compile) inside msys2, I tried to build the tor-0.2.8.9 source
 downloaded from torproject.org.

 While configuring the build, I noticed I had to build and install
 libevent, openssl, and zlib, which I did. After that Configure didn't fail
 anymore, and I proceeded to build tor by issuing "make". It seemed to go
 pretty well until the linker wanted to build tor.exe. It failed and
 complained about undefined references. Here is the output after issuing
 the make command again.

 $ make
 make  all-am
 make[1]: Entering directory `/e/users/v/Desktop/nfolder/tor-0.2.8.9'
   CC   src/common/compat.o
 src/common/compat.c: In function 'tor_mmap_file':
 src/common/compat.c:273:3: warning: implicit declaration of function
 'getpagesize' [-Wimplicit-function-declaration]
   AR   src/common/libor.a
   CC   src/common/src_common_libor_testing_a-compat.o
 src/common/compat.c: In function 'tor_mmap_file':
 src/common/compat.c:273:3: warning: implicit declaration of function
 'getpagesize' [-Wimplicit-function-declaration]
   AR   src/common/libor-testing.a
   CCLD src/or/tor.exe
 src/common/libor.a(compat.o): In function `tor_munmap_file':
 e:\users\v\Desktop\nfolder\tor-0.2.8.9/src/common/compat.c:312: undefined
 reference to `munmap'
 src/common/libor.a(compat.o): In function `tor_mmap_file':
 e:\users\v\Desktop\nfolder\tor-0.2.8.9/src/common/compat.c:285: undefined
 reference to `mmap'
 collect2.exe: error: ld returned 1 exit status
 make[1]: *** [src/or/tor.exe] Error 1
 make[1]: Leaving directory `/e/users/v/Desktop/nfolder/tor-0.2.8.9'
 make: *** [all] Error 2


 I have googled around and have not found an answer to solve this problem.

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

Re: [tor-bugs] #20377 [Applications/Tor Browser]: Tor Browser crashes when certain prefs are forced via autoconfig.js.

[Tor Bug Tracker & Wiki]

#20377: Tor Browser crashes when certain prefs are forced via autoconfig.js.
--+--
 Reporter:  yawning   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:  tbb-sandboxing|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by yawning):

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


Comment:

 Weird, I'm having trouble reproducing this.  I might have just been
 setting up my mozilla.cfg file incorrectly.  I'll close this for now, till
 it rears it's ugly head again.

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

Re: [tor-bugs] #20484 [Core Tor/Tor]: HiddenServiceDir must already exist when making a Single Onion Service

[Tor Bug Tracker & Wiki]

#20484: HiddenServiceDir must already exist when making a Single Onion Service
--+
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, single-onion  |  Actual Points:  0.5
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_revision => 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] #20529 [Core Tor/Tor]: Check the directory for each rend service, not just the last one

[Tor Bug Tracker & Wiki]

#20529: Check the directory for each rend service, not just the last one
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:  0.2
Parent ID:  #20484| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => needs_review
 * actualpoints:   => 0.2


Comment:

 The last commit on my branch bug20484_029 has a fix for this issue.
 (It uses the refactoring in that branch.)

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

Re: [tor-bugs] #20484 [Core Tor/Tor]: HiddenServiceDir must already exist when making a Single Onion Service

[Tor Bug Tracker & Wiki]

#20484: HiddenServiceDir must already exist when making a Single Onion Service
--+
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, single-onion  |  Actual Points:  0.5
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * actualpoints:   => 0.5


Comment:

 See my branch bug20484_029 on github, which also has a fix for #20529.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20529 [Core Tor/Tor]: Check the directory for each rend service, not just the last one

[Tor Bug Tracker & Wiki]

#20529: Check the directory for each rend service, not just the last one
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.2-alpha
 Severity:  Normal|   Keywords:  tor-hs
Actual Points:|  Parent ID:  #20484
   Points:  0.2   |   Reviewer:
  Sponsor:|
--+
 In #13942, we added code to check that a configured hidden service's
 directory had the correct permissions.

 But the fix committed in 85bfad1 in tor-0.2.6.2-alpha only checked the
 last hidden service configured.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20528 [Core Tor/Tor]: Defend against bridge bypass with misconfigured bridges

[Tor Bug Tracker & Wiki]

#20528: Defend against bridge bypass with misconfigured bridges
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  bridge-client, bridge-bypass
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+--
 Currently, we keep our consensus and guards and nodes, even after an
 options transition.

 A user reports that this may bypass bridges when bridge fingerprints are
 misconfigured, and we switch between bridge client and regular client
 mode:
 https://lists.torproject.org/pipermail/tor-dev/2016-November/011618.html
 This bypass is likely timing-related - I suspect it only occurs if tor
 tries a connection to the bridge before the new bridges and pluggable
 transports are properly configured.

 So we should reload the cached consensus, reset downloads and reconfigure
 guards after options transitions.

 Conceptually, we want to do something like:
 (it currently doesn't work due to assertions, so we probably want to
 conditionalise parts of it on has_reasonably_live_consensus() or
 something)
 {{{
 diff --git a/src/or/config.c b/src/or/config.c
 index fef1208..4ecf0ba 100644
 --- a/src/or/config.c
 +++ b/src/or/config.c
 @@ -1183,6 +1183,13 @@ consider_adding_dir_servers(const or_options_t
 *options,
for (cl = options->FallbackDir; cl; cl = cl->next)
  if (parse_dir_fallback_line(cl->value, 0)<0)
return -1;
 +
 +  /* Reset the consensus, because the authorities might have changed */
 +  time_t now = time(NULL);
 +  networkstatus_reset_warnings();
 +  router_reload_consensus_networkstatus();
 +  routerlist_retry_directory_downloads(now);
 +
return 0;
  }

 @@ -1889,6 +1896,11 @@ options_act(const or_options_t *old_options)
circuit_mark_all_unused_circs();
circuit_mark_all_dirty_circs_as_unusable();
revise_trackexithosts = 1;
 +
 +  /* And reload the consensus, which also updates guards (and
 bridges) */
 +  time_t now = time(NULL);
 +  router_reload_consensus_networkstatus();
 +  routerlist_retry_directory_downloads(now);
  }

  if (!smartlist_strings_eq(old_options->TrackHostExits,
 }}}

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => merge_ready


Comment:

 (Nick, before you merge be sure to read the new commit message I pretended
 that you wrote for b2f82d45b, just in case you don't want to have said
 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] #20023 [Applications/Tor Browser]: Upgrade Go to 1.7.3

[Tor Bug Tracker & Wiki]

#20023: Upgrade Go to 1.7.3
--+
 Reporter:  dcf   |  Owner:  dcf
 Type:  task  | Status:
  |  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian TorBrowserTeam201611R  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dcf):

 * keywords:  tbb-gitian => tbb-gitian TorBrowserTeam201611R
 * status:  new => needs_review


Comment:

 Here are patches for review. On the maint-6.0 branch, you will need to
 apply both:
  * attachment:0001-Upgrade-Go-to-1.6.3.patch
  * attachment:0002-Bug-20023-Upgrade-Go-to-1.7.3.patch
 On the master branch, you only need:
  * attachment:0002-Bug-20023-Upgrade-Go-to-1.7.3.patch

 For the SDK version issue in comment:8, I opened an upstream issue:
 https://github.com/golang/go/issues/17732. Maybe they can shed some light
 on whether the problematic CFLAGS are intended. In the patches above, my
 workaround is just to patch one file:
 {{{
 sed -i -e '/^#cgo CFLAGS:/s/-D__MAC_OS_X_VERSION_MAX_ALLOWED=1060//'
 crypto/x509/root_cgo_darwin.go
 }}}

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 Replying to [comment:37 arma]:
 > Replying to [comment:31 nickm]:
 > > What if we go with option (3) putting both patches in both?
 >
 > My {{{bug19969_028_alt}}} branch now implements this idea.
 >
 > And my {{{bug19969_028_squashed}}} branch is the one that we would
 actually want to merge.

 They look good to me, and work in short-term chutney testing.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by arma):

 Replying to [comment:31 nickm]:
 > What if we go with option (3) putting both patches in both?

 My {{{bug19969_028_alt}}} branch now implements this idea.

 And my {{{bug19969_028_squashed}}} branch is the one that we would
 actually want to merge.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 Replying to [comment:35 teor]:
 > Oh, and two compiler warnings:
 > {{{
 > src/or/main.c:732:6: warning: no previous prototype for
 'tell_event_loop_to_finish' [-Wmissing-prototypes]
 >  void tell_event_loop_to_finish(void)
 >   ^
 > src/or/main.c:732:6: warning: no previous prototype for
 'tell_event_loop_to_finish' [-Wmissing-prototypes]
 >  void tell_event_loop_to_finish(void)
 >   ^
 > }}}

 Sorry, this was a bad merge on my part.

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

Re: [tor-bugs] #20484 [Core Tor/Tor]: HiddenServiceDir must already exist when making a Single Onion Service

[Tor Bug Tracker & Wiki]

#20484: HiddenServiceDir must already exist when making a Single Onion Service
--+
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, single-onion  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:7 teor]:
 > It still fails:
 > `src/or/tor HiddenServiceDir `mktemp -d -u` HiddenServicePort 80
 DataDirectory `mktemp -d -u` HiddenServiceNonAnonymousMode 1
 HiddenServiceSingleHopMode 1 SocksPort 0`
 > likely because we attempt to poison the directory before the keys are
 created.
 >
 > (I want to add the unit test equivalent of this - we could call the
 existing unit test with a parameter that says whether to create each
 directory or not.)
 >
 > But it's part of the way there, I think we just need to call
 `rend_service_check_and_create_private_dir` before poisoning as well.

 Sorry, I was wrong about this, it turns out I had compiled the wrong code.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 Oh, and two compiler warnings:
 {{{
 src/or/main.c:732:6: warning: no previous prototype for
 'tell_event_loop_to_finish' [-Wmissing-prototypes]
  void tell_event_loop_to_finish(void)
   ^
 src/or/main.c:732:6: warning: no previous prototype for
 'tell_event_loop_to_finish' [-Wmissing-prototypes]
  void tell_event_loop_to_finish(void)
   ^
 }}}

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 Oh, and arma/bug19969_02[89]_alt introduce a spacing issue:
 {{{
 void tell_event_loop_to_finish(void)
 }}}
 should be:
 {{{
 void
 tell_event_loop_to_finish(void)
 }}}

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

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Oh, and because we have bad directory mirrors serving out of date
 consensuses repeatedly?

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 Code reviews:

 nickm/bug19969_028_small and arma/bug19969_02[89]_alt seem to be quite
 small changes.
 They make sense, I am a little concerned about the extra events in the
 arma patch[es].

 I wonder if it would be possible to unit test or integration test these?

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

Re: [tor-bugs] #17773 [Core Tor/Tor]: Should clients avoid using guards that lost the Guard flag?

[Tor Bug Tracker & Wiki]

#17773: Should clients avoid using guards that lost the Guard flag?
---+--
 Reporter:  arma   |  Owner:  arma
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201606  |  Actual Points:
Parent ID: | Points:  medium?
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 Replying to [comment:18 cypherpunks]:
 > What is supposed to happen if the guard flag is dropped while the client
 is connected?

 I'm not sure what the code does, but I expect that it would leave existing
 circuits alone, and opt to use a different first hop when making future
 circuits.

 > What is supposed to happen if the guard is set manually? Will tor refuse
 to build circuits?

 If you put a relay in your EntryNodes list, Tor should never care whether
 it has the Guard flag. See the code snippet from asn above where it checks
 {{{routerset_contains_node(options->EntryNodes,node)}}}.

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

Re: [tor-bugs] #17773 [Core Tor/Tor]: Should clients avoid using guards that lost the Guard flag?

[Tor Bug Tracker & Wiki]

#17773: Should clients avoid using guards that lost the Guard flag?
---+--
 Reporter:  arma   |  Owner:  arma
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201606  |  Actual Points:
Parent ID: | Points:  medium?
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 Replying to [ticket:17773 arma]:
 > What other aspects should we be considering here?

 See #20509 for a case where we want to take away the Guard flag from
 relays that are buggy and would make poor guards. In that case we would
 want clients to jump ship from those relays. And we either do it by taking
 away their Guard flag, or we do it by rejecting the relays from the
 network.

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

Re: [tor-bugs] #17773 [Core Tor/Tor]: Should clients avoid using guards that lost the Guard flag?

[Tor Bug Tracker & Wiki]

#17773: Should clients avoid using guards that lost the Guard flag?
---+--
 Reporter:  arma   |  Owner:  arma
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201606  |  Actual Points:
Parent ID: | Points:  medium?
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 Replying to [comment:11 arma]:
 > What's *supposed* to happen is that the client decides that its guard
 isn't Running anymore, so it moves on to another one, but it keeps the
 first one around for some months in case it comes back.

 For clarity, we currently think that this is what *does* happen in the
 code currently.

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

Re: [tor-bugs] #20509 [Core Tor/Tor]: Directory authorities should take away Guard flag from relays with #20499 bug

[Tor Bug Tracker & Wiki]

#20509: Directory authorities should take away Guard flag from relays with 
#20499
bug
+
 Reporter:  arma|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  028-backport, easy  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by arma):

 Replying to [comment:7 teor]:
 > Hang on, didn't we have a bug where clients would pick relays as their
 guard regardless of whether they had the Guard flag? How many versions ago
 was that?

 That was bug #17772 and its fix went into 0.2.7.6, which came out before
 0.2.8.1-alpha. Whereas directory guards went into 0.2.4.8-alpha. So
 clients running 0.2.4.x and 0.2.5.x and 0.2.6.x will have the #17772 bug.
 But I think they have bigger problems.

 > And do clients automatically get new guards when their existing guards
 lose the Guard flag? Or do they keep their old guards until they rotate?

 Great question. #17773 is the complicated mess you want to read to answer
 it. I *think* the summary of that ticket is that clients do in fact go
 find another Guard if their current one loses its flag. And we were
 thinking of changing that behavior, because it introduces other problems,
 but we haven't yet. Lucky us here.

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

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

[Tor Bug Tracker & Wiki]

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

 * keywords:  tbb-torbutton-conversion, TorBrowserTeam201610 => tbb-
 torbutton-conversion, TorBrowserTeam201610R
 * status:  needs_revision => needs_review


Comment:

 Thanks, gk, mcs and brade for your reviews!

 Replying to [comment:35 gk]:
 > It does, neat! One nit: could you put a comment above the JS code change
 explaining what is going on? (maybe pointing to #18175 additionally?)
 Good idea -- added.

 Replying to [comment:36 mcs]:
 > Kathy and I reviewed both patches. Here are a few comments on the
 Torbutton patch:
 > * In `torbutton_resizelistener.onStateChange`, the container variable
 can be removed.

 Done.

 > * The `extensions.torbutton.startup_resize_period` pref (aka
 `k_tb_tor_resize_warn_pref`) is never set to false and its value is never
 read, so it seems like it can be removed too.

 Removed.

 > * Since the call to `quantizeBrowserSize()` was removed, should the
 entire `src/chrome/content/content-sizer.js` file be removed? Or will that
 functionality be reinstated?

 Oops, I restored that function call.

 > And here are our comments on the browser (C++) patch:
 > * Please add a brief comment above
 `nsXULWindow::ResizeToRoundedDimensions()` to explain what it does (1000 x
 1000 maximum, width constrained to a multiple of 200, etc.)

 Added.

 > * `nsXULWindow::ResizeToRoundedDimensions()` should have `return NS_OK`
 at the end.

 Fixed.

 > * Are we sure that it is okay to remove support for the
 `extensions.torbutton.window.innerWidth` / `innerHeight` prefs? With the
 new patches, there is no way for the user to override the initial window
 size unless they disable fingerprinting protection. That might be okay,
 but I think people who have set these prefs in the past will be surprised.

 I have added two prefs: privacy.window.maxInnerWidth and
 privacy.window.maxInnerHeight. Hopefully these will be enough to solve any
 such problems.

 > A related issue (but not really for this ticket) is that constraining
 the width to a multiple of 200 might be annoying on Android devices that
 have narrow screens (old phones)?

 Good point. We could consider allowing smaller quantizations for small
 window sizes.

 Here's the new version:

 https://github.com/arthuredelstein/tor-browser/commit/19459+14
 https://github.com/arthuredelstein/torbutton/commit/19459+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] #20523 [Metrics/ExoneraTor]: Use metrics-lib for parsing descriptors

[Tor Bug Tracker & Wiki]

#20523: Use metrics-lib for parsing descriptors
+
 Reporter:  karsten |  Owner:
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by karsten):

 * status:  needs_review => needs_revision


Comment:

 Thanks for looking at the patch and for making those build changes.

 Would you mind making some more changes to that `build.xml`?  (I'm
 terrible at finding the correct Ant commands for all those things.)

  - `src/main/webapp/logging.properties` needs to be included in
 `exonerator.war` as `WEB-INF/classes/logging.properties` (currently
 missing).
  - `src/main/webapp/css/*` need to be included in `exonerator.war` as
 `css/*` (currently in root).
  - `src/main/webapp/images/*` need to be included in `exonerator.war` as
 `images/*` (currently in root).
  - `config` can be omitted from `exonerator.war` (currently in `WEB-
 INF/classes/`)
  - `src/main/resources/db/exonerator.sql` can be omitted from
 `exonerator.war` (currently in `WEB-INF/classes/db/`)
  - Is the `etc` property actually used?
  - Can you include `${libs}/gson-2.2.4.jar` in the classpath (was already
 missing before).

 Thanks!

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

Re: [tor-bugs] #20302 [Obfuscation/FTE]: FTE compilation in our gitian setup is broken for Windows with GCC 6.2.0

[Tor Bug Tracker & Wiki]

#20302: FTE compilation in our gitian setup is broken for Windows with GCC 6.2.0
--+
 Reporter:  gk|  Owner:  kpdyer
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Obfuscation/FTE   |Version:
 Severity:  Blocker   | Resolution:
 Keywords:  tbb-gitian, TorBrowserTeam201610  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dcf):

 * cc: dcf (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] #20497 [Applications/Tor Browser]: Add --enable-tor-browser-data-in-home-dir configure option and code

[Tor Bug Tracker & Wiki]

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

 * cc: brade, mcs (added)


Comment:

 Replying to [comment:2 attila]:
 > I don't see why the actual path chosen in the tor-data-in-home-dir case
 couldn't be whatever the group comes to consensus on.  If ~/.local/share
 /TorBrowser-Data (or whatever) is more in line with what you want that's
 fine by me.  I'm sure a lot of *BSD users do use some kind of desktop env
 (I don't but I'm arguably weird). This would be like everything else that
 adheres to the freedesktop.org spec.

 It is not a strong opinion, but I favor `$XDG_DATA_HOME/tor-browser` with
 a fallback to `~/.local/share/tor-browser/`.
 I also wonder if we want to add a runtime option for this as well (via a
 command line flag) so that users who want data to be stored under
 `$XDG_DATA_HOME` would always have that option available to them. On OSX
 we make a similar decision automatically based on where TorBrowser.app is
 installed, but I don't know how to do that on the Unix/Linux systems.

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

Re: [tor-bugs] #20524 [Core Tor/Tor]: Revise initial descriptor upload behavior for onion services

[Tor Bug Tracker & Wiki]

#20524: Revise initial descriptor upload behavior for onion services
--+-
 Reporter:  twim  |  Owner:
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, research  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by twim):

 * keywords:  tor-hs => tor-hs, research


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

Re: [tor-bugs] #20082 [Core Tor/Tor]: Lower initial descriptor upload delay for hidden services

[Tor Bug Tracker & Wiki]

#20082: Lower initial descriptor upload delay for hidden services
-+-
 Reporter:  twim |  Owner:  twim
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, research, review-group-11,   |  Actual Points:
  TorCoreTeam201611  |
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
 |  SponsorR-can
-+-
Changes (by twim):

 * 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] #19538 [Metrics/Atlas]: Replace raster glyphicons with vector icons for flags

[Tor Bug Tracker & Wiki]

#19538: Replace raster glyphicons with vector icons for flags
---+-
 Reporter:  twim   |  Owner:  phw
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by twim):

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


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

Re: [tor-bugs] #20527 [Core Tor/Tor]: Fix some unescaped printings of rendservice directories

[Tor Bug Tracker & Wiki]

#20527: Fix some unescaped printings of rendservice directories
--+--
 Reporter:  twim  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by twim):

 * status:  new => needs_review


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

[tor-bugs] #20527 [Core Tor/Tor]: Fix some unescaped printings of rendservice directories

[Tor Bug Tracker & Wiki]

#20527: Fix some unescaped printings of rendservice directories
--+-
 Reporter:  twim  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-


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

Re: [tor-bugs] #20526 [Core Tor/Tor]: Implement `rend_service_is_ephemeral()`

[Tor Bug Tracker & Wiki]

#20526: Implement `rend_service_is_ephemeral()`
--+--
 Reporter:  twim  |  Owner:
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by twim):

 * status:  new => needs_review


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

[tor-bugs] #20526 [Core Tor/Tor]: Implement `rend_service_is_ephemeral()`

[Tor Bug Tracker & Wiki]

#20526: Implement `rend_service_is_ephemeral()`
--+-
 Reporter:  twim  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Checking if directory is `NULL` is not so readable. Replace such checks
 with `rend_service_is_ephemeral()`.

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

Re: [tor-bugs] #20438 [Internal Services/Service - git]: Create tor-browser-bundle repo for serene

[Tor Bug Tracker & Wiki]

#20438: Create tor-browser-bundle repo for serene
-+
 Reporter:  serene   |  Owner:  tor-gitadm
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  pt tbb snowflake |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by Sebastian):

 * 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] #20122 [Internal Services/Tor Sysadmin Team]: Create VM for Tor Browser tests

[Tor Bug Tracker & Wiki]

#20122: Create VM for Tor Browser tests
-+-
 Reporter:  boklm|  Owner:  tpa
 Type:  task | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * status:  closed => reopened
 * resolution:  user disappeared =>


Comment:

 Sorry for lack of feedback on this.

 The main things this we will be doing from this host are:
 - distributing some static web content used to test Tor Browser
 - receiving some test reports through ssh, then archiving and publishing
 them (as static web content), and sending email summaries
 - downloading the Windows version of Tor Browser, uploading it to
 Virustotal, and creating a report of the results

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

Re: [tor-bugs] #20495 [Metrics/Censorship analysis]: China blocking of meek, 2016-10-19

[Tor Bug Tracker & Wiki]

#20495: China blocking of meek, 2016-10-19
-+-
 Reporter:  dcf  |  Owner:
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block cn meek |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:3 dcf]:
 > I tested [https://ftp.mozilla.org/pub/firefox/releases/45.2.0esr/linux-
 x86_64/en-US/ Firefox 45.2.0esr] (the basis of current Tor Browser 6.0.5)

 Maybe just a minor thing but 6.0.5 is based on 45.4.0esr as well. Both the
 stable and the alphas are usually using the same Firefox version. The
 exception so far has been the migration to a new ESR then the alpha was
 one release earlier already on the new one.

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

Re: [tor-bugs] #19043 [Core Tor/Tor]: prop224: Implementation of ESTABLISH_INTRO cell

[Tor Bug Tracker & Wiki]

#19043: prop224: Implementation of ESTABLISH_INTRO cell
-+-
 Reporter:  alec.heif|  Owner:  asn
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, 6.s194, |  Actual Points:
  TorCoreTeam201611, review-group-11 |
Parent ID:  #17241   | Points:  6
 Reviewer:  asn, dgoulet |Sponsor:
 |  SponsorR-must
-+-
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 Ok, dropping the hs_cell idea, it was way to confusing with the trunnel
 API prefixed `hs_cell_`.

 I've made two extra commits on top. First one is some comments/define
 naming cleanup and second one is some code... let's call that "code
 enhancement/" :).

 Still in `ticket19043_030_01`.

 @asn, if you think this is fine, I think we can move on to `merge_ready`.

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

Re: [tor-bugs] #14270 [Applications/Tor Browser]: Make Tor Browser work with Unix Domain Socket option

[Tor Bug Tracker & Wiki]

#14270: Make Tor Browser work with Unix Domain Socket option
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  project | Status:  closed
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-security, TorBrowserTeam201610  |  Actual Points:
Parent ID:  #19750  | Points:
 Reviewer:  |Sponsor:  SponsorU
+--
Changes (by gk):

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


Comment:

 We are done here (again), I 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] #20490 [Applications/Tor Browser]: Backport fix for assertion failure due to patch for #20304 (bug 1311275)

[Tor Bug Tracker & Wiki]

#20490: Backport fix for assertion failure due to patch for #20304 (bug 1311275)
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201610R,   |  Actual Points:
  GeorgKoppen201610  |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 This is now commit 3c39c36f1f0ad11dbf332b538bc71cc89336cbae on tor-
 browser-45.4.0esr-6.5-1, thanks.

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

Re: [tor-bugs] #20369 [Applications/Tor Browser]: Persistence between Firefox and the Tor Browser for getClientRects and AudioContext fingerprint.

[Tor Bug Tracker & Wiki]

#20369: Persistence between Firefox and the Tor Browser for getClientRects and
AudioContext fingerprint.
--+--
 Reporter:  RobinLinus|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-fingerprinting|  Actual Points:
Parent ID:  #13017| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * owner:   => tbb-team
 * keywords:   => tbb-fingerprinting
 * component:  - Select a component => Applications/Tor Browser


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

Re: [tor-bugs] #20472 [Core Tor/Tor]: circuit_pick_extend_handshake: Non-fatal assertion !(node_prev == NULL) failed

[Tor Bug Tracker & Wiki]

#20472: circuit_pick_extend_handshake: Non-fatal assertion !(node_prev == NULL)
failed
-+-
 Reporter:  cypherpunks  |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.3-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  regression, 029-backport,|  Actual Points:  0.5
  TorCoreTeam201611  |
Parent ID:   | Points:  0.3
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Looks good; merging to 029.

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

Re: [tor-bugs] #20262 [Core Tor/Tor]: Onion services startup time always gets revealed

[Tor Bug Tracker & Wiki]

#20262: Onion services startup time always gets revealed
---+---
 Reporter:  twim   |  Owner:  twim
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Major  | Resolution:  wontfix
 Keywords:  tor-hs, research, review-group-11  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  SponsorR-
   |  can
---+---
Changes (by twim):

 * status:  needs_revision => closed
 * resolution:   => wontfix


Comment:

 Okay, it seems to be that we don't starve for this option. And for now it
 just would make everything bloated.
 We can reopen it in case we need it afterwards.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20525 [Metrics/metrics-lib]: Be more careful when deleting extraneous local descriptor files

[Tor Bug Tracker & Wiki]

#20525: Be more careful when deleting extraneous local descriptor files
-+-
 Reporter:  karsten  |  Owner:  karsten
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 As found in
 [https://trac.torproject.org/projects/tor/ticket/18910#comment:95 this
 ticket], `DescriptorIndexCollector` deletes descriptor files from a
 previous or concurrent collect run if it doesn't collect those files
 itself.  This is unexpected behavior and differs from what
 `DescriptorCollectorImpl` does.  Let's fix this.

 Here's a minimal example (taken from that other ticket):

 {{{
 DescriptorCollector dc =
 DescriptorSourceFactory.createDescriptorCollector();
 dc.collectDescriptors("https://collector.torproject.org;,
 new String[] { "/recent/torperf/" }, 0L, new File("sync"), true);
 dc.collectDescriptors("https://collector.torproject.org;,
 new String[] { "/recent/exit-lists/" }, 0L, new File("sync"),
 true);
 }}}

 This is the (annotated) output of running this code (1) with the default
 `DescriptorIndexCollector`, (2) with `DescriptorCollectorImpl`, and (3) a
 fixed version of `DescriptorIndexCollector`:

 {{{
 $ java -cp bin/:lib/descriptor-1.5.0.jar:lib/slf4j-api-1.7.7.jar:lib
 /commons-compress-1.9.jar:lib/gson-2.2.4.jar Main
 $ du -hs sync/recent/*
  14Msync/recent/exit-lists
   0Bsync/recent/torperf# <- deleted, bad!
 $ rm -rf sync/
 $ java -cp bin/:lib/descriptor-1.5.0.jar:lib/slf4j-api-1.7.7.jar:lib
 /commons-compress-1.9.jar:lib/gson-2.2.4.jar
 -Ddescriptor.collector=org.torproject.descriptor.impl.DescriptorCollectorImpl
 Main
 $ du -hs sync/recent/*
  14Msync/recent/exit-lists
 3.0Msync/recent/torperf# <- not deleted, good!
 $ java -cp bin/:lib/descriptor-1.5.0-dev.jar:lib/slf4j-api-1.7.7.jar:lib
 /commons-compress-1.9.jar:lib/gson-2.2.4.jar Main
 $ du -hs sync/recent/*
  14Msync/recent/exit-lists
 3.0Msync/recent/torperf# <- not deleted, good!
 }}}

 Possible patch used in (3) above:

 {{{
 diff --git
 a/src/main/java/org/torproject/descriptor/index/DescriptorIndexCollector.java
 b/src/main/java/org/torproject/descriptor/index/DescriptorIndexCollector.java
 index d32f811..daef379 100644
 ---
 a/src/main/java/org/torproject/descriptor/index/DescriptorIndexCollector.java
 +++
 b/src/main/java/org/torproject/descriptor/index/DescriptorIndexCollector.java
 @@ -70,7 +70,8 @@ public class DescriptorIndexCollector implements
 DescriptorCollector {
  this.fetchRemoteFiles(index.path, remoteFiles, minLastModified,
  localDirectory, localFiles);
  if (deleteExtraneousLocalFiles) {
 -  this.deleteExtraneousLocalFiles(remoteFiles, localDirectory,
 localFiles);
 +  deleteExtraneousLocalFiles(remoteDirectories, remoteFiles,
 localDirectory,
 +  localFiles);
  }
}

 @@ -108,12 +109,16 @@ public class DescriptorIndexCollector implements
 DescriptorCollector {
  }
}

 -  static void deleteExtraneousLocalFiles(
 +  static void deleteExtraneousLocalFiles(String[] remoteDirectories,
SortedMap remoteFiles,
File localDir, SortedMap locals) {
  for (String localPath : locals.keySet()) {
 -  if (!remoteFiles.containsKey(localPath)) {
 -new File(localDir, localPath).delete();
 +  for (String remoteDirectory : remoteDirectories) {
 +if (localPath.startsWith(remoteDirectory)) {
 +  if (!remoteFiles.containsKey(localPath)) {
 +new File(localDir, localPath).delete();
 +  }
 +}
}
  }
}
 }}}

 I briefly thought about an alternative fix where we look at the actual
 `index.json` contents to decide whether a local descriptor file that we
 didn't care about in the current collect run would be safe to delete or
 not.  After all, we have that information, so we could as well use it.

 The two arguments against it are (1) that we'd change the previous
 behavior of `DescriptorCollector` in a somewhat backward-incompatible way
 and (2) that this code might be smarter than developers might think it is
 and hence confuse them in a bad way.

 I think I'd rather go with something like the patch above.

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

Re: [tor-bugs] #20278 [Core Tor/Tor]: cert-spec.txt contains incomplete reference / documentation for certificate types

[Tor Bug Tracker & Wiki]

#20278: cert-spec.txt contains incomplete reference / documentation for 
certificate
types
---+---
 Reporter:  patrickod  |  Owner:  dgoulet
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  tor-spec, review-group-11  |  Actual Points:
Parent ID: | Points:
 Reviewer:  nickm  |Sponsor:
---+---
Changes (by nickm):

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


Comment:

 Merged.  Long-term, the spec should refer to a proposal, but since the
 proposal is in-progress, we may as well refer to it as appropriate.

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

Re: [tor-bugs] #20082 [Core Tor/Tor]: Lower initial descriptor upload delay for hidden services

[Tor Bug Tracker & Wiki]

#20082: Lower initial descriptor upload delay for hidden services
-+-
 Reporter:  twim |  Owner:  twim
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, research, review-group-11,   |  Actual Points:
  TorCoreTeam201611  |
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
 |  SponsorR-can
-+-

Comment (by twim):

 Unmessing even further by detaching the discussion about initial shuffling
 of services to #20524. It's good to have this feature implemented
 separately.

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

Re: [tor-bugs] #19642 [Core Tor/Tor]: Add a descriptor line for Single Onion Services

[Tor Bug Tracker & Wiki]

#19642: Add a descriptor line for Single Onion Services
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, rsos, sos, prop224,  |  Actual Points:
  proposal, TorCoreTeam201611|
Parent ID:  #17238   | Points:  0.5
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-

Comment (by nickm):

 Suggestion for the torspec patch: Add a sentence like "Older versions of
 the Single Onion Service implementation did not include this line."

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

[tor-bugs] #20524 [Core Tor/Tor]: Revise initial descriptor upload behavior for onion services

[Tor Bug Tracker & Wiki]

#20524: Revise initial descriptor upload behavior for onion services
--+
 Reporter:  twim  |  Owner:
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 According to `rend-spec.txt`:
 {{{
When uploading descriptors, the hidden service needs to make sure that
descriptors for different clients are not uploaded at the same time
 (cf.
Section 1.1) which is also a limiting factor for the number of clients.
 }}}

 At the moment it's unclear how it should be implemented and why.

   * What is the threat model here?
   * How exactly descriptors should be uploaded?
   * In what range delays should be set?
   * How this will work along with absent delays after #20082?

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

Re: [tor-bugs] #20502 [Core Tor/Tor]: Setting UseBridges=1 UseEntryGuards=0 means you bypass your bridges

[Tor Bug Tracker & Wiki]

#20502: Setting UseBridges=1 UseEntryGuards=0 means you bypass your bridges
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  config|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 I'm fine with either idea. Implementor gets to pick. :)

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

Re: [tor-bugs] #20486 [Core Tor/Tor]: HiddenServiceDirectory is created if it doesn't exist

[Tor Bug Tracker & Wiki]

#20486: HiddenServiceDirectory is created if it doesn't exist
---+
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  tor-hs, easy, doc  |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:
---+
Changes (by nickm):

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


Comment:

 Lovely; merged!

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

Re: [tor-bugs] #20484 [Core Tor/Tor]: HiddenServiceDir must already exist when making a Single Onion Service

[Tor Bug Tracker & Wiki]

#20484: HiddenServiceDir must already exist when making a Single Onion Service
--+
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, single-onion  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Okay; you want to revise or should I?

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

Re: [tor-bugs] #20487 [Core Tor/Tor]: Should HiddenServiceNonAnonymousMode change default SocksPort to 0?

[Tor Bug Tracker & Wiki]

#20487: Should HiddenServiceNonAnonymousMode change default SocksPort to 0?
---+---
 Reporter:  teor   |  Owner:
 Type:  enhancement| Status:  closed
 Priority:  Low|  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Minor  | Resolution:  implemented
 Keywords:  single-onion, tor-hs, doc  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer:  teor   |Sponsor:
---+---
Changes (by nickm):

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


Comment:

 okay; merging!

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

Re: [tor-bugs] #20523 [Metrics/ExoneraTor]: Use metrics-lib for parsing descriptors

[Tor Bug Tracker & Wiki]

#20523: Use metrics-lib for parsing descriptors
+--
 Reporter:  karsten |  Owner:
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by iwakeh):

 Looks fine, nice to see all those lines replaced by standard-metrics-lib
 parsing!

 Please find a commit on top of that
 
[https://gitweb.torproject.org/user/iwakeh/exonerator.git/commit/?h=task-20523=ee2f00516037378a98657efd0c8ba2a37f03f385
 here] straightening out the project structure toward metrics project
 standards.
 And, please test thoroughly, if this still works as expected.

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

Re: [tor-bugs] #20486 [Core Tor/Tor]: HiddenServiceDirectory is created if it doesn't exist

[Tor Bug Tracker & Wiki]

#20486: HiddenServiceDirectory is created if it doesn't exist
---+
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, easy, doc  |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:
---+
Changes (by pastly):

 * status:  new => needs_review


Comment:

 Simple doc change

 https://github.com/pastly/public-tor/tree/ticket20486

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

Re: [tor-bugs] #14271 [Applications/Tor Browser]: Make Torbutton work with Unix Domain Socket option

[Tor Bug Tracker & Wiki]

#14271: Make Torbutton work with Unix Domain Socket option
-+-
 Reporter:  gk   |  Owner:  brade
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-torbutton, tbb-security, |  Actual Points:
  TorBrowserTeam201609   |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by mcs):

 #3967 was resolved as a duplicate.

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

Re: [tor-bugs] #3967 [Applications/Torbutton]: new identity feature could support ControlSocket

[Tor Bug Tracker & Wiki]

#3967: new identity feature could support ControlSocket
+---
 Reporter:  T(A)ILS developers  |  Owner:  mikeperry
 Type:  enhancement | Status:  closed
 Priority:  Low |  Milestone:
Component:  Applications/Torbutton  |Version:
 Severity:  Normal  | Resolution:  duplicate
 Keywords:  AffectsTails|  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by mcs):

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


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

Re: [tor-bugs] #20487 [Core Tor/Tor]: Should HiddenServiceNonAnonymousMode change default SocksPort to 0?

[Tor Bug Tracker & Wiki]

#20487: Should HiddenServiceNonAnonymousMode change default SocksPort to 0?
---+---
 Reporter:  teor   |  Owner:
 Type:  enhancement| Status:  merge_ready
 Priority:  Low|  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Minor  | Resolution:
 Keywords:  single-onion, tor-hs, doc  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer:  teor   |Sponsor:
---+---
Changes (by teor):

 * keywords:  single-onion, tor-hs => single-onion, tor-hs, doc
 * reviewer:   => teor
 * status:  needs_review => merge_ready


Comment:

 Looks good, nice simple doc change.

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

Re: [tor-bugs] #20484 [Core Tor/Tor]: HiddenServiceDir must already exist when making a Single Onion Service

[Tor Bug Tracker & Wiki]

#20484: HiddenServiceDir must already exist when making a Single Onion Service
--+
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, single-onion  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 It still fails:
 `src/or/tor HiddenServiceDir `mktemp -d -u` HiddenServicePort 80
 DataDirectory `mktemp -d -u` HiddenServiceNonAnonymousMode 1
 HiddenServiceSingleHopMode 1 SocksPort 0`
 likely because we attempt to poison the directory before the keys are
 created.

 (I want to add the unit test equivalent of this - we could call the
 existing unit test with a parameter that says whether to create each
 directory or not.)

 But it's part of the way there, I think we just need to call
 `rend_service_check_and_create_private_dir` before poisoning as well.

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

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:16 nickm]:
 > So, if we're truly on exponential backoff, no maximum could be too
 large, right?

 Technically, yes.

 But at some exponent, the wait time becomes indistinguishable from
 failure.
 (Which is why we need to make sure requests trigger a new attempt.)

 I guess this essentially implements hibernate mode then?

 And we could just put the failure count up to something quite high, let's
 say, at most, the failure number at which tor is waiting for the average
 time between tor stable releases?

 > I also wonder, why are these failure counts so high?

 Firstly, because they get incremented twice for each failure.

 {{{
 download_status_increment_failure() gets called with a status_code of 304

 update_consensus_networkstatus_downloads() gets called again, this time it
 stops at the call to connection_dir_count_by_purpose_and_resource() which
 returns 1 (equal to max_in_progress_conns)

 download_status_increment_failure() gets called again, this time with a
 status_code of 0 (as a result each 304 response results in the fail count
 being increased by 2)
 }}}

 And secondly, because the laptop was offline for 12? hours?

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

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 So, if we're truly on exponential backoff, no maximum could be too large,
 right?

 I also wonder, why are these failure counts so high?

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

Re: [tor-bugs] #20523 [Metrics/ExoneraTor]: Use metrics-lib for parsing descriptors

[Tor Bug Tracker & Wiki]

#20523: Use metrics-lib for parsing descriptors
+--
 Reporter:  karsten |  Owner:
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

 * cc: iwakeh (added)
 * status:  new => needs_review


Comment:

 Please review
 [https://gitweb.torproject.org/user/karsten/exonerator.git/log/?h=task-20523
 my task-20523 branch].

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

[tor-bugs] #20523 [Metrics/ExoneraTor]: Use metrics-lib for parsing descriptors

[Tor Bug Tracker & Wiki]

#20523: Use metrics-lib for parsing descriptors
+-
 Reporter:  karsten |  Owner:
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+-
 We're using metrics-lib for downloading descriptors from CollecTor, but
 we're still using our own parsing code.  Let's avoid duplicating code by
 using what metrics-lib provides.

 Also update to Java 7 and metrics-lib 1.5.0.

 Branch follows in a moment.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 This seems to be working fine (and consistently) on the test network:
 {{{
 Nov 02 01:58:09.000 [warn] http status 400 ("Looks like your keypair does
 not match its older value.") response from dirserver 'REDACTED1'. Please
 correct.
 Nov 02 01:58:09.000 [warn] http status 400 ("Looks like your keypair does
 not match its older value.") response from dirserver 'REDACTED2'. Please
 correct.
 }}}

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #20472, #20462, #20356, #20355, ...

[Tor Bug Tracker & Wiki]

Batch modification to #20472, #20462, #20356, #20355, #20354, #20082, #19899, 
#19642, #19293, #19291, #17238, #12600, #12595 by dgoulet:
keywords to TorCoreTeam201611

--
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] #17306 [Core Tor/Stem]: Split up controller.py's integ tests

[Tor Bug Tracker & Wiki]

#17306: Split up controller.py's integ tests
---+
 Reporter:  atagar |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  testing, easy  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by neel):

 * severity:   => Normal


Comment:

 I have not made all changes listed, but I have split the getinfo commands
 into separate commands as in this patch:

 https://gist.github.com/neelchauhan/2e76169143dc6e24ef69321fcd6d68fb

 Let me know if there are any issues with this patch.

 Also, the testing log is posted here:

 https://gist.github.com/neelchauhan/7b032d05083e85f52d31241a8999700e

 Thanks,
 Neel Chauhan
 ===
 https://www.neelc.org/

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

Re: [tor-bugs] #19043 [Core Tor/Tor]: prop224: Implementation of ESTABLISH_INTRO cell

[Tor Bug Tracker & Wiki]

#19043: prop224: Implementation of ESTABLISH_INTRO cell
-+-
 Reporter:  alec.heif|  Owner:  asn
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, 6.s194, |  Actual Points:
  TorCoreTeam201611, review-group-11 |
Parent ID:  #17241   | Points:  6
 Reviewer:  asn, dgoulet |Sponsor:
 |  SponsorR-must
-+-
Changes (by dgoulet):

 * keywords:  tor-hs, prop224, 6.s194, TorCoreTeam201610, review-group-11 =>
 tor-hs, prop224, 6.s194, TorCoreTeam201611, review-group-11
 * status:  needs_review => needs_revision
 * points:  3 => 6


Comment:

 I've reviewed and squashed-rebased on master in: `ticket19043_030_01`

 This is merge ready imo but I'll set this one in `needs_revision` for now
 as I'll do an attempt to break it down with the `hs_cell.{c|h}` idea and
 see if we like it as we discussed. If not, we'll move this one in
 `merge_ready` for nickm's 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] #3967 [Applications/Torbutton]: new identity feature could support ControlSocket

[Tor Bug Tracker & Wiki]

#3967: new identity feature could support ControlSocket
+
 Reporter:  T(A)ILS developers  |  Owner:  mikeperry
 Type:  enhancement | Status:  needs_revision
 Priority:  Low |  Milestone:
Component:  Applications/Torbutton  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  AffectsTails|  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by intrigeri):

 Yes, it looks like a subset of #14271.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 Replying to [comment:24 nickm]:
 > Replying to [comment:23 teor]:
 > > '''Requiring Ed25519'''
 > >
 > > Also, what are we going to do about `DISABLE_DISABLING_ED25519`?
 > > It's currently `#undef`, which means that a relay can drop its ed25519
 key whenever it wants.
 > > When are we going to turn it on? When 0.2.5 is no longer recommended?
 >
 >
 > That sounds plausible to me.  Or another option would be to look at
 historical metrics data to see how often relays run a recent version for a
 while, then drop back to an older one.  If the answer is "almost never"
 then we can just turn it on now.

 Split off #20522. I'm in favour of doing it soon, because it makes key
 pinning consistent.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20522 [Core Tor/Tor]: Enable DISABLE_DISABLING_ED25519

[Tor Bug Tracker & Wiki]

#20522: Enable DISABLE_DISABLING_ED25519
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-ed25519-proto
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+
 Split from #18319

 At some point, we should require relays that once had an ed25519 key
 associated with their RSA key to always have that key, rather than
 allowing them to drop back to a version that didn't support ed25519.

 (This means they need to use a new RSA key to downgrade to an older
 version of tor without ed25519, which is consistent with the pinning in
 #18319.)

 This means either:
 1a. waiting until 0.2.5 is no longer recommended, or
 1b. look at historical metrics data to see how often relays run a recent
 version for a while, then drop back to an older one. If the answer is
 "almost never" then we can just turn it on now.

 To implement this change, replace `#undef DISABLE_DISABLING_ED25519` with
 `#define DISABLE_DISABLING_ED25519`.

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

Re: [tor-bugs] #20522 [Core Tor/Tor]: Enable DISABLE_DISABLING_ED25519

[Tor Bug Tracker & Wiki]

#20522: Enable DISABLE_DISABLING_ED25519
---+
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-ed25519-proto  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * status:  new => needs_information


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

Re: [tor-bugs] #20521 [Metrics/metrics-lib]: Deprecate `DescriptorReader.setExcludeFiles()` and add two separate methods for loading and saving a history file

[Tor Bug Tracker & Wiki]

#20521: Deprecate `DescriptorReader.setExcludeFiles()` and add two separate 
methods
for loading and saving a history file
-+---
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  new => needs_review


Comment:

 Please review [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/log/?h=task-20521 my branch task-20521].

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

Re: [tor-bugs] #20509 [Core Tor/Tor]: Directory authorities should take away Guard flag from relays with #20499 bug

[Tor Bug Tracker & Wiki]

#20509: Directory authorities should take away Guard flag from relays with 
#20499
bug
+
 Reporter:  arma|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  028-backport, easy  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * keywords:  028-backport => 028-backport, easy


Comment:

 Also, `tor_version_as_new_as` is a very useful function for this patch.

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

Re: [tor-bugs] #20511 [Core Tor/Tor]: add a failsafe where if you're about to serve a consensus that you know is obsolete, don't do it

[Tor Bug Tracker & Wiki]

#20511: add a failsafe where if you're about to serve a consensus that you know 
is
obsolete, don't do it
--+
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Clock skew on relays becomes much more important after this fix, but the
 directory authorities already check for that (~3 hours).

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

Re: [tor-bugs] #20456 [Core Tor/Tor]: Relative paths don't work for PidFile and control_auth_cookie

[Tor Bug Tracker & Wiki]

#20456: Relative paths don't work for PidFile and control_auth_cookie
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.9
 Severity:  Normal| Resolution:
 Keywords:  regression?   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 This may be related to #20119, and, if so, there are also issues with
 creating a PidFile in a non-existent directory.

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

Re: [tor-bugs] #20119 [Core Tor/Tor]: Fails to create the pid file when an enclosing directory is missing

[Tor Bug Tracker & Wiki]

#20119: Fails to create the pid file when an enclosing directory is missing
--+
 Reporter:  yurivict271   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 This may be related to #20456, and if so, may also affect
 control_auth_cookie.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20521 [Metrics/metrics-lib]: Deprecate `DescriptorReader.setExcludeFiles()` and add two separate methods for loading and saving a history file

[Tor Bug Tracker & Wiki]

#20521: Deprecate `DescriptorReader.setExcludeFiles()` and add two separate 
methods
for loading and saving a history file
-+---
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+---
 The history file implementation in `DescriptorReader` has a design bug for
 much too long that I'd finally want to fix.

 The issue is that `DescriptorReader` writes the history file passed in
 `setExcludeFiles()` immediately after reading and parsing the last
 descriptor and putting it into the queue, regardless of whether the
 application has finished processing those descriptors.

 If the application fails after the history file is written, it may not be
 able to process descriptors in the next execution that have still been in
 the queue at the time of failing.

 One way to reduce that gap would be to have `BlockingIteratorImpl` tell
 `DescriptorReader` when the application has first learned that `hasNext()`
 returned `false` or that `next()` threw a `NoSuchElementException`.  The
 benefit of that solution would be that no interface change would be
 required.  The downside would be that the application might not have fully
 cleaned up at the time of learning that there are no further descriptors
 available.  In one example, the application would close a database import
 file, perform the database import, and only write the history file after
 learning that the database import has succeeded.

 A better solution would be to decouple saving the history file to disk
 from completing the descriptor read operation.  We would replace the
 `setExcludeFiles()` method by a `setHistoryFile()` and a
 `saveHistoryFile()` method.  Applications would use `setHistoryFile()`
 before starting to read descriptors, process all descriptors, perform any
 cleaning up, and then call `saveHistoryFile()`.

 Here's an example of the code that this would save in applications that
 currently work around this known design bug by loading and saving history
 files themselves:

 {{{
 diff --git
 a/modules/hidserv/src/org/torproject/metrics/hidserv/Parser.java
 b/modules/hidserv/src/org/torproject/metrics/hidserv/Parser.java
 index 2ef404e..215b0c9 100644
 --- a/modules/hidserv/src/org/torproject/metrics/hidserv/Parser.java
 +++ b/modules/hidserv/src/org/torproject/metrics/hidserv/Parser.java
 @@ -96,33 +96,7 @@ public class Parser {
public void readParseHistory() {
  if (this.parseHistoryFile.exists()
  && this.parseHistoryFile.isFile()) {
 -  SortedMap excludedFiles =
 -  new TreeMap();
 -  try {
 -BufferedReader br = new BufferedReader(new FileReader(
 -this.parseHistoryFile));
 -String line;
 -while ((line = br.readLine()) != null) {
 -  try {
 -/* Each line is supposed to contain the last-modified time
 and
 - * absolute path of a descriptor file. */
 -String[] parts = line.split(" ", 2);
 -excludedFiles.put(parts[1], Long.parseLong(parts[0]));
 -  } catch (NumberFormatException e) {
 -System.err.printf("Illegal line '%s' in parse history.  "
 -+ "Skipping line.%n", line);
 -  }
 -}
 -br.close();
 -  } catch (IOException e) {
 -System.err.printf("Could not read history file '%s'.  Not "
 -+ "excluding descriptors in this execution.",
 -this.parseHistoryFile.getAbsolutePath());
 -  }
 -
 -  /* Tell the descriptor reader to exclude the files contained in the
 -   * parse history file. */
 -  this.descriptorReader.setExcludedFiles(excludedFiles);
 +  this.descriptorReader.setHistoryFile(this.parseHistoryFile);
  }
}

 @@ -130,33 +104,7 @@ public class Parser {
 * and absolute paths to the parse history file to avoid parsing these
 * files again, unless they change until the next execution. */
public void writeParseHistory() {
 -
 -/* Obtain the list of descriptor files that were either parsed now or
 - * that were skipped in this execution from the descriptor reader. */
 -SortedMap excludedAndParsedFiles =
 -new TreeMap();
 -excludedAndParsedFiles.putAll(
 -this.descriptorReader.getExcludedFiles());
 -
 excludedAndParsedFiles.putAll(this.descriptorReader.getParsedFiles());
 -try {
 -  this.parseHistoryFile.getParentFile().mkdirs();
 -  BufferedWriter bw = new BufferedWriter(new FileWriter(
 - 

Re: [tor-bugs] #19986 [Core Tor/Tor]: pathbias_count_use_attempt: Bug: Used circuit is in strange path state new

[Tor Bug Tracker & Wiki]

#19986: pathbias_count_use_attempt: Bug: Used circuit is in strange path state 
new
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.1-alpha
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


Comment:

 I think this is a duplicate of the above two issues.

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

Re: [tor-bugs] #20502 [Core Tor/Tor]: Setting UseBridges=1 UseEntryGuards=0 means you bypass your bridges

[Tor Bug Tracker & Wiki]

#20502: Setting UseBridges=1 UseEntryGuards=0 means you bypass your bridges
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  config|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 I propose an alternate fix: set UseEntryGuards to 1 if UseBridges is 1,
 and warn the user.

 We already have UseEntryGuards_opt or something, so this won't overwrite
 the config value if we write out the config.

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

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Perhaps max_dl_tries is also far too low, and we should increase it
 somewhat? 10?

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

Re: [tor-bugs] #20509 [Core Tor/Tor]: Directory authorities should take away Guard flag from relays with #20499 bug

[Tor Bug Tracker & Wiki]

#20509: Directory authorities should take away Guard flag from relays with 
#20499
bug
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  028-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:1 arma]:
 > ...
 > Option 2 is that we change the directory authority code to withhold a
 Guard vote for all relays running the affected versions. And then get
 enough authorities to update that we can affect Guard assignment. This
 option seems better in theory, I don't have a good handle on what versions
 the dir auths like to run, so I don't know how tricky this one will be in
 practice.
 > ...

 Hang on, didn't we have a bug where clients would pick relays as their
 guard regardless of whether they had the Guard flag? How many versions ago
 was that?

 And do clients automatically get new guards when their existing guards
 lose the Guard flag? Or do they keep their old guards until they rotate?

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 Replying to [comment:31 nickm]:
 > >I think I favor either (1) putting your 028 into both 028 and 029, and
 my 029 into 029, or (2) putting my 029 into both 028 and 029. With slight
 preference for option 2 at present, since (i) the thing that is in 028
 would get testing in 029, and (ii) it would resolve bug B as well.
 >
 > What if we go with option (3) putting both patches in both?

 Seems like a good idea.
 In general, I don't like the idea of testing different code in 0.2.9 than
 the code we plan to backport to 0.2.8.

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

Re: [tor-bugs] #20262 [Core Tor/Tor]: Onion services startup time always gets revealed

[Tor Bug Tracker & Wiki]

#20262: Onion services startup time always gets revealed
---+---
 Reporter:  twim   |  Owner:  twim
 Type:  defect | Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Major  | Resolution:
 Keywords:  tor-hs, research, review-group-11  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  SponsorR-
   |  can
---+---

Comment (by asn):

 Hey twim, how about we close this ticket and work on #20082 for things
 related to HS startup time from now on?

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

Re: [tor-bugs] #20520 [Core Tor/Stem]: stem test_installs_all_files fails with *.swo file

[Tor Bug Tracker & Wiki]

#20520: stem test_installs_all_files fails with *.swo file
---+
 Reporter:  chelseakomlo   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by cypherpunks):

 * owner:   => atagar
 * component:  Core Tor => Core Tor/Stem


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

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by rubiate):

 I set up two new relays:

 bug20499badED6E43F07ABE87C017BD80D4BA24E41F8FF32E94
 bug20499revert 083971FD18EDBD442DF0971D0FDC6F500642AD91

 'bad is running 0.2.9.4-alpha, and 'revert is identical except it has
 09a0f2d0b24 reverted. Both have the same config, other than cosmetic
 differences (different names, ports, logfile).

 Rough timeline:

 10:36 Both start up
 [...] both request the consensus every minute
 10:41 they reach a fail count of 10
 [...] both do nothing every minute, fail count is too high
 11:36 'revert updates the microdesc consensus; valid-until 2016-11-01
 14:00:00
 11:36 'bad is still doing nothing, valid-until 2016-11-01 13:00:00
 11:37 'revert tries to do it again, gets a 304, fail count is 2
 11:38 'revert tries to do it again, gets a 304, fail count is 4
 [...] and so on
 11:41 'revert reaches a fail count of 10 again
 [...] both do nothing
 12:36 'revert updates; valid-until 2016-11-01 15:00:00
 12:36 'bad doesn't; valid-until 2016-11-01 13:00:00
 12:41 'revert hits 10 fails again
 [...] doin' nothin'
 13:00 'bad now has a microdesc consensus past its valid-until date
 [...]
 13:36 'revert updates; valid-until 2016-11-01 16:00:00
 13:36 'bad doesn't; valid-until 2016-11-01 13:00:00
 [...] I suspect this pattern is going to hold.

 'revert:
 http://45.32.188.229:9209/tor/status-vote/current/consensus-microdesc

 'bad:
 http://45.32.188.229:9201/tor/status-vote/current/consensus-microdesc

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20520 [Core Tor]: stem test_installs_all_files fails with *.swo file

[Tor Bug Tracker & Wiki]

#20520: stem test_installs_all_files fails with *.swo file
--+-
 Reporter:  chelseakomlo  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 When I run `make test-stem` (which is also a sub-task of `make test-full`,
 I see the below error.

 I submitted a basic fix for this here:
 `g...@github.com:chelseakomlo/stem.git`, branch `swo_fix`, and a refactor
 which makes the code more extensible if we need to exclude other file
 formats.

 {{{
 Running tests...

   util.conf... success (0.00s)
   util.connection...   success (0.00s)
   util.proc... success (0.00s)
   util.system...   success (1.04s)
   installation...  failed (0.35s)
 test_installing_stem [SUCCESS]
 test_installs_all_files  [FAILURE]

 ==
 FAIL: test_installs_all_files
 --
 Traceback (most recent call last):
   File
 
"/home/chelseakomlo/Documents/development/open/stem/test/integ/installation.py",
 line 96, in test_installs_all_files
 self.fail("The following files were expected to be in our installation
 but weren't. Maybe our setup.py needs to be updated?\n\n%s" %
 '\n'.join(mi$sing))
 AssertionError: The following files were expected to be in our
 installation but weren't. Maybe our setup.py needs to be updated?

 stem/.prereq.py.swo

 --
 Ran 2 tests in 0.346s

 }}}


 Let me know if there are any recommended changes for this!

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by nickm):

 Replying to [comment:23 teor]:
 > Replying to [comment:19 nickm]:
 > > ...
 > >
 > > When we turn on pinning, the most recent journal entry will rule.  So
 a relay will only be excluded from the consensus if its most recently
 pinned Ed25519 key is not the one it uses.  So if somebody switched Ed
 keys once a few months ago, they won't get penalized here.  This only
 affects them if they are switching frequently, or if they switch keys
 again.
 > >
 > > The rule for relays becomes:
 > > {{{
 > > Always use the same Ed25519 identity with the same RSA identity.
 > > }}}
 > > So, don't switch one unless you also switch the other.  If you lose
 one, don't try to retain the other.
 > >
 > > Sebastian says:
 > > > ...
 > > > How will this all work, by the way? My key pinning journal goes back
 one year and has more entries than what is written above, including more
 than just the dirauth above.
 > >
 > > Once key pinning is turned on, an authority will believe the latest
 entry for any given RSA key.  They will not accept a descriptor signed
 with that RSA identity key unless it also has the provided Ed25519
 identity.  So it only affects the voting, not the consensus.
 > > ...
 >
 > I see from the manual that AuthDirPinKeys is set on a per-authority
 basis, so it only affects that authority's votes (and so it's not like a
 consensus method, where every authority uses it at the same time).
 >
 > '''Activation Timing'''
 >
 > What if I run a relay that changes ed keys during the changeover?
 >
 > If authorities A, B, C, D set key pinning at hour 1,
 >  & authorities E, F, G, H set key pinning at hour 2,
 > then I have a different ed key pinned on some authorities compared to
 others.
 >
 > I guess I need to regenerate both RSA & ed keys in this instance.

 Yes.  If you are a relay, you should never keep one key and change the
 other.  The consequences for doing it during the changeover are weirder
 than usual.

 > '''Keeping State'''
 >
 > Will authorities need to back up their key pinning file?
 >
 > If an authority is restored with an empty pinning file, it will
 regenerate its key pinning file based on the descriptors it sees at that
 time, and those descriptors could be different after the restore. (But the
 other authorities will anchor the pinning, if a majority keep their
 files.)

 IMO authorities should probably back these up, but it isn't crucial.

 > '''Requiring Ed25519'''
 >
 > Also, what are we going to do about `DISABLE_DISABLING_ED25519`?
 > It's currently `#undef`, which means that a relay can drop its ed25519
 key whenever it wants.
 > When are we going to turn it on? When 0.2.5 is no longer recommended?


 That sounds plausible to me.  Or another option would be to look at
 historical metrics data to see how often relays run a recent version for a
 while, then drop back to an older one.  If the answer is "almost never"
 then we can just turn it on 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] #19969 [Core Tor/Tor]: tor client does not immediately open new circuits after standby

[Tor Bug Tracker & Wiki]

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

Comment (by nickm):

 >I think I favor either (1) putting your 028 into both 028 and 029, and my
 029 into 029, or (2) putting my 029 into both 028 and 029. With slight
 preference for option 2 at present, since (i) the thing that is in 028
 would get testing in 029, and (ii) it would resolve bug B as well.

 What if we go with option (3) putting both patches in both?

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

Re: [tor-bugs] #20509 [Core Tor/Tor]: Directory authorities should take away Guard flag from relays with #20499 bug

[Tor Bug Tracker & Wiki]

#20509: Directory authorities should take away Guard flag from relays with 
#20499
bug
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  028-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * keywords:   => 028-backport
 * milestone:   => Tor: 0.2.9.x-final


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

Re: [tor-bugs] #20511 [Core Tor/Tor]: add a failsafe where if you're about to serve a consensus that you know is obsolete, don't do it

[Tor Bug Tracker & Wiki]

#20511: add a failsafe where if you're about to serve a consensus that you know 
is
obsolete, don't do it
--+
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 404 seems fine to me.  You asked for a "current" consensus.  I don't have
 one of those.

 Tenatively assigning this to 0.3.0

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

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 I concur that for 0.2.9, reverting 09a0f2d0b seems like a good choice.  If
 we feel cheeky, we might increase the interval, 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] #20519 [Metrics/CollecTor]: untangle releaydesc and modernize

[Tor Bug Tracker & Wiki]

#20519: untangle releaydesc and modernize
---+
 Reporter:  iwakeh |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #20518
   Points: |   Reviewer:
  Sponsor: |
---+
 * unify descriptor parsing throughout all classes
 * separate statistics
 * untangle the following picture

 {{{

 ++
  |
 |
  |  X o--+ Y : X holds a Y reference somewhere
 |
  |
 |
 ++
  |
 |
  |
 |
  |   ++
 |
  |   |  RelayDescriptorParser +\
 |
  |   +-+-o-+o---o-+ \
 |
  |/ /  | \   --  -\
 |
  |   / /   |  \\-  -\
 |
  |  / / \ |  \-  -\
 |
  | / /  |  \   \-  -\
 |
  |/ /   |  | \-  -\
 |
  |   / /|   \  \-  -\
 |
  |  / /  \  |\-  -\
 |
  | / /   |   \ \-  \
 |
  |+---o-+---+|   |  +---+---o-+
 |
  ||  ArchiveReader  | \   \ |  ArchiveWriter  |
 |
  |+-+ |   | +---o-+
 |
  ||\|
 |
  ||||
 |
  | \\  /
 |
  |+o+--+--+
 |
  || RelayDescriptorDownloader |
 |
  |+---+
 |
  |   /
 |
  |  /
 |
  | /
 |
  | +--o--+
 |
  | | CachedRelayDescriptorParser |
 |
  | +-+
 |
  |
 |
  |
 |
 ++
 }}}

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

Re: [tor-bugs] #8799 [Metrics/CollecTor]: collector's downloads: avoid httpurl-connection

[Tor Bug Tracker & Wiki]

#8799: collector's downloads: avoid httpurl-connection
---+-
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  assigned
 Priority:  High   |  Milestone:  CollecTor 1.2.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #20518 | Points:
 Reviewer: |Sponsor:
---+-
Changes (by iwakeh):

 * keywords:  metrics-help =>
 * parent:   => #20518


Comment:

 Set parent ticket and removed metrics-help tag as this ticket only groups
 the three subtickets.

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

Re: [tor-bugs] #20518 [Metrics/CollecTor]: CollecTor: architecture improvements and modernization

[Tor Bug Tracker & Wiki]

#20518: CollecTor: architecture improvements and modernization
---+-
 Reporter:  iwakeh |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 #8799 already describes the download modernization.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20518 [Metrics/CollecTor]: CollecTor: architecture improvements and modernization

[Tor Bug Tracker & Wiki]

#20518: CollecTor: architecture improvements and modernization
---+-
 Reporter:  iwakeh |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 This is the parent ticket for further architecture improvements and
 modernization of the CollecTor code-base.

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