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

[Tor Bug Tracker & Wiki]

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

 * 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] #18873 [Core Tor/Tor]: Refactor circuit_predict_and_launch_new()

[Tor Bug Tracker & Wiki]

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

Comment (by dgoulet):

 Oh I see right... only general purpose so it's safe. Ok I think it's fine
 indeed and yes adding a comment saying "Well GENERAL purpose has to be an
 origin circuit" would be good idea so we are clear that after those
 conditions downcasting to an origin circuit is safe :).

 The rest lgtm;

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

Re: [tor-bugs] #19646 [Obfuscation/meek]: Mac OS: wrong location for meek browser profile

[Tor Bug Tracker & Wiki]

#19646: Mac OS: wrong location for meek browser profile
-+-
 Reporter:  mcs  |  Owner:  dcf
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/meek |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-regression, tbb-6.0-issues,  |  Actual Points:
  meek, TorBrowserTeam201611R|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by brade):

 * status:  new => needs_review
 * cc: arthuredelstein (added)
 * keywords:  tbb-regression, tbb-6.0-issues, meek, TorBrowserTeam201610 =>
 tbb-regression, tbb-6.0-issues, meek, TorBrowserTeam201611R


Comment:

 Two patches are needed, one for meek (which I just attached to this
 ticket) and one for Tor Launcher, which is here:
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug19646-01=5ac452d86f93ee15ba3722afc606be862e8f3686

 Please review both patches.

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

Re: [tor-bugs] #20390 [Applications/Tor Browser]: Tor Crashes

[Tor Bug Tracker & Wiki]

#20390: Tor Crashes
--+---
 Reporter:  mwolfe|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 This ticket differs, if it's OOM then it was triggered somehow indirectly.
 {{{
 0   libnss3.dylib   0x0001004224ad
 PK11_ExitContextMonitor + 14\
 1   libnss3.dylib   0x000100423398
 PK11_DigestFinal + 264\
 }}}
 Similar backtrace reported for #20181

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

Re: [tor-bugs] #15055 [Core Tor/Tor]: Implement ed25519 link handshake

[Tor Bug Tracker & Wiki]

#15055: Implement ed25519 link handshake
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, prop-220, |  Actual Points:
  027-triaged-1-in, 028-triaged, |
  201511-deferred, 201512-deferred, tor-crypto-  |
  identity, tor-ed25519-proto,   |
  TorCoreTeam201609, nickm-deferred-20161005,|
  review-group-11|
Parent ID:  #15054   | Points:  parent
 Reviewer:  isis |Sponsor:
 |  SponsorU-must
-+-
Changes (by isis):

 * status:  needs_review => merge_ready


Comment:

 Okay, review complete: https://gitlab.com/nickm_tor/tor/merge_requests/7

 There's some minor complaints about documenting that we expect future
 AUTHCHALLENGE types to always be better than previously defined types,
 which is probably true, but if we're depending on that maybe we should
 note it?

 Overall, it looks good and can be 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] #18873 [Core Tor/Tor]: Refactor circuit_predict_and_launch_new()

[Tor Bug Tracker & Wiki]

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

Comment (by chelseakomlo):

 Ok, see changes at `g...@github.com:chelseakomlo/tor_patches.git`, branch
 `circuituse`. Thanks for all the great feedback!



 > * This comment confuses me as it doesn't appear to indicate what the
 function does or return. As I understand it, the function returns true iff
 the circuit matches some criteria that made it available for use.
 Documenting those criteria would be useful here. Also, what kind of
 circuit can be passed. Any kind? Or origin only or? as I see that it must
 be a GENERAL purpose for instance.
 > {{{
 > +/* Figure out how many circuits we have open that we can use. */
 > +STATIC int
 > +circuit_is_available_for_use(circuit_t *circ)
 > }}}


 Great, let me know if it is more clear now.


 > * I would honestly break this one down inside the function. This has
 quite the complicated conditions and the clearer the better as right now
 it's not that easy to get and also very easy to misunderstand:
 > {{{
 > needs_hs_client_circuits(...)
 > }}}


 Ok, I pulled some of the logic out into separate variables. Let me know if
 this makes it more readable/easy to understand.


 > * This condition has disappeared which is not good as
 `TO_ORIGIN_CIRCUIT()` in `circuit_is_available_for_use()` will explode if
 it's not an origin circuit.
 > {{{
 > -if (!CIRCUIT_IS_ORIGIN(circ))
 > -  continue;
 > }}}
 >
 >  and furthermore, this also could explode:
 >  {{{
 > cpath_build_state_t *build_state = TO_ORIGIN_CIRCUIT(circ)->build_state;
 >  }}}

 Hey! Ok, here is my understanding:

 A circuit with purpose CIRCUIT_PURPOSE_C_GENERAL will always be an origin
 circuit, because:

 in or.h
 {{{
 #define CIRCUIT_IS_ORIGIN(c) (CIRCUIT_PURPOSE_IS_ORIGIN((c)->purpose))
 #define CIRCUIT_PURPOSE_IS_ORIGIN(p) ((p)>CIRCUIT_PURPOSE_OR_MAX_)
 #define CIRCUIT_PURPOSE_OR_MAX_ 4
 #define CIRCUIT_PURPOSE_C_GENERAL 5
 }}}

 so in circuit_is_available_for_use, circuituse.c

 `origin_circ = TO_ORIGIN_CIRCUIT(circ);`

 should not explode, because of the previous check:

 {{{
 if (circ->purpose != CIRCUIT_PURPOSE_C_GENERAL)
   return 0;/* only pay attention to general
   purpose circs */
 }}}

 So that is the reason we should be able to safely remove

 {{{
 if (!CIRCUIT_IS_ORIGIN(circ))
   continue;
 }}}

 Let me know if you have a different understanding of this.

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:15 chelseakomlo]:
 [snip]
 > > * This condition has disappeared which is not good as
 `TO_ORIGIN_CIRCUIT()` in `circuit_is_available_for_use()` will explode if
 it's not an origin circuit.
 > > {{{
 > > -if (!CIRCUIT_IS_ORIGIN(circ))
 > > -  continue;
 > > }}}
 > >
 > >  and furthermore, this also could explode:
 > >  {{{
 > > cpath_build_state_t *build_state =
 TO_ORIGIN_CIRCUIT(circ)->build_state;
 > >  }}}
 >
 > Hey! Ok, here is my understanding:
 >
 > A circuit with purpose CIRCUIT_PURPOSE_C_GENERAL will always be an
 origin circuit, because:
 >
 > in or.h
 > {{{
 > #define CIRCUIT_IS_ORIGIN(c) (CIRCUIT_PURPOSE_IS_ORIGIN((c)->purpose))
 > #define CIRCUIT_PURPOSE_IS_ORIGIN(p) ((p)>CIRCUIT_PURPOSE_OR_MAX_)
 > #define CIRCUIT_PURPOSE_OR_MAX_ 4
 > #define CIRCUIT_PURPOSE_C_GENERAL 5
 > }}}
 >

 I see that `CIRCUIT_IS_ORIGIN(c)` translates to `if c >
 CIRCUIT_PURPOSE_OR_MAX_ then circ is origin`. We have lots of purposes
 that are above `CIRCUIT_PURPOSE_C_GENERAL = 5` in values like a client
 doing an HS introduction to a relay `CIRCUIT_PURPOSE_C_INTRODUCING = 6`.
 Am I missing something here?

 Origin circuits means that we (tor) initiated them and just with the HS,
 there are lots of purposes.

 I think you missed this syntax fix as well:

 {{{
 #define CBT_MAX_UNUSED_OPEN_CIRCUITS (MAX_UNUSED_OPEN_CIRCUITS- \
 CBT_MIN_REMAINING_PREEMPTIVE_CIRCUITS)
 }}}

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by chelseakomlo):

 Replying to [comment:17 dgoulet]:
 > Replying to [comment:15 chelseakomlo]:
 [snip]
 > > Hey! Ok, here is my understanding:
 > >
 > > A circuit with purpose CIRCUIT_PURPOSE_C_GENERAL will always be an
 origin circuit, because:
 > >
 > > in or.h
 > > {{{
 > > #define CIRCUIT_IS_ORIGIN(c) (CIRCUIT_PURPOSE_IS_ORIGIN((c)->purpose))
 > > #define CIRCUIT_PURPOSE_IS_ORIGIN(p) ((p)>CIRCUIT_PURPOSE_OR_MAX_)
 > > #define CIRCUIT_PURPOSE_OR_MAX_ 4
 > > #define CIRCUIT_PURPOSE_C_GENERAL 5
 > > }}}
 > >
 >
 > I see that `CIRCUIT_IS_ORIGIN(c)` translates to `if c >
 CIRCUIT_PURPOSE_OR_MAX_ then circ is origin`. We have lots of purposes
 that are above `CIRCUIT_PURPOSE_C_GENERAL = 5` in values like a client
 doing an HS introduction to a relay `CIRCUIT_PURPOSE_C_INTRODUCING = 6`.
 Am I missing something here?
 >
 > Origin circuits means that we (tor) initiated them and just with the HS,
 there are lots of purposes.


 In circuit_is_available_for_use, we exclude all circuits that don't have
 purpose `CIRCUIT_PURPOSE_C_GENERAL,` which is an origin circuit. See line
 1023.

 I can add a comment in the code explaining this if it isn't clear in the
 code.


 >
 > I think you missed this syntax fix as well:
 >
 > {{{
 > #define CBT_MAX_UNUSED_OPEN_CIRCUITS (MAX_UNUSED_OPEN_CIRCUITS- \
 > CBT_MIN_REMAINING_PREEMPTIVE_CIRCUITS)
 > }}}


 That change is in commit `extract magic numbers in circuituse.c`

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

