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:
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  tor-hs research  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+

Comment (by teor):

 The original commit was intended to reduce linkability between hidden
 service instances on the same tor instance, rather than hide the startup
 time itself:

 {{{
 commit 4b76fe8
 Author: Roger Dingledine 
 Date:   Mon Nov 15 09:05:54 2004 +
 

 Also make sure the hidden service descriptors are at a random
 offset from each other, to hinder linkability.
 }}}

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

Re: [tor-bugs] #12500 [Core Tor/Tor]: Add an option to upload hidden service descriptors some time after startup

[Tor Bug Tracker & Wiki]

#12500: Add an option to upload hidden service descriptors some time after 
startup
--+
 Reporter:  andrea|  Owner:
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-hs, easy  |  Actual Points:
Parent ID:  #20082| Points:  small
 Reviewer:  teor  |Sponsor:  SponsorR-can
--+

Comment (by teor):

 (bugfix on commit 4b76fe8 in 0.0.9pre6)

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

Re: [tor-bugs] #12500 [Core Tor/Tor]: Add an option to upload hidden service descriptors some time after startup

[Tor Bug Tracker & Wiki]

#12500: Add an option to upload hidden service descriptors some time after 
startup
--+
 Reporter:  andrea|  Owner:
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-hs, easy  |  Actual Points:
Parent ID:  #20082| Points:  small
 Reviewer:  teor  |Sponsor:  SponsorR-can
--+
Changes (by teor):

 * version:  Tor: 0.2.5.5-alpha => Tor: unspecified


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

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

[Tor Bug Tracker & Wiki]

#20082: Lower initial descriptor upload delay for hidden services
-+-
 Reporter:  twim |  Owner:
 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, research, proposal-needed?,  |  Actual Points:
  TorCoreTeam201610, 030-proposed|
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
 |  SponsorR-can
-+-
Changes (by teor):

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


Comment:

 Replying to [comment:26 twim]:
 > Replying to [comment:25 teor]:
 >
 > > Removed references to rend_service_reveal_startup_time():
 > > * there are references in the comments as well. grep is your friend.
 > > Add REND_DIRTY_DESC_STABILIZING_PERIOD_TESTING
 > > * The logic here is inverted: the testing period needs to be used when
 TestingTorNetwork is 1.
 >
 > Thanks, good catches! Fixed.
 >
 > > In future, please add a short message to the commit saying what's
 changed.
 > > (These ones look like they will squash nicely into one commit, so no
 need to fix them.)
 > These ones are supposed to be squashed. There is no need to store thashy
 commits in `master`. ;)

 These all look good.

 > > This also needs a changes file. See tor/changes/ for examples, or read
 doc/HACKING/CodingStandards.md
 > Yeap, added changes file. As always, not sure about 'feature on ...'
 string.

 We don't use "feature on", only "bugfix on". And the changes file is
 usually shorter.

 Here's what I suggest we write for the changes file - they can be hard to
 get right:
 {{{
 o Minor features (onion services):
   - Reduce onion service initial descriptor upload delay from 30s to 3s.
 If descriptor changes too soon after this (< 30s), log a warning about
 unreliable network connections. Closes ticket 20082.
 o Minor bugfixes (onion services):
   - Remove code that claimed to introduce an initial descriptor upload
 delay,
 but never actually worked. Closes ticket 12500, bugfix on
 tor-0.0.9pre6.
 }}}

 Here are the commands I used to find which release the bug was introduced
 in:
 {{{
 git blame src/or/rendservice.c
 (look at the commits that changed the function)
 git show 4b76fe803
 git describe --contains 4b76fe8
 }}}

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

Re: [tor-bugs] #12500 [Core Tor/Tor]: Add an option to upload hidden service descriptors some time after startup

[Tor Bug Tracker & Wiki]

#12500: Add an option to upload hidden service descriptors some time after 
startup
--+
 Reporter:  andrea|  Owner:
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.5.5-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-hs, easy  |  Actual Points:
Parent ID:  #20082| Points:  small
 Reviewer:  teor  |Sponsor:  SponsorR-can
--+
Changes (by teor):

 * status:  assigned => closed
 * reviewer:   => teor
 * resolution:   => fixed
 * milestone:  Tor: 0.2.??? => Tor: 0.3.0.x-final


Comment:

 This bug is fixed in #20082 by removing the offending code, #20262 will
 add back in a delay if research discovers it is actually useful.

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

Re: [tor-bugs] #20077 [Core Tor/Tor]: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent

[Tor Bug Tracker & Wiki]

#20077: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  refactor, 030-proposed,  |  Actual Points:
  TorCoreTeam201610  |
Parent ID:   | Points:  1
 Reviewer:  teor |Sponsor:
-+-

Comment (by chelseakomlo):

 Ok, sorry, I understand. The ROUTER_PURPOSE_BRIDGE overrides the other
 dir_purpose cases.

 Thanks! Will add that back in!

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