Re: [tor-bugs] #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.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bridge-client, bridge-bypass  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 (asn has confirmed this on irc)

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

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

[Tor Bug Tracker & Wiki]

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

 * 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] #19991 [Core Tor/Tor]: Tor client slow to bootstrap using ClientUseIPv6 0

[Tor Bug Tracker & Wiki]

#19991: Tor client slow to bootstrap using ClientUseIPv6 0
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 This may well be an instance of #20499 or #19969.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by chelseakomlo):

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

 Changes added:
  - Syntax fix for CBT_MIN_REMAINING_PREEMPTIVE_CIRCUITS
  - Comment to explain general purpose circuits are always origin circuits.

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

Re: [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.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bridge-client, bridge-bypass  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 A further update from irc:
 {{{
 consensus updates rs
 and client using infor from ri
 it's about ipv6
 not about generic conflict
 ...
 it is when you paste meek bridge line and using plain tor relay
 ...
 start tcpdump and watch for ip.addr == 188.138.1.166
 then with green onion menu
 chose tor network setting, choose to use bridge, custom
 and paster
 meek 0.0.2.0:2 3C3A6134E4B5B7D1C18AD4E86EE23FAC63866554
 url=https://d2zfqthxsdq309.cloudfront.net/ front=a0.awsstatic.com
 it's fp for it
 it should to fail sometime during connections
 tor using this p to get extend info for desc fetching
 *fp
 if knows such relay it using relay addr
 insead of pt
 }}}

 188.138.1.166 is the direct address of the relay
 3C3A6134E4B5B7D1C18AD4E86EE23FAC63866554, not the transport address of
 https://d2zfqthxsdq309.cloudfront.net/

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  windows, mingw, backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by ice):

 Okay. After more looking into this, it seems that I did have the libmman.a
 in one lib directory, which I suspect is the one picked up by the
 configure script. However, due to the nature of MinGW64 there are now
 several library directories that GCC can access depending on the type of
 build x64, X86, etc. So even though libmman.a was picked up by configure,
 the build system looked for it in MinGW64/x86_64-w64-mingw32/lib directory
 instead of MinGW64/mingw/lib where it is found.

 Alas, building and installing the mman-win32 and installing it in the
 MinGW64/x86_64-w64-mingw32/lib and adding a link to it in the Makefile,
 results in the build succeeding albeit with failed tests related to mmap
 functions. As an aside the tests in the mman-win32 library all pass.

 At any rate, seeing that my vanilla GCC 5.3.0 (still referred to as
 MinGW64) does not contain the mman.h or the libmman.a, I tried hiding the
 mman.h by renaming it in GCC 4.7.3 (which is the one I used here) and
 issuing configure, make, and make test. Sure enough the configure script
 cannot find the header file, the build succeeds and all the tests pass.
 Except those referring to mmap of course are never tested, since they are
 now not available. I enclose the test output for reference. The question
 now is whether the removal of said functionality renders tor unusable, and
 whether or not that functionality exists in the tor distributed by the tor
 project whether in the Expert package or in the torbrowser.

 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] #8962 [Core Tor/Tor]: pathbias_count_use_attempt strange path state log lines

[Tor Bug Tracker & Wiki]

#8962: pathbias_count_use_attempt strange path state log lines
--+---
 Reporter:  jefnag|  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.5.8-rc
 Severity:  Normal| Resolution:
 Keywords:  tor-client|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by teor):

 Replying to [comment:10 hira]:
 > I am seeing this exact same message while fetching sites using pycurl
 (with a custom circuit made using stem). I have tor version v0.2.4.27 and
 the message goes something like this:
 >
 >
 > {{{
 > Mar 20 16:15:59.000 [notice] Bootstrapped 100%: Done.
 > Mar 20 16:17:16.000 [notice] New control connection opened.
 > Mar 20 16:17:19.000 [notice] pathbias_count_use_attempt(): Bug: Used
 circuit is in strange path state new. Circuit is a General-purpose client
 currently open.
 > Mar 20 16:17:20.000 [notice] pathbias_mark_use_success(): Bug: Used
 circuit 5 is in strange path state new. Circuit is a General-purpose
 client currently open.
 > Mar 20 16:17:20.000 [notice] pathbias_count_use_attempt(): Bug: Used
 circuit is in strange path state new. Circuit is a General-purpose client
 currently open.
 >
 >
 > }}}
 >
 >

 Custom circuits often trigger this bug, because of
 `__LeaveStreamsUnattached 1` (I think, or it's something else to do with
 control-port based circuit building).
 When I am building paths myself, I set `UseEntryGuards 0` to work around
 this.
 (This disables the pathbias detector.)
 But that doesn't work for the general 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] #20379 [Applications/Tor Browser]: Can't initially connect to bridges after new network connection

[Tor Bug Tracker & Wiki]