Re: [tor-bugs] #20077 [Core Tor/Tor]: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent

[Tor Bug Tracker & Wiki]

#20077: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  refactor, 030-proposed,  |  Actual Points:
  TorCoreTeam201610  |
Parent ID:   | Points:  1
 Reviewer:  teor |Sponsor:
-+-

Comment (by chelseakomlo):

 Hey! It isn't clear what cases should be tested for router_purpose in
 purpose_needs_anonymity.

 In the previous code, purpose_needs_anonymity returned true by default,
 and the only router_purpose case that was tested would return also true.
 So removing this case doesn't (from what I can see!) change the logic
 flow.

 See here:
 
https://github.com/chelseakomlo/tor_patches/commit/c6d0255eebdafe7b635c6c762c8c16a5a45b5a2f
 #diff-c56fd972333216da3bb1852bcc89f57dL131

 Are there a list of cases where a router_purpose should _not_ use an
 anonymous connection?

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

Re: [tor-bugs] #20341 [Core Tor/Tor]: torrc man page missing components for Bridge line

[Tor Bug Tracker & Wiki]

#20341: torrc man page missing components for Bridge line
---+--
 Reporter:  stefanib   |  Owner:
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  torrc manual page  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by yawning):

 * priority:  Medium => Low


Comment:

 The extra args including `iat-mode` are specific to obfs4 and should not
 be part of the tor man page, especially since it's an entirely separate
 piece of software.

 That said, the documentation for the bridge line could clarify that,
 transports can add arbitrary things to the bridge line.

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

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

[Tor Bug Tracker & Wiki]

#20082: Lower initial descriptor upload delay for ephemeral services
-+-
 Reporter:  twim |  Owner:
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.???
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, research, proposal-needed?,  |  Actual Points:
  TorCoreTeam201610, 030-proposed|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-

Comment (by twim):

 Replying to [comment:25 teor]:

 > Removed references to rend_service_reveal_startup_time():
 > * there are references in the comments as well. grep is your friend.
 > Add REND_DIRTY_DESC_STABILIZING_PERIOD_TESTING
 > * The logic here is inverted: the testing period needs to be used when
 TestingTorNetwork is 1.

 Thanks, good catches! Fixed.

 > In future, please add a short message to the commit saying what's
 changed.
 > (These ones look like they will squash nicely into one commit, so no
 need to fix them.)
 These ones are supposed to be squashed. There is no need to store thashy
 commits in `master`. ;)

 > This also needs a changes file. See tor/changes/ for examples, or read
 doc/HACKING/CodingStandards.md
 Yeap, added changes file. As always, not sure about 'feature on ...'
 string.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 ephemeral services

[Tor Bug Tracker & Wiki]

#20082: Lower initial descriptor upload delay for ephemeral services
-+-
 Reporter:  twim |  Owner:
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.???
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, research, proposal-needed?,  |  Actual Points:
  TorCoreTeam201610, 030-proposed|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-

Comment (by teor):

 Thanks, we prefer git branches ;-)

 Code review:

 Removed references to rend_service_reveal_startup_time():
 * there are references in the comments as well. grep is your friend.

 Move numbers to #define
 * looks good!

 Add REND_DIRTY_DESC_STABILIZING_PERIOD_TESTING
 * The logic here is inverted: the testing period needs to be used when
 TestingTorNetwork is 1.

 Reword warning message for users and leave a comment for developers
 * looks good!

 In future, please add a short message to the commit saying what's changed.
 (These ones look like they will squash nicely into one commit, so no need
 to fix them.)

 This also needs a changes file. See tor/changes/ for examples, or read
 doc/HACKING/CodingStandards.md

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  tor-hs research  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+

Comment (by twim):

 I think that because of #20082 and that startuptime should be revealed by
 default (that's what users expect), it's reasonable to introduce
 `ObfuscateOnionServiceStartupTime` instead that defaults to `0`. Thus it
 would not conflict with Single Onions and SOS operators can obfuscate
 startup time also (maybe pointless).
 If implemented, it should be built on top of #20082 (without lower bound
 for initial delay) just with `crypto_rand_int(2*rendpostperiod)` delay
 instead of immediate first upload.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 ephemeral services

[Tor Bug Tracker & Wiki]

#20082: Lower initial descriptor upload delay for ephemeral services
-+-
 Reporter:  twim |  Owner:
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.???
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, research, proposal-needed?,  |  Actual Points:
  TorCoreTeam201610, 030-proposed|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-

Comment (by twim):

 Replying to [comment:23 teor]:

 Thanks for review and comments! Fixed now. Not sure about wording in warn
 message I chose.
 The code lives here [1] because it will be too much patch noise here
 otherwise.

 [1] https://github.com/nogoegst/tor/tree/no-initialpostdelay

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20342 [Core Tor/Tor]: Add tor-gencert.exe to tor expert bundle and tor nightlies

[Tor Bug Tracker & Wiki]

#20342: Add tor-gencert.exe to tor expert bundle and tor nightlies
--+---
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Major |   Keywords:  029-proposed, testing
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+---
 At the recent tor developer meeting, a volunteer tried to get chutney
 working on Windows, but tor-gencert.exe wasn't in the tor expert bundle.

 If we want people to test Tor on Windows, we need to add at least tor-
 gencert.exe to the windows expert and nightly bundles. There might be
 other binaries we want to add 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] #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:
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  tor-hs research  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+

Comment (by teor):

 (I added a note to #20082 about removing that function, because that patch
 makes it unused. We can always add it back later.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 ephemeral services

[Tor Bug Tracker & Wiki]

#20082: Lower initial descriptor upload delay for ephemeral services
-+-
 Reporter:  twim |  Owner:
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.???
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, research, proposal-needed?,  |  Actual Points:
  TorCoreTeam201610, 030-proposed|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-
Changes (by teor):

 * status:  needs_review => needs_revision
 * keywords:  tor-hs, research, proposal-needed?, TorCoreTeam201609 => tor-
 hs, research, proposal-needed?, TorCoreTeam201610, 030-proposed


Comment:

 Thanks for these patches. Given the discussion in #20262, I think we can
 proceed with removing this code that never worked anyway.

 A few comments on patch 0001:
 * Please don't remove the lower delay for test networks. Instead, make it
 0.
 * All references to rend_service_reveal_startup_time() should be removed,
 because it is no longer used.

 And on 0002:
 * We generally don't include numbers in the code like
 `old_stabilizing_period = (time_t) 30;`, instead, let's keep the old
 #define, but change its name to include OLD.
 * The warning message is unhelpful, because the user can't do anything to
 fix it. It will most likely be triggered when the network is slow or
 unreliable - let's say that, and tell them that their service may be
 unreliable as a result. (The message that maybe the "new stabilizing
 period is too short" is for developers, it should go in a comment above
 the log message.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  tor-hs research  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+

Comment (by twim):

 Replying to [comment:6 teor]:
 > A torrc option like this will be confusing if merged into the current
 master, because it contains a function rend_service_reveal_startup_time()
 which defaults to 0.
 Right. It's because it does
 {{{
 return rend_service_non_anonymous_mode_enabled(options);
 }}}
 When introducing this torrc option this func should be changed to
 something like
 {{{
 return options->RevealOnionServiceStartupTime ||
rend_service_non_anonymous_mode_enabled(options);
 }}}

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

Re: [tor-bugs] #20307 [Core Tor/Tor]: [warn] Remote server sent bogus reason code 65021

[Tor Bug Tracker & Wiki]

#20307: [warn] Remote server sent bogus reason code 65021
---+
 Reporter:  arma   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal | Resolution:
 Keywords:  circuit, 029-proposed  |  Actual Points:
Parent ID: | Points:  2
 Reviewer: |Sponsor:
---+
Changes (by isis):

 * keywords:   => circuit, 029-proposed
 * cc: isis (added)
 * points:   => 2


Comment:

 I also this bug today on a really crappy network, with the same reason
 code (65021).

 Would it better to track down this bug and do a one-off patch for it, or
 attempt to make return codes universally more 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

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:
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  tor-hs research  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+

Comment (by teor):

 Replying to [comment:5 twim]:
 > Replying to [comment:2 asn]:
 > > If in the future we want to add a random delay for security purposes,
 someone should write a proposal with security analysis.
 >
 > See ticket description about saving this behavior as `torrc` option.

 A torrc option like this will be confusing if merged into the current
 master, because it contains a function rend_service_reveal_startup_time()
 which defaults to 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] #19999 [Core Tor/Tor]: Maybe test-cases should complete without BUG warnings?

[Tor Bug Tracker & Wiki]

#1: Maybe test-cases should complete without BUG warnings?
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  testing, TorCoreTeam201609, review-  |  Actual Points:  3
  group-10   |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => new
 * milestone:  Tor: 0.2.9.x-final => Tor: 0.3.0.x-final


Comment:

 rubiate: merged your patch as baa6be9fe7fb.  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] #20341 [Core Tor/Tor]: torrc man page missing components for Bridge line

[Tor Bug Tracker & Wiki]

#20341: torrc man page missing components for Bridge line
---+--
 Reporter:  stefanib   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  torrc manual page  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by arma):

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


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

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

[Tor Bug Tracker & Wiki]

#20082: Lower initial descriptor upload delay for ephemeral services
-+-
 Reporter:  twim |  Owner:
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.???
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, research, proposal-needed?,  |  Actual Points:
  TorCoreTeam201609  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-
Changes (by twim):

 * status:  needs_revision => needs_review