#20379: Can't initially connect to bridges after new network connection
--+--
 Reporter:  qbi   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by qbi):

 Here are the preliminary results based on my bisecting efforts. What did I
 do after starting the bisecting?

  1. `make clean`
  1. `./autogen.sh`
  1. `./configure --disable-asciidoc`
  1. `make`
  1. `cp src/or/tor $TBB/Browser/TorBrowser/Tor`
  1. Open TBB, go to https://check.torproject.org/ and click on the Q as
 well as the Volunteers link.
  1. Change to another network
  1. Check that the current network connections works without Tor
  1. Open some random links in the Q and volunteers page
  1. wait for some minutes
  1. In the good case it usually takes less than five minutes until the
 connection works. In the bad case it "never" works. Figure out what case
 it is.
  1. `git bisect good/bad`
  1. GOTO 1

 The output I got after the first round of bisecting is:

 {{{
 git bisect start
 # bad: [7010e8593978ff52e4f81e959f39e6215cd72a15] changes file for 20389
 git bisect bad 7010e8593978ff52e4f81e959f39e6215cd72a15
 # good: [9a4cac74fd2f4bb300830e06ff56f74ccf91e373] A day has passed.
 git bisect good 9a4cac74fd2f4bb300830e06ff56f74ccf91e373
 # bad: [6cc3397e26ff37d6f01471b83e0e5bb1b5aa8eee] Merge remote-tracking
 branch 'teor/fallback-script' into maint-0.2.8
 git bisect bad 6cc3397e26ff37d6f01471b83e0e5bb1b5aa8eee
 # bad: [ff3e90070fd21788ac2c1c9116f18c9b888c750a] Merge branch
 'maint-0.2.7'
 git bisect bad ff3e90070fd21788ac2c1c9116f18c9b888c750a
 # bad: [8a41d2a1d9eb65268d0f36e39d0ade77f5a39307] Merge branch
 'maint-0.2.7'
 git bisect bad 8a41d2a1d9eb65268d0f36e39d0ade77f5a39307
 # bad: [34b4da709d04a64e52f023f7fa54fdbab270546f] Fix a bunch more memory
 leaks in the tests.
 git bisect bad 34b4da709d04a64e52f023f7fa54fdbab270546f
 # good: [11e3db3ee876c8cc161d6bb019cbb19a1b623b6c] clean up whitespace
 git bisect good 11e3db3ee876c8cc161d6bb019cbb19a1b623b6c
 # bad: [cd14405a431cf351abe79441214899cfee5eb670] Merge remote-tracking
 branch 'origin/maint-0.2.7'
 git bisect bad cd14405a431cf351abe79441214899cfee5eb670
 # bad: [aaa27b995c03f6fe07849021e0302ecd9b720551] changes file for #16563
 git bisect bad aaa27b995c03f6fe07849021e0302ecd9b720551
 # good: [c44a94606a27e3dd9eb02083c05d87f9fe049b91] Use __FUNCTION__
 instead of __PRETTY_FUNCTION__
 git bisect good c44a94606a27e3dd9eb02083c05d87f9fe049b91
 # good: [bfd9dccdb8692a8d1d04c1c4004bc4bd3236c7b1] Merge remote-tracking
 branch 'origin/maint-0.2.7'
 git bisect good bfd9dccdb8692a8d1d04c1c4004bc4bd3236c7b1
 # good: [20ec030d9b6ff0e403e37d2161f3e53dfd6dd622] Fix compilation with
 openssl 1.1 by forcibly disabling some tests
 git bisect good 20ec030d9b6ff0e403e37d2161f3e53dfd6dd622
 # good: [41782bf3ac0ce1d2b3363585e652dfe944a9a58e] Merge remote-tracking
 branch 'tvdw/fix-16563'
 git bisect good 41782bf3ac0ce1d2b3363585e652dfe944a9a58e
 # first bad commit: [aaa27b995c03f6fe07849021e0302ecd9b720551] changes
 file for #16563
 }}}

 I'll do some rechecking over the next days, because this was a highly
 manual process which is prone to errors. Also it depends on the network
 conditions. So I want to see if I can reproduce this result. If it is
 done, I'll report back.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20540 [Metrics]: define log-levels for all java metrics-products

[Tor Bug Tracker & Wiki]

#20540: define log-levels for all java metrics-products
-+-
 Reporter:  iwakeh   |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 This is the parent issue for creating that document.

 The definitions should applied in child-tickets.

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

Re: [tor-bugs] #20534 [Core Tor/Tor]: Revise hard-coded download schedules

[Tor Bug Tracker & Wiki]

#20534: Revise hard-coded download schedules
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:  #20499| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Actually, there's not much point in revising these schedules - the
 exponential backoff code only pays attention to the first and last value
 in the schedule.

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

Re: [tor-bugs] #20379 [Applications/Tor Browser]: Can't initially connect to bridges after new network connection

[Tor Bug Tracker & Wiki]

#20379: Can't initially connect to bridges after new network connection
--+--
 Reporter:  qbi   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Replying to [comment:11 arma]:
 > Sounds like this one could be #19969. That bug started in 0.2.8.1-alpha.

 Here's one of the ChangeLog stanzas from the #19969 fix:

 {{{
   o Major bugfixes (clients on flaky network connections);
 - When Tor leaves standby because of a new application request, open
   circuits as needed to serve that request. Previously, we would
   potentially wait a very long time. Fixes part of bug 19969; bugfix
   on 0.2.8.1-alpha.
 }}}

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

Re: [tor-bugs] #20430 [Metrics/metrics-lib]: log-level definition for metrics-lib

[Tor Bug Tracker & Wiki]

#20430: log-level definition for metrics-lib
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #20540   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * parent:   => #20540


Comment:

 Ticket for applying the general log-level definitions from parent ticket.

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

Re: [tor-bugs] #20540 [Metrics]: define log-levels for all java metrics-products

[Tor Bug Tracker & Wiki]

#20540: define log-levels for all java metrics-products
-+-
 Reporter:  iwakeh   |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by iwakeh):

 A summary of what is in place or known already:

 * java projects should use slf4j (our default implementation is logback,
 but that is less important)
 * errors are possibly mailed by logging frameworks (in their default
 settings). So error level should be important (an 'action item') for
 operation.
 * info-level should give an indication that all things are running as
 expected.
 * maybe, log statistics to separate log files (as in Onionoo).
 * what else?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20541 [Metrics/Metrics website]: Add tor release date next to version strings in graph legends

[Tor Bug Tracker & Wiki]

#20541: Add tor release date next to version strings in graph legends
-+-
 Reporter:  fem  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 I made a regex to extract it from the tor !ChangeLog file:

 {{{
 /version (\S+) - (20\d\d-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01]))/
 }}}

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

Re: [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| Resolution:
 Keywords:  bridge-client, bridge-bypass  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 > We have been unable to confirm this

 So you need to close ticket as invalid or not a bug.

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

Re: [tor-bugs] #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):

 Further goals are
  1) to replace the tarball-script with a Java module of CollecTor and
  2) to make index.json as accurate as possible.

 For 2) it might be useful to remove the separately configurable create-
 index module.  The index should just be created after each (major) change,
 e.g. any download or sync module run.

 The tarball creation could run as a continuous background process that is
 stops during sync and download runs, i.e. basically 'stays out of the way'
 when other modules run.  It also relates to the index creation as it
 changes the 'archive' path.  Maybe, trigger an index-run after a
 substantial change?

 Other thoughts and general goals?

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