Comment:

 Okay, getting back on results.
 I have tested meek and it works fine.  Despite me trying, I got no events
 when descriptor gets dirty. For sure this should be tested in even more
 crazy network environment than mine.

 At the moment I removed __initial posting delay__ and it still works fine.
 Because startup time gets revealed anyway (#20262) I removed dead code
 that was supposed to introduce random initial delay.
 Also it drops a warning when new 3s stabilizing period is too small (`3s <
 was_stable_for < 30s`).

 Please see the last two patches.
 Would be thankful for any feedback on this.

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

[tor-bugs] #20341 [- Select a component]: torrc man page missing components for Bridge line

[Tor Bug Tracker & Wiki]

#20341: torrc man page missing components for Bridge line
--+---
 Reporter:  stefanib  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:  torrc manual page
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 The man page for torrc Bridge currently has an entry:
 Bridge [transport] IP:ORPort [fingerprint]

 an example line i was just given had a bit more than this:

 Bridge [transport] IP:ORPort [fp] [cert=...] ] iat-mode=0

 perhaps a description of iat-mode and its values would be helpful? and
 extend the config line?

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

Re: [tor-bugs] #19690 [Core Tor/DirAuth]: Tonga (Bridge Authority) Permanent Shutdown Notice

[Tor Bug Tracker & Wiki]

#19690: Tonga (Bridge Authority) Permanent Shutdown Notice
---+
 Reporter:  shamrock   |  Owner:  isis
 Type:  task   | Status:  closed
 Priority:  Very High  |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/DirAuth   |Version:  Tor: 0.2.8.5-rc
 Severity:  Critical   | Resolution:  fixed
 Keywords:  TorCoreTeam201608  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by isis):

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


Comment:

 This task was completed in late August. At the same time, code related to
 temporarily having multiple directory authorities was merged into
 BridgeDB, see #20088.

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

Re: [tor-bugs] #18529 [Core Tor/Tor]: Fix duplicate check for "only allow internal addresses if we are on a network with nonstandard authorities"

[Tor Bug Tracker & Wiki]

#18529: Fix duplicate check for "only allow internal addresses if we are on a
network with nonstandard authorities"
-+-
 Reporter:  nickm|  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Low  |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.1-alpha
 Severity:  Trivial  | Resolution:
 Keywords:  easy, refactor, 029-nickm-says-yes,  |  Actual Points:
  review-group-3, nickm-deferred-20160905|
Parent ID:   | Points:  1
 Reviewer:  isis |Sponsor:
-+-
Changes (by isis):

 * status:  needs_review => merge_ready
 * milestone:  Tor: 0.2.??? => Tor: 0.2.9.x-final


Comment:

 LGTM. FWIW, we could still probably add do call to
 `is_default_directory_auth()` inside `tor_addr_is_internal()`, for further
 condensation, but it's not vital.

 Nick: This should be a very safe patch to merge into 0.2.9, because it
 functionally doesn't change anything, if you're okay with 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] #20111 [Applications/Tor Browser]: use Unix domain sockets for SOCKS port by default

[Tor Bug Tracker & Wiki]

#20111: use Unix domain sockets for SOCKS port by default
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, tbb-security, tbb-|  Actual Points:
  sandboxing, TorBrowserTeam201610R  |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:20 arthuredelstein]:
 > A few very minor comments:
 >
 > * "extensions.torlauncher.socks_port_use_socket" is a confusing name to
 me, because we are using a TCP socket when it is false. Maybe call it
 "socks_port_use_ipc", as this would also cover the named pipe scenario if
 we later get it working in Windows? Similar for the env var
 TOR_SOCKS_SOCKET.

 Good point. Kathy and I cleaned this up. We renamed the env vars and
 preferences as well as various functions and variables. The changes are a
 little messy, but they seem worthwhile.

 > * `_strUnescape`: It would be nicer if this function simply returned the
 unescaped string, and threw an exception if it failed. (Although maybe you
 want to keep it this way to be consistent with the other copy in Tor
 launcher.)

 Done. While testing, we also found some errors in the implementation
 (oops).

 > * `unescapeTorString`: I would suggest defining this after
 `_strUnescape` is defined in utils.js, because it refers to it.

 Done.

 Revised patches for Tor Launcher and Torbutton:
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug20111-04=e0e8798adf793b1a369430292b881bf3cbbd6693
 
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug20111-03=d66fa277a83b4a117669f6ee8e86591b2988ec22

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

Re: [tor-bugs] #20261 [Core Tor]: tor_fragile_assert() when Unix domain socket is used

[Tor Bug Tracker & Wiki]

#20261: tor_fragile_assert() when Unix domain socket is used
---+
 Reporter:  mcs|  Owner:  yawning
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor   |Version:  Tor: 0.2.9.2-alpha
 Severity:  Normal | Resolution:  fixed
 Keywords:  tbb-needs  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by mcs):

 My tests with Tor Browser show that these changes fix the problem.
 Thank you Nick and Yawning!

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

Re: [tor-bugs] #20339 [Applications/Tor Browser]: tor-browser mozilla_user0 directory often appear in /tmp

[Tor Bug Tracker & Wiki]

#20339: tor-browser mozilla_user0 directory often appear in /tmp
--+--
 Reporter:  anon  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-disk-leak |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * owner:   => tbb-team
 * keywords:   => tbb-disk-leak
 * 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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

[Tor Bug Tracker & Wiki]

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Okay, I started reviewing those seven commits, but I'm running out of
 brains here.  However, before getting back to reviewing tomorrow, I
 figured I could share my thoughts on the first of the seven commits,
 16e1c84:

  - It seems we're deprecating a few config options by adding a comment to
 the default `collector.properties` and not paying attention to those
 options in the code anymore.  Shouldn't we instead remove those config
 options entirely, so that operators notice for sure that they need to
 change these config options?  We could mention this in the change log as
 medium change.

  - Speaking of, can you include a change log entry for this commit?

  - I wonder if we could simplify the configuration by avoiding that tri-
 state SyncType option and turning it into a boolean.  Consider
 `ImportCachedRelayDescriptors`, `ImportDirectoryArchives`, and
 `DownloadRelayDescriptors` in the relaydescs module.  We could just add a
 fourth option `SyncRelayDescriptors` that can be `true` or `false`.
 Basically, syncing descriptors from other CollecTor instances would be the
 fourth source for collecting relay descriptors.  This shouldn't change
 much in the code you wrote, but it might make things a bit simpler for
 future operators.  For bridge descriptors and exit lists there would have
 to be two new options to activate the current sources, that is, sanitize
 bridge descriptors found in a local directory or download exit lists from
 the exit list server.

  - I found at least one long line that checkstyle should complain about,
 though I didn't run it myself.

 In case you want to start working on any of these comments, can you please
 write `--fixup` commits that resolve those issues in this particular
 commit?  In any case, please don't modify commits 2 to 7 in that branch at
 this point, because I already started reviewing those.

 More tomorrow.  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] #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:
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  tor-hs research  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+

Comment (by twim):

 Replying to [comment:2 asn]:
 > I think the plan here is to remove the delay for now, since the current
 30s delay is useless. So having no delay is the same as the current
 situation.

 Yes, we do want to remove this delay (#20082 and tor-dev@ thread). But
 there is code that claims that it works certain way while it doesn't. This
 ticket is to make it work as it should and supposed to.
 So we have to either drop thus dead code or resurrect it (my patch).
 Resurrecting will break our lovely assumptions about how descriptors gets
 published.

 > If in the future we want to add a random delay for security purposes,
 someone should write a proposal with security analysis.

 See ticket description about saving this behavior as `torrc` option.

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

Re: [tor-bugs] #18541 [Applications/Orbot]: Orbot does not stop Tor when requested in Android N developer preview

[Tor Bug Tracker & Wiki]

#18541: Orbot does not stop Tor when requested in Android N developer preview
+--
 Reporter:  whalenster@…|  Owner:  n8fr8
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:  Tor: 0.2.7.5
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by gleblanc):

 This seems to be a problem on the final release of Android 7.0 on my Nexus
 6p.  I can provide more information, bu I'm not sure what is pertinent.

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

Re: [tor-bugs] #20340 [Core Tor/Tor]: nice to have: test torrc for incompatible transistions of config values

[Tor Bug Tracker & Wiki]

#20340: nice to have: test torrc for incompatible transistions of config values
--+--
 Reporter:  toralf|  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.8
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by toralf):

 What just comes into my mind:
 Add an option like "--strict-test-that-reload-would-work" which would
 force tor to return rather an error code then zero, if the torrc is fine
 but would break a reload.
 FWIW the OpenRc init.d script as used in Gentoo land looks straightforward
 :
 {{{
 t44 ~ # cat /etc/init.d/tor
 #!/sbin/openrc-run
 # Copyright 1999-2016 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Id$

 command=/usr/bin/tor
 pidfile=/var/run/tor/tor.pid
 command_args="--hush --runasdaemon 1 --pidfile \"${pidfile}\""
 retry=${GRACEFUL_TIMEOUT:-60}

 extra_commands="checkconfig"
 extra_started_commands="reload"
 description="Anonymizing overlay network for TCP"
 description_checkconfig="Check for valid config file"
 description_reload="Reload the configuration"

 checkconfig() {
 ${command} --verify-config --hush > /dev/null 2>&1
 if [ $? -ne 0 ] ; then
 eerror "Tor configuration (/etc/tor/torrc) is not valid."
 eerror "Example is in /etc/tor/torrc.sample"
 return 1
 fi
 }

 start_pre() {
 checkconfig || return 1
 checkpath -d -m 0755 -o tor:tor /var/run/tor
 }

 stop() {
 ebegin "Stopping Tor (waiting up to ${retry} seconds)"
 start-stop-daemon -K -s INT -R ${retry} -P -p ${pidfile}
 eend $?
 }

 reload() {
 checkconfig || return 1
 ebegin "Reloading Tor configuration"
 start-stop-daemon -s HUP --pidfile ${pidfile}
 eend $?
 }

 }}}

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