Re: [tor-bugs] #18074 [Applications/Tor Browser]: TBB Vagrantfile uses HTTP

[Tor Bug Tracker & Wiki]

#18074: TBB Vagrantfile uses HTTP
--+--
 Reporter:  miserlou  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:
 Keywords:  tbb-gitian|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by fem):

 Ubuntu builds (and signs) vagrant boxes for xenial https://cloud-
 images.ubuntu.com/releases/xenial/release/ubuntu-16.04-server-cloudimg-
 amd64-vagrant.box

 This reaches a bit beyond this ticket but maybe we should also consider
 upgrading to xenial from precise.

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

 This is the
 
[https://gitweb.torproject.org/user/iwakeh/exonerator.git/commit/?h=task-20523=8419a062967efcf25359d7c3c88c972afac177c0
 correct link].

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

Re: [tor-bugs] #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:
+-

Comment (by ice):

 Sorry I am not that familiar with trac. I attached the config-output.txt
 file to the comment above? Anyway. I meant to attach it here.

 So after reading the configure output, there is no mention of the items
 you listed above.

 I have also disabled HAVE_SYS_MMAN_H in orconfig.h and there was no
 change; same error as above-- after cleaning and rebuilding.

 The header files that mention getpagesize on my system are as follows:

 E:\dev\MinGW64\mingw\include\commctrl.h 142 KB C/C++ Header 2012-09-24
 2:56:07 PM 2014-05-26 8:40:29 PM 2014-05-26 8:40:29 PM 1
 1808 #define TBM_GETPAGESIZE (WM_USER+22)

 E:\dev\MinGW64\mingw\include\dbgeng.h 110 KB C/C++ Header 2012-09-24
 2:56:07 PM 2014-05-26 8:40:35 PM 2014-05-26 8:40:35 PM 3
 744 STDMETHOD(GetPageSize)(THIS_ PULONG Size) PURE;
 846 STDMETHOD(GetPageSize)(THIS_ PULONG Size) PURE;
 967 STDMETHOD(GetPageSize)(THIS_ PULONG Size) PURE;

 E:\dev\MinGW64\mingw\include\msrdc.h 16 KB C/C++ Header 2012-09-24 2:56:09
 PM 2014-05-26 8:41:03 PM 2014-05-26 8:41:03 PM 3
 261 STDMETHOD(GetPageSize)(THIS_ DWORD *pageSize) PURE;
 275 #define ISimilarityTraitsMapping_GetPageSize(This,pageSize)
 (This)->lpVtbl->GetPageSize(This,pageSize)

 I don't think they are related to this, or are they?

 More importantly, I am not so sure about mmap and friends on Windows. I
 think these are linux/unix specific. On the gcc-patches mailing list[1]
 one can read the following.

 "When compiling for windows, there shouldn't be any mmap/munmap references
 at all. While cygwin may supply some version of these, dlmalloc defines
 w32mmap/w32unmap which directly calls the appropriate routines for windows
 when WIN32 is defined (which I believe is always the case for the mingw
 compiler)."

 On MSDN[2] there is mention of CreateFileMapping, and I think this and
 friends are what are used on Windows.

 If you take a look at the mmapmodule[3] of Python, you'll notice how on
 Windows that function and its associated types are the ones used in place
 of mmap, etc.


 [1] https://gcc.gnu.org/ml/gcc-patches/2009-06/msg02240.html
 [2] https://msdn.microsoft.com/en-
 us/library/windows/desktop/aa366537(v=vs.85).aspx
 [3] https://github.com/python-git/python/blob/master/Modules/mmapmodule.c

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

Re: [tor-bugs] #20390 [Applications/Tor Browser]: Tor Crashes

[Tor Bug Tracker & Wiki]

#20390: Tor Crashes
--+---
 Reporter:  mwolfe|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by mwolfe):

 I thought it was insufficient memory, so I added 4GB, going from 4GB to
 8GB, but Tor still crashes (it uses about 5GB, which might have explained
 the problem with having only 4GB).

 I had four tabs open: independent.co.uk home page, an article about the
 election, fivethirtyeight.com and realclearpolitics.com when Tor crashed.

 I have attached the crash file from OS X 10.6.8

 I am now running Tor Browser 6.0.5 (based on Mozilla Firefox 45.4.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] #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):

 Oh, I forgot to commit the move of logging.properties into resources.
 
[https://gitweb.torproject.org/user/iwakeh/exonerator.git/commit/?h=task-20523=f6668f1bccd7ea352263b4bd99ffd40d98f88bf8
 amended here]

 I'd rather keep logging configuration in 'resources' than in 'webapp'.

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

Comment (by teor):

 Ok, your configure output says:
 {{{
 checking sys/mman.h usability... yes
 checking sys/mman.h presence... yes
 checking for sys/mman.h... yes
 }}}
 https://trac.torproject.org/projects/tor/attachment/ticket/20530
 /configure-output.txt#L264

 This is why HAVE_SYS_MMAN_H gets redefined in orconfig.h every time you
 run configure.
 (If the header did not exist, tor would not try to use the functions in
 it.)

 If you want to try rebuilding without HAVE_SYS_MMAN_H:
 Disable it in orconfig.h and then '''do not run configure,''' just run
 make.
 If this works, we can fix the order of the alternatives in compat.c so
 that we check for WIN32 first, then HAVE_SYS_MMAN_H.

 If you want to try rebuilding with HAVE_SYS_MMAN_H:
 What are the contents of sys/mman.h on your machine?
 Does it contain mmap, munmap, or getpagesize?

 If you want to try building with dlmalloc, that could be a bit harder.
 Do you have dlmalloc installed? dlmalloc.c or dlmalloc.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] #20379 [Applications/Tor Browser]: Can't initially connect to bridges after new network connection

[Tor Bug Tracker & Wiki]

#20379: Can't initially connect to bridges after new network connection
--+--
 Reporter:  qbi   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Replying to [comment:6 qbi]:
 >  3. I tried the network change with version 6.5a1 and waited now for ~30
 minutes. I constantly reloaded the site when I got the timeout message
 from Firefox. So far without success. After I opened the network menu and
 closed it, the page opened. So 6.5a1 has the problem which I described
 above.

 Sounds like this one could be #19969. That bug started in 0.2.8.1-alpha.

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

Re: [tor-bugs] #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):

 * status:  needs_revision => needs_review


Comment:

 Thanks for those fixes.  The only thing I'm still missing is
 `logging.properties`.  Mind taking a look at the last commit in
 [https://gitweb.torproject.org/user/karsten/exonerator.git/log/?h=task-20523
 my updated 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

Re: [tor-bugs] #19991 [Core Tor/Tor]: Tor client slow to bootstrap using ClientUseIPv4 0 (was: Tor client slow to bootstrap using ClientUseIPv6 0)

[Tor Bug Tracker & Wiki]

#19991: Tor client slow to bootstrap using ClientUseIPv4 0
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:
Parent ID:| Points:  1
 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] #20545 [Core Tor/Tor]: Default Value Incorrect in Tor Manual

[Tor Bug Tracker & Wiki]

#20545: Default Value Incorrect in Tor Manual
--+--
 Reporter:  agd   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  doc   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * keywords:   => doc
 * milestone:   => 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] #20414 [Applications/Tor Browser]: Donation banner on about:tor page for 2016 campaign

[Tor Bug Tracker & Wiki]

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