Re: [tor-bugs] #20340 [Core Tor/Tor]: nice to have: test torrc for incompatible transistions of config values

[Tor Bug Tracker & Wiki]

#20340: nice to have: test torrc for incompatible transistions of config values
--+--
 Reporter:  toralf|  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.8
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 toralf: any thoughts about what kind of interface might make sense here?
 How do other daemons handle this kind of thing, if they do?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  tor-hs research  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+

Comment (by asn):

 Replying to [comment:3 cypherpunks]:
 > Why do you say that is the plan? Who decided it? Enough is enough of
 trying to launder orders from bloodthirsty external US military people as
 rational community decisions.

 Hm, this escalated quickly here.

 When I say this is the plan, I meant that this is my opinion, and it also
 aligns with the opinion of other devs when we discussed it in Seattle.

 In a few words, I think that a deterministic 30s delay offers absolutely
 nothing in terms of security, and it actually harms reachability for some
 use cases (e.g. onionshare). So I think reducing it from deterministic 30s
 to deterministic 0s changes nothing in terms of security, and actually
 improves Tor performance.

 Now, if we think that ''probablistic'' delays actually offer something in
 terms of security, I'd like someone to do a proper security analysis of
 what they offer, and how long the delays will be.

 You disagree? Please make your point but also include a '''convincing'''
 security analysis. Personally, I don't take orders from external US
 military people, and who knows this might even include yourself.

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

Re: [tor-bugs] #18667 [Core Tor/Tor]: Manual on website doesn't render ipv6 addresses right

[Tor Bug Tracker & Wiki]

#18667: Manual on website doesn't render ipv6 addresses right
--+
 Reporter:  Sebastian |  Owner:  Sebastian
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  029-nickm-unsure  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by Sebastian):

 The fix is commit 6c84e8022ee16fcb532ebeaa0744d2dea3da379c in the webwml
 repo

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20340 [Core Tor/Tor]: nice to have: test torrc for incompatible transistions of config values

[Tor Bug Tracker & Wiki]

#20340: nice to have: test torrc for incompatible transistions of config values
--+--
 Reporter:  toralf|  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.8
 Severity:  Minor |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Under Gentoo we do have a config check in the OpenRc script:
 "${command} --verify-config --hush"
 But unfortunately that will not catch the case where the config is ok but
 a reload will fail due to changes eg. from "SandBox 0" to "SandBox 1".

 It would be a nifty feature to prevent a reload of Tor in such a case.

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

Re: [tor-bugs] #18667 [Core Tor/Tor]: Manual on website doesn't render ipv6 addresses right

[Tor Bug Tracker & Wiki]

#18667: Manual on website doesn't render ipv6 addresses right
--+
 Reporter:  Sebastian |  Owner:  Sebastian
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  029-nickm-unsure  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by Sebastian):

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


Comment:

 Finally fixed. Yuck yuck yuck.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  tor-hs research  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+

Comment (by cypherpunks):

 Why do you say that is the plan? Who decided it? Enough is enough of
 trying to launder orders from bloodthirsty external US military people as
 rational community decisions.

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

Re: [tor-bugs] #20261 [Core Tor]: tor_fragile_assert() when Unix domain socket is used

[Tor Bug Tracker & Wiki]

#20261: tor_fragile_assert() when Unix domain socket is used
---+
 Reporter:  mcs|  Owner:  yawning
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor   |Version:  Tor: 0.2.9.2-alpha
 Severity:  Normal | Resolution:  fixed
 Keywords:  tbb-needs  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

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


Comment:

 2e7e635c593f13 tweaks this a little as discussed above.  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

[tor-bugs] #20339 [- Select a component]: tor-browser mozilla_user0 directory often appear in /tmp

[Tor Bug Tracker & Wiki]

#20339: tor-browser mozilla_user0 directory often appear in /tmp
--+-
 Reporter:  anon  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 tor-browser-linux64-6.0.5_en-US

 sometimes a this directory appear: /tmp/mozilla_user0
 Modification time is updated every now and then.
 I think is used to store temporary data ( user data ? ).

 That doesn't happen often.
 For example it happen sometimes watching youtube ( maybe some
 advertisement or script ?) and when a download is finished to save to disk
 in mega, the site.

 This happen when I run Tor Browser.
 It happen every now and then, frequently.
 My privacy settings are at default ( low ).
 If I delete that directory, sometimes it is recreated.
 If I close Tor-Browser, the directory stay there.

 Which conditions let the directory mozilla_user0 appear in /tmp ?
 What about linux x86 (32bit), Windows and macOS versions ?
 That could be privacy related or worse?

 Happy to contribute

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  tor-hs research  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+
Changes (by asn):

 * keywords:   => tor-hs research
 * sponsor:   => SponsorR-can
 * milestone:   => Tor: 0.3.0.x-final


Comment:

 I think the plan here is to remove the delay for now, since the current
 30s delay is useless. So having no delay is the same as the current
 situation.

 If in the future we want to add a random delay for security purposes,
 someone should write a proposal with security analysis.

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

Re: [tor-bugs] #20289 [Core Tor]: HS_DESC event while waiting for upload

[Tor Bug Tracker & Wiki]

#20289: HS_DESC event while waiting for upload
-+
 Reporter:  meejah   |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-hs   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+
Changes (by asn):

 * keywords:   => tor-hs
 * sponsor:   => SponsorR-can
 * milestone:   => Tor: 0.3.0.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] #20077 [Core Tor/Tor]: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent

[Tor Bug Tracker & Wiki]

#20077: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  refactor, 030-proposed,  |  Actual Points:
  TorCoreTeam201610  |
Parent ID:   | Points:  1
 Reviewer:  teor |Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: 0.2.??? => Tor: 0.3.0.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] #15621 [Core Tor/Tor]: Kill the pre-version 3 intro protocol code with fire.

[Tor Bug Tracker & Wiki]

#15621: Kill the pre-version 3 intro protocol code with fire.
--+---
 Reporter:  yawning   |  Owner:  dgoulet
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:  #6418 | Points:  1
 Reviewer:  asn   |Sponsor:  SponsorR-must
--+---
Changes (by dgoulet):

 * status:  needs_revision => accepted
 * sponsor:  SponsorR-can => SponsorR-must


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

Re: [tor-bugs] #19024 [Core Tor/Tor]: prop224: Refactor rend_data_t so be able to use multiple HS version

[Tor Bug Tracker & Wiki]

#19024: prop224: Refactor rend_data_t so be able to use multiple HS version
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, TorCoreTeam201609,  |  Actual Points:
  review-group-9, nickm-deferred-20161005|
Parent ID:  #17238   | Points:  4
 Reviewer:  asn  |Sponsor:
 |  SponsorR-must
-+-
Changes (by dgoulet):

 * status:  needs_revision => accepted


Comment:

 The implementation is in parent ticket which is being reviewed so putting
 this one in `Accepted` state and once parent is merged, we can simply
 close.

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

Re: [tor-bugs] #17238 [Core Tor/Tor]: prop224: Implement HSDir support

[Tor Bug Tracker & Wiki]

#17238: prop224: Implement HSDir support
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, |  Actual Points:  6+
  actualreviewpoints=2, TorCoreTeam201609,   |
  review-group-9, nickm-deferred-20161005|
Parent ID:  #12424   | Points:  parent
 Reviewer:  asn  |Sponsor:
 |  SponsorR-must
-+-
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 This should be in `needs_review` as I've replied to teor and nickm's
 review.

 https://gitlab.com/dgoulet/tor/merge_requests/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] #19167 [Core Tor/Tor]: torrc parsing b0rks on carriage-return

[Tor Bug Tracker & Wiki]

#19167: torrc parsing b0rks on carriage-return
-+-
 Reporter:  cypherpunks  |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.6
 Severity:  Normal   | Resolution:  fixed
 Keywords:  windows, crlf, lorax, easy, review-  |  Actual Points:
  group-10   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 I've added unit tests and a changes file, and cherry-picked as
 ab78a4df93d1aed26cb13343cdd012c8309a206f.  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] #20217 [Applications/Tor Browser]: Make sure that all .mar files required for generating incremental ones on OS X contain code-signed bits

[Tor Bug Tracker & Wiki]

#20217: Make sure that all .mar files required for generating incremental ones 
on
OS X contain code-signed bits
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  tbb-gitian, TorBrowserTeam201610R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

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


Comment:

 Looks good, thanks. Merged to master (commit
 9836227e4ae27123a3eb27167dc6dca13b5d1027).

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

Re: [tor-bugs] #20261 [Core Tor]: tor_fragile_assert() when Unix domain socket is used

[Tor Bug Tracker & Wiki]

#20261: tor_fragile_assert() when Unix domain socket is used
---+
 Reporter:  mcs|  Owner:  yawning
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor   |Version:  Tor: 0.2.9.2-alpha
 Severity:  Normal | Resolution:
 Keywords:  tbb-needs  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by nickm):

 Looks good to me, but I have one question.

 In case there are other places in the code --or there later become places
 in the code! -- where we compare two AF_UNIX addresses, maybe we should
 make them turn out _unequal_ by default?  I think that missing a match is
 probably safer than reporting a spurious match, right?  If you agree, I'll
 switch the hack to do a pointer comparison.

 (Also, a note on tor_addr_t : the main reason to use tor_addr_t at all,
 instead of sockaddr_storage, was to keep it small in the case where we
 need to create a zillion of them. So if we're going to make AF_UNIX
 firstclass, we'll need some other approach to keeping it small.)

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

Re: [tor-bugs] #19223 [Core Tor/Tor]: Potential heap corruption in do_getpass in routerkeys.c

[Tor Bug Tracker & Wiki]

#19223: Potential heap corruption in do_getpass in routerkeys.c
-+-
 Reporter:  asn  |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Low  |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-bug-bounty, 028-backport,|  Actual Points:
  isaremoved, nickwants029, review-group-10  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 lgtm; merged!

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

Re: [tor-bugs] #20325 [Metrics/CollecTor]: perform available space check using the partition recent is located on

[Tor Bug Tracker & Wiki]

#20325: perform available space check using the partition recent is located on
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  accepted
 Priority:  Low|  Milestone:  CollecTor 1.2.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-help   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by iwakeh):

 * keywords:   => metrics-help