Comment (by arthuredelstein):

 After feedback from Shari, I've modified the text and layout somewhat.
 Please see images below.

 The new patches are here:
 https://github.com/arthuredelstein/torbutton/commits/20414+8
 The patch for strings alone is at
 
https://github.com/arthuredelstein/torbutton/commit/9eed15d158f4763471150a97c83bb8d772774d57

 [[Image(banner1a.png)]]
 [[Image(banner2a.png)]]
 [[Image(banner3a.png)]]
 [[Image(banner4a.png)]]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  windows, mingw, backport,|  Actual Points:  0.3
  029-proposed, CoreTorTeam201611|
Parent ID:   | Points:  0.3
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  new => needs_review
 * version:   => Tor: unspecified
 * milestone:  Tor: 0.3.0.x-final => Tor: 0.2.9.x-final
 * points:   => 0.3
 * actualpoints:   => 0.3
 * keywords:  windows, mingw, backport => windows, mingw, backport,
 029-proposed, CoreTorTeam201611


Comment:

 Ok, so we need to prefer sys/mman.h when it's available, even on Windows,
 so Cygwin can handle mmap() and fork() correctly. (Although this is not so
 important now, because Tor uses threads, rather than forking.)

 I think tor is missing a check for getpagesize, and that's causing the
 problem.

 We could also check for linkage to the mmap, munmap, and getpagesize
 functions, but I'm going to leave that for now, because other environments
 replace those functions using macros. (There would be nothing to link to,
 even though the code is correct.)

 Can you please test this branch?
 https://github.com/teor2345/tor/tree/fix-mingw-pagesize

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

Re: [tor-bugs] #20464 [Metrics/Consensus Health]: Consensus-Health vote_data table gets out of date when a dirauth is added

[Tor Bug Tracker & Wiki]

#20464: Consensus-Health vote_data table gets out of date when a dirauth is 
added
--+
 Reporter:  tom   |  Owner:  tom
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by tom):

 * 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] #18873 [Core Tor/Tor]: Refactor circuit_predict_and_launch_new()

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => merge_ready
 * reviewer:  dgoulet => dgoulet, teor


Comment:

 Thanks chelsea! This lgtm; Builds properly and test passes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by chelseakomlo):

 * 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] #20545 [- Select a component]: Default Value Incorrect in Tor Manual

[Tor Bug Tracker & Wiki]

#20545: Default Value Incorrect in Tor Manual
--+-
 Reporter:  agd   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 At https://www.torproject.org/docs/tor-manual.html.en :

 "AutomapHostsOnResolve 0|1

 When this option is enabled, and we get a request to resolve an
 address that ends with one of the suffixes in AutomapHostsSuffixes, we map
 an unused virtual address to that address, and return the new virtual
 address. This is handy for making ".onion" addresses work with
 applications that resolve an address and then connect to it. (Default: 0)"



 The Default is actually 1.  I know that because the value in my torrc file
 is 1 and I can access sigaintevyh2rzvw.onion.  I'm running Tails 2.6 with
 the included Tor Browser (6.0.5), and the relevant torrc is at
 etc/tor/torrc .

 I have left the options below at their defaults because I'd just be
 guessing.

 It should be very simple to confirm and fix.

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

Re: [tor-bugs] #20480 [Metrics/Consensus Health]: Faravahar is not showing up in graphs on consensus health

[Tor Bug Tracker & Wiki]

#20480: Faravahar is not showing up in graphs on consensus health
--+
 Reporter:  tom   |  Owner:  tom
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by tom):

 * 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] #20545 [Core Tor/Tor]: Default Value Incorrect in Tor Manual

[Tor Bug Tracker & Wiki]

#20545: Default Value Incorrect in Tor Manual
--+-
 Reporter:  agd   |  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


Comment:

 Hm? No, it defaults to 0.

 From config.c:
 {{{
   V(AutomapHostsOnResolve,   BOOL, "0"),
 }}}

 Maybe you have a line in your torrc file that changes it to 1? That would
 not be what I would call a default. :)

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

Re: [tor-bugs] #17847 [Core Tor/Tor]: Unify router_pick_directory_server_impl and router_pick_trusteddirserver_impl

[Tor Bug Tracker & Wiki]

#17847: Unify router_pick_directory_server_impl and
router_pick_trusteddirserver_impl
---+--
 Reporter:  teor   |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy refactor  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by ahf):

 I have a partial fix, that could use a review and an iteration or two, in
 the `ahf/bugs/17847` branch on https://gitlab.com/ahf/tor.git

 Direct link to the branch:
 https://gitlab.com/ahf/tor/commits/ahf/bugs/17847

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

Re: [tor-bugs] #19646 [Obfuscation/meek]: Mac OS: wrong location for meek browser profile

[Tor Bug Tracker & Wiki]

#19646: Mac OS: wrong location for meek browser profile
-+-
 Reporter:  mcs  |  Owner:  dcf
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/meek |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-regression, tbb-6.0-issues,  |  Actual Points:
  meek, TorBrowserTeam201611R|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Both patches look good to me.

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

Re: [tor-bugs] #20062 [Applications/Tor Messenger]: Make stripping signatures reproducible on Tor Messenger .exe files

[Tor Bug Tracker & Wiki]

#20062: Make stripping signatures reproducible on Tor Messenger .exe files
+
 Reporter:  boklm   |  Owner:  huyvq
 Type:  task| 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:  assigned => closed
 * resolution:   => fixed


Comment:

 Closed by https://gitweb.torproject.org/tor-messenger-
 build.git/commit/?id=f70daf0b2759d2e7b8df2a974e6b6143d20c1023

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

 Addendum to comment:1:

 * descriptor writing should only be performed by the 'o.t.c.persist'
 package
 * One class of each module should extend CollecTorMain.  It should be
 named Main, e.g. RelayMain or BridgeMain, and contain the code for
 structuring the modules work, i.e. no detailed functionality.
 * The other classes of each module should provide the actual module
 functionality.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  reopened
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by twim):

 Sorry, I thought that I've lost this branch and this ticket is not useful
 anymore. :\
 The relevant branch is `fontawesome` at https://github.com/nogoegst/atlas.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  windows, mingw, backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * keywords:  windows, mingw => windows, mingw, backport
 * 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] #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:  merge_ready
 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 dgoulet):

 Right it does, I actually removed `\"%s\"` in favor of `%s` in I think 3
 callsites. Is that ok?

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

Re: [tor-bugs] #20516 [Metrics/CollecTor]: CollecTor's exitlists module should avoid httpurlconnection

[Tor Bug Tracker & Wiki]

#20516: CollecTor's exitlists module should avoid httpurlconnection
---+-
 Reporter:  iwakeh |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-help   |  Actual Points:
Parent ID:  #8799  | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 See also #20543.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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_revision
 Priority:  Low   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => needs_revision
 * priority:  Medium => Low
 * points:   => 0.1
 * milestone:   => Tor: 0.3.0.x-final
 * keywords:   => tor-hs
 * reviewer:   => dgoulet


Comment:

 The patch looks good but I can't apply it on git master... One issue that
 I can't figure out. Can you retry on current git master? Sorry about 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] #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:  merge_ready
 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 twim):

 Oops, was looking at this upside down. ;) It's okay 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] #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:  closed
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by karsten):

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


Comment:

 Looks good, merged to master.  Thanks!  Closing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20542 [Metrics/CollecTor]: structure bridgedescs and modernize