Comment:

 Suited for getting acquainted with ColleTor build environment.

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

Re: [tor-bugs] #20334 [Metrics/metrics-lib]: explicitly log, which implementation is served by DescriptorSourceFactory

[Tor Bug Tracker & Wiki]

#20334: explicitly log, which implementation is served by 
DescriptorSourceFactory
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 1.5.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-help |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * keywords:   => metrics-help


Comment:

 Yes, either I write the patch or I can mentor this task.

 This is a ticket well suited to get acquainted with the metrics-lib build
 environment.

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

Re: [tor-bugs] #20301 [Applications/Tor Browser]: Bumping the compiler version to 6.2.0 breaks 64bit Tor Browser builds

[Tor Bug Tracker & Wiki]

#20301: Bumping the compiler version to 6.2.0 breaks 64bit Tor Browser builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Blocker  | Resolution:
 Keywords:  tbb-gitian, TorBrowserTeam201610R,   |  Actual Points:
  GeorgKoppen201610  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  new => needs_review
 * keywords:  tbb-gitian, TorBrowserTeam201610 => tbb-gitian,
 TorBrowserTeam201610R, GeorgKoppen201610


Comment:

 Okay, I bisected the problem (`PIE` enforcement breaks the compiler) and
 pushed a fix fro review to bug_20301
 (https://gitweb.torproject.org/user/gk/tor-browser-
 bundle.git/commit/?h=bug_20301=dfa3403825fc315168df3295f6062f5979b0a8a0)
 in my public repo.

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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

[Tor Bug Tracker & Wiki]

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by iwakeh):

 * status:  assigned => needs_review


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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

[Tor Bug Tracker & Wiki]

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  assigned
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Please review the seven commits on top of
 [https://gitweb.torproject.org/user/iwakeh/collector.git?h=task-18910
 -first-sync this branch].

 There are two new packages:
 `sync` for sync-merge functionality and `persist` as new modular way to
 persist descriptors (currently file-system, but could be extended or
 changed in future).  The latter should step by step be used for all
 persisting of descriptors, i.e. be used instead of the `store*` methods
 throughout the various modules.  (that is useful for removing the tight
 circular coupling of ArchiveWriter, DescriptorDownloader and
 DescriptorParser for example).

 Persisting is based on `DescriptorPersistence` defining methods for
 storing.  The classes extending `DescriptorPersistence` just need to
 define the explicit storage path.  For convenience
 `PersistenceUtils`provides date-time to string methods. Thus, providing
 methods for code that is repeatedly defined in the current code base.

 `CollecTorMain` extends `SyncManager` in a way that all synchronization
 options can be configured during runtime, i.e. syncing of a module can be
 turned on or off and sources can be changed without restart.

 (I'll add package-info later for the two packages.)

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

Re: [tor-bugs] #20207 [Applications/Tor Messenger]: IB and Tor Messenger seem to still be sharing a notification key on macOS

[Tor Bug Tracker & Wiki]

#20207: IB and Tor Messenger seem to still be sharing a notification key on 
macOS
+
 Reporter:  arlolra |  Owner:
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by arlolra):

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


Comment:

 Fixed in https://gitweb.torproject.org/tor-messenger-
 build.git/commit/?id=7a2c858e080c1862641c42d3a0df4f7eea6bddf9

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

Re: [tor-bugs] #20338 [Applications/Tor Messenger]: Prevent notification sharing in macOS between IB and TM

[Tor Bug Tracker & Wiki]

#20338: Prevent notification sharing in macOS between IB and TM
+
 Reporter:  huyvq   |  Owner:
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  #20207  | Points:
 Reviewer:  |Sponsor:
+
Changes (by arlolra):

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


Comment:

 Thanks!

 Landed as https://gitweb.torproject.org/tor-messenger-
 build.git/commit/?id=7a2c858e080c1862641c42d3a0df4f7eea6bddf9

 ps. huyvq, you could have just added an attachment on #20207, rather than
 opening a new ticket.  (But note that adding attachments doesn't send out
 notifications, so follow it up with an "I added a patch for this ...", or
 something.

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