[Tor Bug Tracker & Wiki]

#20542: structure bridgedescs 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: |
---+
 * All parsing should be delegated to metrics-lib code.
 * Create 'BridgeMain'.

 Current picture:
 BridgeSnapshotReader only has a constructor of more than 200 lines of
 code.
 BridgeDescriptorParser actually only determines the descriptor type and
 SanitizedBridgesWriter performes parsing and obfuscation.

 {{{
++
| SanitizedBridgesWriter |
+---o+---+
 --/   /-   \
  --//-  \
   --/ /- \
--/  /-\
 --/   /-+--++
 +--+-o---+  |  BridgeSnapshotReader |
 | BridgeDescriptorParser +--o---+
 ++

 X o--+ Y : X holds a Y reference somewhere
 }}}

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

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:  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


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

Re: [tor-bugs] #20481 [Core Tor/Tor]: Section 3.8.1 of dir-spec is out of date again

[Tor Bug Tracker & Wiki]

#20481: Section 3.8.1 of dir-spec is out of date again
--+
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


Comment:

 We merged those for 030 so let's try go get our spec up to date by the
 time we release.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  Low   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by twim):

 * 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] #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:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  windows, mingw, backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by ice):

 My bad. I don't know why I was looking for mmap.h in the configure output.
 Also HAVE_SYS_MMAN_H was not (re)defined in orconfig.h; when you suggested
 I disable it, I understood it to mean undefine it as it was not defined
 there.

 At any rate that mman.h is indeed on my system, but I think it is an
 artifact from the person (or build system) that build the compiler. There
 is no libmman.a on my system and that file must have come from this
 repository: https://github.com/witwall/mman-win32.

 I downloaded it and built the libmman.a and installed it. Edited Makefile
 to link with that libary and then issued "make". And success: building tor
 went without problems.

 Issuing make test however, resulted in 3 fails and 6 skipped tests. I am
 attaching the make test output for reference. If the fails are expected
 then maybe we document all this somewhere. If the fails are a sign of a
 more serious problem, I am open for suggestions.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20543 [Metrics/CollecTor]: restructuring of exitlists module

[Tor Bug Tracker & Wiki]

#20543: restructuring of exitlists module
---+
 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: |
---+
 A smaller module.

 ExitList processing:

 * download (see ticket #20516 for replacing httpurlconnection)
 * parses data using metrics-lib
 * verifies age of most recent measurement
 * looks for the last three lists received (What is this statistics for?)
 * performs a clean-up in recent-folder by cut-off time.

 These five steps could be structured a little.
 The cleaning step should be moved to a general place (cf. note in parent
 ticket).

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

 Addendum comment:1:
 Several modules perform some sort of cleaning, i.e. erase files based on
 their age.  This should be offered by a utility class/package.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  merge_ready
 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 dgoulet):

 * status:  needs_review => merge_ready


Comment:

 lgtm; I made an extra fixup commit on top to fix minor things where we
 kept the print format `\"%s\"` which would ultimately add again the double
 quotes.

 I also signed off the commit and slightly changed the name :).

 See `bug20527_030_01`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  Tor:
 |  0.2.???
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, research, tor-spec, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * keywords:  tor-hs, research => tor-hs, research, tor-spec, prop224
 * milestone:   => Tor: 0.2.???


Comment:

 Would be good also to extend this analysis to next generation HS (prop224)
 as it will become important to figure out the behavior we want before
 deployment.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  merge_ready
 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 twim):

 Replying to [comment:3 dgoulet]:
 > lgtm; I made an extra fixup commit on top to fix minor things where we
 kept the print format `\"%s\"` which would ultimately add again the double
 quotes.

 AFAIK, `escaped()` already makes strings quoted:

 {{{
  Allocate and return a new string representing the contents of s,
  surrounded by quotes and using standard C escapes.
 }}}
 Am I wrong?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  merge_ready
 Priority:  Low   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 Thanks twim!

 I've signed off commit in: `bug20526_030_01`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.9
 Severity:  Normal| Resolution:
 Keywords:  regression?   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * 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] #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 cypherpunks):

 what about ultrasurf?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20536 [Core Tor/Tor]: Should tor keep on retrying, even if it has reached the failure limit?

[Tor Bug Tracker & Wiki]

#20536: Should tor keep on retrying, even if it has reached the failure limit?
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  regression
Actual Points:|  Parent ID:  #20499
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 In #20499, when relays reach the download failure limit, they stop
 downloading consensuses.

 I think this behaviour is desirable for relays that will never get a good
 consensus (if they are too old, for example).

 But for relays that have a temporary issue, it is really unhelpful.
 Perhaps tor should retry every few days no matter what?

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

 Ok, and finally, for the bahaviour at the failure limit, I opened #20536.

 Some of these will also interact with #19969, we should consider both
 tickets when doing the fixes.

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

 Well, they're in Australia, so latency is high, and measured bandwidth is
 low. But I'm not sure that would cause so many failures. Maybe something
 with OpenBSD?

 My relay at the same provider has AccountingMax set, and has disabled its
 DirPort, so it's much harder to interrogate. It's on FreeBSD, but on
 0.2.8.7 (still waiting for a package update), and up to date with its
 consensuses.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:17 teor]:
 > But at some exponent, the wait time becomes indistinguishable from
 failure.
 > (Which is why we need to make sure requests trigger a new attempt.)

 It is good that we have the belt-and-suspenders fix in place where new
 client requests trigger a new attempt -- but that trick only works for
 clients. We should make sure that directory mirrors also have some way to
 reliably keep trying, and same for exit relays because of the
 should_refuse_unknown_exits() thing. Basically all of the reasons in
 directory_fetches_from_authorities().

 > 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?

 It seems to me that any design that effectively has a "now you won't ask
 for the consensus anymore" possible outcome is a scary one here. Speaking
 of which. is there a place I should look to read about our current
 download design? I only know the one I wrote some years ago, and it looks
 like it's changed since then.

 > Firstly, because they get incremented twice for each failure.

 I haven't looked into that one, but if so, can we open a new ticket for
 this (what looks like separate) bug?

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

 Actually, I think I drove my consensus download failure count up to 8 over
 the course of about ten minutes -- it launches each new try within a
 second of when the last one failed:
 {{{
 Oct 24 03:51:12.713 [info] update_consensus_bootstrap_attempt_downloads():
 Launching microdesc bootstrap mirror networkstatus consensus download.
 Oct 24 03:51:12.713 [info] update_consensus_bootstrap_attempt_downloads():
 Launching microdesc bootstrap authority networkstatus consensus download.
 Oct 24 03:51:42.725 [info] update_consensus_bootstrap_attempt_downloads():
 Launching microdesc bootstrap authority networkstatus consensus download.
 Oct 24 03:52:36.747 [info] update_consensus_bootstrap_attempt_downloads():
 Launching microdesc bootstrap authority networkstatus consensus download.
 Oct 24 03:54:14.787 [info] update_consensus_bootstrap_attempt_downloads():
 Launching microdesc bootstrap authority networkstatus consensus download.
 Oct 24 03:57:19.855 [info] update_consensus_bootstrap_attempt_downloads():
 Launching microdesc bootstrap authority networkstatus consensus download.
 Oct 24 04:00:48.938 [info] update_consensus_bootstrap_attempt_downloads():
 Launching microdesc bootstrap authority networkstatus consensus download.
 }}}

 My laptop was closed (asleep) for more than a day, so when it woke up its
 consensus was more than 24 hours old, so it immediately jumped to
 bootstrap mode for its downloads. Ten minutes later, it had given up
 permanently.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:21 arma]:
 > Replying to [comment:17 teor]:
 > > But at some exponent, the wait time becomes indistinguishable from
 failure.
 > > (Which is why we need to make sure requests trigger a new attempt.)
 >
 > It is good that we have the belt-and-suspenders fix in place where new
 client requests trigger a new attempt -- but that trick only works for
 clients. We should make sure that directory mirrors also have some way to
 reliably keep trying, and same for exit relays because of the
 should_refuse_unknown_exits() thing. Basically all of the reasons in
 directory_fetches_from_authorities().
 >
 > > 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?
 >
 > It seems to me that any design that effectively has a "now you won't ask
 for the consensus anymore" possible outcome is a scary one here. Speaking
 of which. is there a place I should look to read about our current
 download design? I only know the one I wrote some years ago, and it looks
 like it's changed since then.

 Proposal 210 is close, but it's been modified by at least you, me, and
 andrea since then.

 > > Firstly, because they get incremented twice for each failure.
 >
 > I haven't looked into that one, but if so, can we open a new ticket for
 this (what looks like separate) bug?

 #20533

 > > And secondly, because the laptop was offline for 12? hours?
 >
 > Actually, I think I drove my consensus download failure count up to 8
 over the course of about ten minutes -- it launches each new try within a
 second of when the last one failed:
 > {{{
 > Oct 24 03:51:12.713 [info]
 update_consensus_bootstrap_attempt_downloads(): Launching microdesc
 bootstrap mirror networkstatus consensus download.
 > Oct 24 03:51:12.713 [info]
 update_consensus_bootstrap_attempt_downloads(): Launching microdesc
 bootstrap authority networkstatus consensus download.
 > Oct 24 03:51:42.725 [info]
 update_consensus_bootstrap_attempt_downloads(): Launching microdesc
 bootstrap authority networkstatus consensus download.
 > Oct 24 03:52:36.747 [info]
 update_consensus_bootstrap_attempt_downloads(): Launching microdesc
 bootstrap authority networkstatus consensus download.
 > Oct 24 03:54:14.787 [info]
 update_consensus_bootstrap_attempt_downloads(): Launching microdesc
 bootstrap authority networkstatus consensus download.
 > Oct 24 03:57:19.855 [info]
 update_consensus_bootstrap_attempt_downloads(): Launching microdesc
 bootstrap authority networkstatus consensus download.
 > Oct 24 04:00:48.938 [info]
 update_consensus_bootstrap_attempt_downloads(): Launching microdesc
 bootstrap authority networkstatus consensus download.
 > }}}
 >
 > My laptop was closed (asleep) for more than a day, so when it woke up
 its consensus was more than 24 hours old, so it immediately jumped to
 bootstrap mode for its downloads. Ten minutes later, it had given up
 permanently.

 That timing is off from what I would expect - when I designed it, it was:
 Fallbacks: 0, 1, 5, 16, 3600, ...
 Authorities: 10, 21, 3600, ...

 But if we're skipping two on every failure, it could become:
 Fallbacks: 0, (1 or 5 depending on exact failure timing), 3600, ...
 Authorities: 10, 3600, ...
 And if the client has all the authorities as down, I guess it won't even
 try them.

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

[tor-bugs] #20534 [Core Tor/Tor]: Revise hard-coded download schedules

[Tor Bug Tracker & Wiki]

#20534: Revise hard-coded download schedules
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  regression
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+
 We should tweak the download schedules in config.c based on what we've
 learned in #20499.

 These schedules should retry sooner than never:
 TestingServerDownloadSchedule
 TestingClientDownloadSchedule

 These schedules retry at most every 2 hours, should that be higher?
 TestingServerConsensusDownloadSchedule

 These schedules retry at most every 12 hours, should that be higher?
 lower?
 TestingClientConsensusDownloadSchedule

 These schedules retry at most every 73 hours, should that be lower?
 Should we try more times before jumping to retrying after an hour?
 ClientBootstrapConsensusAuthorityDownloadSchedule
 ClientBootstrapConsensusFallbackDownloadSchedule
 ClientBootstrapConsensusAuthorityOnlyDownloadSchedule

 Should we try more than 7 or 8 times to get directory documents?
 TestingConsensusMaxDownloadTries
 ClientBootstrapConsensusMaxDownloadTries
 TestingDescriptorMaxDownloadTries
 TestingMicrodescMaxDownloadTries
 TestingCertMaxDownloadTries

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:21 arma]:
 > Replying to [comment:17 teor]:
 > > But at some exponent, the wait time becomes indistinguishable from
 failure.
 > > (Which is why we need to make sure requests trigger a new attempt.)
 >
 > It is good that we have the belt-and-suspenders fix in place where new
 client requests trigger a new attempt -- but that trick only works for
 clients. We should make sure that directory mirrors also have some way to
 reliably keep trying, and same for exit relays because of the
 should_refuse_unknown_exits() thing. Basically all of the reasons in
 directory_fetches_from_authorities().
 >
 > > 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?
 >
 > It seems to me that any design that effectively has a "now you won't ask
 for the consensus anymore" possible outcome is a scary one here. Speaking
 of which. is there a place I should look to read about our current
 download design? I only know the one I wrote some years ago, and it looks
 like it's changed since then.

 I logged #20534 for this. There are existing cases where we give up
 forever. We should tune them to do what we think we want.

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

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):

 Replying to [comment:19 arma]:
 > What is wrong with your relay set-up such that they both fail to get a
 consensus at bootstrap? :)

 Ah, no, they both got a perfectly good consensus at startup. The
 "failures" every minute after that are from them having a fresh consensus,
 requesting a new one anyway and getting 304 Not Modified in response.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20535 [Core Tor/Tor]: A 304 "Not Modified" should update the time to when we next expect a modification

[Tor Bug Tracker & Wiki]

#20535: A 304 "Not Modified" should update the time to when we next expect a
modification
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  regression
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+
 In #20499, we discovered that when a 304 "Not Modified" is received,
 relays try too hard when 09a0f2d0b is reverted, and don't try enough when
 it is applied.

 Instead, we should retry when we next expect the document to be modified.
 And if we don't know, we should retry on some sensible schedule.

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

Re: [tor-bugs] #20534 [Core Tor/Tor]: Revise hard-coded download schedules

[Tor Bug Tracker & Wiki]

#20534: Revise hard-coded download schedules
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:  #20499| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * parent:   => #20499


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

Re: [tor-bugs] #20533 [Core Tor/Tor]: Each download request should only increment the failure count once

[Tor Bug Tracker & Wiki]

#20533: Each download request should only increment the failure count once
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:  #20499| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * parent:   => #20499


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

Re: [tor-bugs] #20535 [Core Tor/Tor]: A 304 "Not Modified" should update the time to when we next expect a modification

[Tor Bug Tracker & Wiki]

#20535: A 304 "Not Modified" should update the time to when we next expect a
modification
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:  #20499| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * parent:   => #20499


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

Re: [tor-bugs] #20535 [Core Tor/Tor]: A 304 "Not Modified" should update the time to when we next expect a modification

[Tor Bug Tracker & Wiki]

#20535: A 304 "Not Modified" should update the time to when we next expect a
modification
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:  #20499| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 This also affects #19969

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

Re: [tor-bugs] #20533 [Core Tor/Tor]: Each download request should only increment the failure count once

[Tor Bug Tracker & Wiki]

#20533: Each download request should only increment the failure count once
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:  #20499| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 This also affects #19969

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

Re: [tor-bugs] #20536 [Core Tor/Tor]: Should tor keep on retrying, even if it has reached the failure limit?

[Tor Bug Tracker & Wiki]

#20536: Should tor keep on retrying, even if it has reached the failure limit?
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:  #20499| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 This also affects #19969

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

Re: [tor-bugs] #20534 [Core Tor/Tor]: Revise hard-coded download schedules

[Tor Bug Tracker & Wiki]

#20534: Revise hard-coded download schedules
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:  #20499| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Some of these schedules also affect #19969

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20533 [Core Tor/Tor]: Each download request should only increment the failure count once

[Tor Bug Tracker & Wiki]

#20533: Each download request should only increment the failure count once
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  regression
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 From #20499:

 At startup (or reload) the relay fetches the microdesc consensus

 1 minute later it tries to fetch it again
 (update_consensus_networkstatus_downloads() is called) and receives a 304
 response as it hasn't been modified

 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)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:24 rubiate]:
 > Replying to [comment:19 arma]:
 > > What is wrong with your relay set-up such that they both fail to get a
 consensus at bootstrap? :)
 >
 > Ah, no, they both got a perfectly good consensus at startup. The
 "failures" every minute after that are from them having a fresh consensus,
 requesting a new one anyway and getting 304 Not Modified in response.

 So your reverted relay is bad: it retries 5 times every hour, when it
 should only try once an hour.
 And your bad relay is also bad: it retries never, when it should at least
 try once an hour.

 I opened #20535 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] #20362 [Core Tor/Tor]: Bug: Used circuit is in strange path state new

[Tor Bug Tracker & Wiki]

#20362: Bug: Used circuit is in strange path state new
--+--
 Reporter:  lior  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * milestone:   => 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

[tor-bugs] #20544 [Internal Services/Service - git]: create meek repo for brade

[Tor Bug Tracker & Wiki]

#20544: create meek repo for brade
-+
 Reporter:  brade|  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Please create /user/brade/meek.git.  Description should be "Kathy's meek
 Repository".

 This is needed for meek/Tor Browser integration work.

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

Re: [tor-bugs] #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.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bridge-client, bridge-bypass  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by asn):

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


Comment:

 Assigning this to 0.3.0 since a bridge bypass is important to fix.

 (Also seems like #20528 and #20531 are related tickets)

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

Comment (by iwakeh):

 Replying to [comment:3 karsten]:
 > 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.)
 >

 Sure, please find the
 
[https://gitweb.torproject.org/user/iwakeh/exonerator.git/commit/?h=task-20523=fda2f01de78b68dca9726291de3372910ad7996c
 amended branch].

 Thanks for checking this thoroughly!

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

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:
--+--

Comment (by cypherpunks):

 No, it doesn't sound as right explanation, and solution can't work if so.
 You no need to switch client mode, you need to get new bridge (so client
 doesn't knew bridge desc for right addr:port pair yet) with public relay's
 fp, for warm started tbb.

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

Re: [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   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by iwakeh):

 * cc: iwakeh (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

[tor-bugs] #20537 [Community/Training]: Tor Browser User Manual needs meta section

[Tor Bug Tracker & Wiki]

#20537: Tor Browser User Manual needs meta section
+
 Reporter:  weasel  |  Owner:  Kelley
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Training  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+
 The Tor Browser User Manual on https://tb-manual.torproject.org/windows
 /en-US/ needs a section covering
  a) where to find the source,
  b) how it is licensed, and
  c) where and how to report bugs.

 Cheers,

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  reopened
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by karsten):

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


Comment:

 Hmm, what's the reason for closing this ticket?  Maybe it's something that
 somebody else wants to pick up?  Or is there a technical reason?  Re-
 opening for now to not lose track of it.

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

Re: [tor-bugs] #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 iwakeh):

 * cc: iwakeh (added)


Comment:

 cc'ed myself in order to have this on my list.

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

[tor-bugs] #20538 [Community/Outreach]: TB manual single page

[Tor Bug Tracker & Wiki]

#20538: TB manual single page
+--
 Reporter:  weasel  |  Owner:  mrphs, ailanthus
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+--
 Can we please (additionally if you like) have a single-page build of the
 manual?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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]: Make sure bridge clients update bridges when options are updated (was: Defend against bridge bypass with misconfigured bridges)

[Tor Bug Tracker & Wiki]

#20528: Make sure bridge clients update bridges when options are updated
---+--
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  bridge-client  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+--
Changes (by teor):

 * keywords:  bridge-client, bridge-bypass => bridge-client


Old description:

> 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,
> }}}

New description:

 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,
 }}}

--

Comment:

 It might not explain your issue, but it is still a bug.

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

Re: [tor-bugs] #20528 [Core Tor/Tor]: Make sure bridge clients update bridges when options are updated

[Tor Bug Tracker & Wiki]

#20528: Make sure bridge clients update bridges when options are updated
---+--
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  bridge-client  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 ok, some another bug.

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

Re: [tor-bugs] #20535 [Core Tor/Tor]: A 304 "Not Modified" should update the time to when we next expect a modification

[Tor Bug Tracker & Wiki]

#20535: A 304 "Not Modified" should update the time to when we next expect a
modification
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:  #20499| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Here's my analysis:

 On bootstrap:
 * download_status_increment_attempt increments the schedule for each
 attempt
 * each attempt causes the delay to be increased exponentially (rather than
 using the actual hard-coded Bootstrap schedules)

 After downloading the consensus:
 * download_status_increment_failure doesn't increase the schedule on 503
 (server unavailable), even though it probably should, rather than retrying
 immediately
 * download_status_increment_failure increases the schedule exponentially
 on 304 (not modified), or perhaps doesn't increase the schedule at all
 (see #20499), even though it should probably only increase it up to the
 next time we expect the document to be modified (1 hour)
 * download_status_schedule_get_delay uses the schedule to increase the
 backoff, if the schedule isn't increased, the backoff isn't either (rather
 than using the actual hard-coded Bootstrap schedules)

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

Re: [tor-bugs] #20535 [Core Tor/Tor]: A 304 "Not Modified" should update the time to when we next expect a modification

[Tor Bug Tracker & Wiki]

#20535: A 304 "Not Modified" should update the time to when we next expect a
modification
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:  #20499| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 We took schedules carefully tuned in 0.2.8 to make sure that it could
 survive 7 relay failures and still bootstrap in 30 seconds with 99.9%
 reliability, and implemented exponential backoff in 0.2.9 in a way that
 causes retries 5 times in 10 seconds in some cases, and in other cases
 retries twice in the first 30 seconds.

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

[tor-bugs] #20539 [Core Tor/Tor]: Make sure fallback directories deliver a recent consensus

[Tor Bug Tracker & Wiki]

#20539: Make sure fallback directories deliver a recent consensus
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  fallback
Actual Points:|  Parent ID:  #18828
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+
 After #20499, we should reject fallback directories that deliver a
 consensus outdated by more than N hours, where N is one of [1, 2, 3].

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