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

Comment (by teor):

 Replying to [comment:13 nickm]:
 > teor: fwiw, the patch looks good, but IIUC it doesn't resolve the
 problem above?

 The test.exe error is a different bug to do with asprintf, not mman.
 It's likely that some logging code called by the circuit_timeout and geoip
 tests use a format not understood by _vscprintf or _vsnprintf.
 This is probably happening due to #1.
 I've split this off into #20560.

 Otherwise, I am unable to tell if it resolves the mman problem above,
 because the build environment changed between:
 https://trac.torproject.org/projects/tor/attachment/ticket/20530
 /configure-output.txt
 and:
 https://trac.torproject.org/projects/tor/attachment/ticket/20530
 /configureOutput-fix-mingw-pagesize.txt
 likely due to:
 https://trac.torproject.org/projects/tor/ticket/20530?replyto=13#comment:7

 The first build had sys/mman.h available, the second did not.

 However, the patch does prevent a call to getpagesize() when sys/mman.h is
 present, but getpagesize is not. So it's a net win.

 > >would you say it is safe to use the tor I built without the mman
 functionality?
 >
 > ice: it should be just fine.  The windows memory mapping code (which Tor
 uses when HAVE_SYS_MMAN_H is not defined) is probably a much better choice
 for Windows users.

 It is, as long as you are not using Cygwin.

 If you are using Cygwin, you need to use Cygwin's mmap() so that Cygwin
 can handle fork() semantics correctly (and possibly other system calls).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20560 [Core Tor/Tor]: Some unit tests fail when logging messages on Windows / MinGW64

[Tor Bug Tracker & Wiki]

#20560: Some unit tests fail when logging messages on Windows / MinGW64
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  029-proposed
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+--
 A Windows / MinGW64 user sees the following errors in the unit tests:
 {{{
 circuit_timeout: [forking] Nov 03 15:52:03.329 [err] tor_asprintf(): Bug:
 Internal error in asprintf (on Tor 0.2.9.4-alpha-dev 8f465808a06c739d)
 Nov 03 15:52:03.329 [err] tor_assertion_failed_(): Bug: compat.c:515:
 tor_asprintf: Assertion 0 failed; aborting. (on Tor 0.2.9.4-alpha-dev
 8f465808a06c739d)
 Nov 03 15:52:03.329 [err] Bug: Assertion 0 failed in tor_asprintf at
 compat.c:515. (Stack trace not available) (on Tor 0.2.9.4-alpha-dev
 8f465808a06c739d)
 OK
 rend_fns: [forking] OK
 geoip: Nov 03 15:52:11.920 [err] tor_asprintf(): Bug: Internal error in
 asprintf (on Tor 0.2.9.4-alpha-dev 8f465808a06c739d)
 Nov 03 15:52:11.920 [err] tor_assertion_failed_(): Bug: compat.c:515:
 tor_asprintf: Assertion 0 failed; aborting. (on Tor 0.2.9.4-alpha-dev
 8f465808a06c739d)
 Nov 03 15:52:11.920 [err] Bug: Assertion 0 failed in tor_asprintf at
 compat.c:515. (Stack trace not available) (on Tor 0.2.9.4-alpha-dev
 8f465808a06c739d)
 This application has requested the Runtime to terminate it in an unusual
 way.
 Please contact the application's support team for more information.
 make: *** [test] Error 3
 }}}


 https://trac.torproject.org/projects/tor/attachment/ticket/20530/test-
 output-fmp.txt

 Split off from #20530.
 This is probably happening due to #1.

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

Re: [tor-bugs] #20560 [Core Tor/Tor]: Some unit tests fail when logging messages on Windows / MinGW64

[Tor Bug Tracker & Wiki]

#20560: Some unit tests fail when logging messages on Windows / MinGW64
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.???
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-proposed, windows, mingw64,  |  Actual Points:
  test   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  029-proposed => 029-proposed, windows, mingw64, test


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

Re: [tor-bugs] #20559 [Core Tor/Tor]: rend_config_services ignores failures in rend_add_service

[Tor Bug Tracker & Wiki]

#20559: rend_config_services ignores failures in rend_add_service
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:  0.1
Parent ID:  #20484| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:   => tor-hs
 * parent:   => #20484
 * actualpoints:   => 0.1


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

Re: [tor-bugs] #20559 [Core Tor/Tor]: rend_config_services ignores failures in rend_add_service

[Tor Bug Tracker & Wiki]

#20559: rend_config_services ignores failures in rend_add_service
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 and fixes on 03d6a3171  in 0.2.6.3-alpha, 60a0ae198 in 0.2.1.5-alpha.

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

[tor-bugs] #20559 [Core Tor/Tor]: rend_config_services ignores failures in rend_add_service

[Tor Bug Tracker & Wiki]

#20559: rend_config_services ignores failures in rend_add_service
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.1-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 Tor used to warn but continue on some hidden service misconfigurations.
 Instead, the fix I am adding #20484 will consider these misconfigurations
 a config error, and terminate tor.

 I think it's better to stop with an error, than potentially reveal
 sensitive information due to a misconfiguration (or, far more likely, just
 ignore hidden services the user has misconfigured).

 Bugfix on commit 915c743 in #6411 in tor-0.2.7.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] #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:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by chelseakomlo):

 Replying to [comment:3 atagar]:
 > Thanks Chelsea, great catch! Fix pushed.


 I'm glad it was useful :) Thanks for the quick 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] #20477 [Core Tor/Stem]: stem cwd tests fail on macOS Sierra

[Tor Bug Tracker & Wiki]

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

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


Comment:

 Oops, thanks for the catch!
 
[https://gitweb.torproject.org/stem.git/commit/?id=139e598af7529b270eaf279ed4d89d47bfdcba56
 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] #20477 [Core Tor/Stem]: stem cwd tests fail on macOS Sierra

[Tor Bug Tracker & Wiki]

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

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


Comment:

 The change in the test creates a duplicate dictionary key. Found using
 `flake8`.

 {{{
 test/unit/util/system.py:364:7: F999 dictionary key '75717' repeated with
 different values
 test/unit/util/system.py:365:7: F999 dictionary key '75717' repeated with
 different values
 }}}

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

Re: [tor-bugs] #20558 [Core Tor/Tor]: Coverity complains about 64-bit time_t vs 64-bit int64_t comparison

[Tor Bug Tracker & Wiki]

#20558: Coverity complains about 64-bit time_t vs 64-bit int64_t comparison
--+
 Reporter:  nickm |  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):

 * status:  new => needs_review


Comment:

 `bug20558` is my attempt at a fix here.  There is no bug: Coverity Scan
 just doesn't like it when we check whether a 64-bit value is larger than
 it can possibly be.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20558 [Core Tor/Tor]: Coverity complains about 64-bit time_t vs 64-bit int64_t comparison

[Tor Bug Tracker & Wiki]

#20558: Coverity complains about 64-bit time_t vs 64-bit int64_t comparison
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 {{{
 *** CID 1375988:  Integer handling issues  (CONSTANT_EXPRESSION_RESULT)
 /src/or/torcert.c: 160 in tor_cert_parse()
 154   cert = tor_malloc_zero(sizeof(tor_cert_t));
 155   cert->encoded = tor_memdup(encoded, len);
 156   cert->encoded_len = len;
 157
 158   memcpy(cert->signed_key.pubkey, parsed->certified_key, 32);
 159   const int64_t valid_until_64 = ((int64_t)parsed->exp_field) *
 3600;
 >>> CID 1375988:  Integer handling issues
 (CONSTANT_EXPRESSION_RESULT)
 >>> "valid_until_64 > 9223372036854775807L /*
 (time_t)9223372036854775807L */" is always false regardless of the values
 of its operands. This occurs as the logical operand of if.
 160   if (valid_until_64 > TIME_MAX)
 161 cert->valid_until = TIME_MAX - 1;
 162   else
 163 cert->valid_until = (time_t) valid_until_64;
 164   cert->cert_type = parsed->cert_type;
 165
 }}}

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

Re: [tor-bugs] #20400 [Core Tor/Tor]: Unreachable code in rend_service_derive_key_digests()

[Tor Bug Tracker & Wiki]

#20400: Unreachable code in rend_service_derive_key_digests()
--+
 Reporter:  twim  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Very 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:|Sponsor:  SponsorR-can
--+
Changes (by twim):

 * priority:  Medium => Very Low
 * 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

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:  closed
 Priority:  Low   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by nickm):

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


Comment:

 yup!  adding that and merging.  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] #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:
--+

Comment (by twim):

 {{{
   o Refactoring (onion services):
 - Introduce rend_service_is_ephemeral() that tells if given onion
   service is ephemeral. Replace unclear NULL-checkings for service
   directory with this function.
   Closes ticket 20526.
 }}}
 Does this look plausible?

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

Comment (by nickm):

 This needs a changes file; could one of you please add one?

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

Re: [tor-bugs] #19563 [Core Tor/Tor]: Test: add unit test for tor_htonll() and tor_ntohll()

[Tor Bug Tracker & Wiki]

#19563: Test: add unit test for tor_htonll() and tor_ntohll()
--+
 Reporter:  dgoulet   |  Owner:
 Type:  task  | Status:  closed
 Priority:  Low   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:  implemented
 Keywords:  test easy |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by nickm):

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


Comment:

 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] #20551 [Core Tor/Tor]: Implicit conversion warnings with openssl 1.1 on 32-bit platforms

[Tor Bug Tracker & Wiki]

#20551: Implicit conversion warnings with openssl 1.1 on 32-bit platforms
---+---
 Reporter:  nickm  |  Owner:
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.2.8.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  029-backport 028-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * status:  needs_review => closed
 * resolution:   => fixed
 * milestone:  Tor: 0.2.9.x-final => Tor: 0.2.8.x-final


Comment:

 Your recommendation plus the broken jenkins is enough for me.  Merging. :)

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

Re: [tor-bugs] #20423 [Core Tor/Tor]: Clock jumps on FreeBSD relay

[Tor Bug Tracker & Wiki]

#20423: Clock jumps on FreeBSD relay
+
 Reporter:  Felixix |  Owner:
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.8.9
 Severity:  Normal  | Resolution:
 Keywords:  regression freebsd  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by Felixix):

 There is an obvious difference in the log files between 0.2.7.6 and
 0.2.8.9:
 * 0.2.8.9 in the jail, debug after reload with about 23k times
 resolve_my_address etc, 5-6 min Tor down to 4% CPU
 * 0.2.7.6_1 in the *same* jail and keys, debug after reload with 4 times
 resolve_my_address etc, pushing data on 25% CPU

 For now I keep it like it is. If you want me to do anything please tell
 me. I would be glad if I can assist/test.

 
 0.2.8.9 in the jail, debug after reload:

 Nov 03 18:35:02.000 [info] router_write_fingerprint: Dumping fingerprint
 to "/var/db/tor/fingerprint"...
 Nov 03 18:35:02.000 [notice] Your Tor server's identity key fingerprint is
 'blabla fingerprint'
 Nov 03 18:35:02.000 [info] cell_ewma_set_scale_factor: Enabled cell_ewma
 algorithm because of value in CircuitPriorityHalflifeMsec in consensus;
 scale factor is 0.793701 per 10 seconds
 Nov 03 18:35:02.000 [info] options_act: Worker-related options changed.
 Rotating workers.
 Nov 03 18:35:02.000 [debug] configure_nameservers: stat()ing
 /etc/resolv.conf
 Nov 03 18:35:02.000 [info] configure_nameservers: No change to
 '/etc/resolv.conf'

 23484*
 Nov 03 18:35:02.000 [debug] resolve_my_address: Guessed local host name as
 'jail1'
 Nov 03 18:35:02.000 [info] resolve_my_address: Could not resolve guessed
 local hostname 'jail1'. Trying something else.
 Nov 03 18:35:02.000 [info] resolve_my_address: Learned IP address
 '10.x.x.x' for local interface. Using that.
 Nov 03 18:35:02.000 [info] resolve_my_address: Address '' resolves to private IP address '10.x.x.x'. Tor servers that
 use the default DirAuthorities must have public IP addresses.
 Nov 03 18:35:02.000 [info] router_pick_published_address: Could not
 determine our address locally. Checking if directory headers provide any
 hints.
 Nov 03 18:35:02.000 [info] router_pick_published_address: Success: chose
 address 'm.y.i.p'.
 ...

 25432*
 Nov 03 18:40:34.000 [debug] connection_bucket_refill_helper:
 or_conn->read_bucket now 1073741824.

 !!!
 Nov 03 18:40:34.000 [warn] Your system clock just jumped 332 seconds
 forward; assuming established circuits no longer work.

 2498*
 Nov 03 18:40:34.000 [debug] run_connection_housekeeping: Sending keepalive
 to (an.y.i.p:port)

 
 0.2.7.6_1 in the same jail, debug after reload:

 Nov 03 21:25:46.000 [info] int router_write_fingerprint(int): Dumping
 fingerprint to "/var/db/tor/fingerprint"...
 Nov 03 21:25:46.000 [notice] Your Tor server's identity key fingerprint is
 'blabla fingerprint'
 Nov 03 21:25:46.000 [info] void cell_ewma_set_scale_factor(const
 or_options_t *, const networkstatus_t *): Enabled cell_ewma algorithm
 because of value in CircuitPriorityHalflifeMsec in consensus; scale factor
 is 0.793701 per 10 seconds
 Nov 03 21:25:46.000 [info] int options_act(const or_options_t *): Worker-
 related options changed. Rotating workers.
 Nov 03 21:25:46.000 [debug] int configure_nameservers(int): stat()ing
 /etc/resolv.conf
 Nov 03 21:25:46.000 [info] int configure_nameservers(int): No change to
 '/etc/resolv.conf'

 4*
 Nov 03 21:25:46.000 [debug] int resolve_my_address(int, const or_options_t
 *, uint32_t *, const char **, char **): Guessed local host name as 'jail1'
 Nov 03 21:25:46.000 [info] int resolve_my_address(int, const or_options_t
 *, uint32_t *, const char **, char **): Could not resolve guessed local
 hostname 'jail1'. Trying something else.
 Nov 03 21:25:46.000 [info] int resolve_my_address(int, const or_options_t
 *, uint32_t *, const char **, char **): Learned IP address '10.x.x.x' for
 local interface. Using that.
 Nov 03 21:25:46.000 [info] int resolve_my_address(int, const or_options_t
 *, uint32_t *, const char **, char **): Address '' resolves to private IP address '10.x.x.x'. Tor servers that
 use the default DirAuthorities must have public IP addresses.
 Nov 03 21:25:46.000 [info] int router_pick_published_address(const
 or_options_t *, uint32_t *): Could not determine our address locally.
 Checking if directory headers provide any hints.
 Nov 03 21:25:46.000 [info] int router_pick_published_address(const
 or_options_t *, uint32_t *): Success: chose address 'm.y.i.p'.
 ...

 Nov 03 21:25:46.000 [debug] void directory_initiate_command_rend(const
 tor_addr_t *, uint16_t, uint16_t, const char *, uint8_t, uint8_t,
 dir_indirection_t, const char *, const char *, size_t, time_t, 

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

 Actually `context` was freed by C_SetOperationState, it seems. If *slot
 overwritten by free() then crash triggered.

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

Re: [tor-bugs] #19563 [Core Tor/Tor]: Test: add unit test for tor_htonll() and tor_ntohll()

[Tor Bug Tracker & Wiki]

#19563: Test: add unit test for tor_htonll() and tor_ntohll()
--+
 Reporter:  dgoulet   |  Owner:
 Type:  task  | Status:  merge_ready
 Priority:  Low   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  test easy |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 lgtm and works for me! (well only tested on Little Endian :S). 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] #19563 [Core Tor/Tor]: Test: add unit test for tor_htonll() and tor_ntohll()

[Tor Bug Tracker & Wiki]

#19563: Test: add unit test for tor_htonll() and tor_ntohll()
--+
 Reporter:  dgoulet   |  Owner:
 Type:  task  | Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  test easy |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:  dgoulet   |Sponsor:
--+

Comment (by icanhasaccount):

 Heya - thanks, I've put the fix for test_util_format into the same
 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] #19563 [Core Tor/Tor]: Test: add unit test for tor_htonll() and tor_ntohll()

[Tor Bug Tracker & Wiki]

#19563: Test: add unit test for tor_htonll() and tor_ntohll()
--+
 Reporter:  dgoulet   |  Owner:
 Type:  task  | Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  test easy |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:  dgoulet   |Sponsor:
--+

Comment (by dgoulet):

 Oh it's fine that you do the cleanup with this branch! :) I'll look at it
 asap.

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

Re: [tor-bugs] #19563 [Core Tor/Tor]: Test: add unit test for tor_htonll() and tor_ntohll()

[Tor Bug Tracker & Wiki]

#19563: Test: add unit test for tor_htonll() and tor_ntohll()
--+
 Reporter:  dgoulet   |  Owner:
 Type:  task  | Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  test easy |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by icanhasaccount):

 * status:  needs_revision => needs_review


Comment:

 Thank you - I've updated the branch re the feedback. I'll open another bug
 (with a patch) for test_util_format.c.

 Thanks again!

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

Re: [tor-bugs] #20347 [Applications/Tor Browser]: Put "custom" option on security slider?

[Tor Bug Tracker & Wiki]

#20347: Put "custom" option on security slider?
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-security-slider,  |  Actual Points:
  TorBrowserTeam201610   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Kathy and I reviewed the 20347+1 patch and it looks good to us. We also
 did a little testing on OSX.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 use-after-free can be [https://dxr.mozilla.org/mozilla-
 esr45/source/security/nss/lib/pk11wrap/pk11cxt.c#133 RCE]

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

Re: [tor-bugs] #20557 [Applications/Tor Browser]: Upstream the BSD Diversity Project Tor Browser patches.

[Tor Bug Tracker & Wiki]

#20557: Upstream the BSD Diversity Project Tor Browser patches.
--+--
 Reporter:  yawning   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: gk (added)


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

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

[Tor Bug Tracker & Wiki]

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

 * parent:   => #20557


Comment:

 I felt inspired, and think we should examine the other patches as well,
 and merge/upstream things that are sensible.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20557 [Applications/Tor Browser]: Upstream the BSD Diversity Project Tor Browser patches.

[Tor Bug Tracker & Wiki]

#20557: Upstream the BSD Diversity Project Tor Browser patches.
--+--
 Reporter:  yawning   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Inspired by #20497

 They did the work in getting Tor Browser to build/run on OpenBSD, so we
 should review and merge/upstream patches if possible.

 Patches: https://github.com/torbsd/openbsd-ports/tree/master/www/tbb/tor-
 browser/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] #20264 [Applications/Tor Browser]: Reduce number of security slider states from 4 to 3 (proposed)

[Tor Bug Tracker & Wiki]

#20264: Reduce number of security slider states from 4 to 3 (proposed)
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security-slider, |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Kathy and I reviewed the 20264+1 patch and it looks okay to us (of course
 gk should also review it because it would be bad to ship a a buggy
 security slider).

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

Re: [tor-bugs] #20551 [Core Tor/Tor]: Implicit conversion warnings with openssl 1.1 on 32-bit platforms

[Tor Bug Tracker & Wiki]

#20551: Implicit conversion warnings with openssl 1.1 on 32-bit platforms
---+---
 Reporter:  nickm  |  Owner:
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  029-backport 028-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by yawning):

 IMO backport to 028/029, since that's when we started supporting OpenSSL
 1.1.

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

Re: [tor-bugs] #20551 [Core Tor/Tor]: Implicit conversion warnings with openssl 1.1 on 32-bit platforms

[Tor Bug Tracker & Wiki]

#20551: Implicit conversion warnings with openssl 1.1 on 32-bit platforms
---+---
 Reporter:  nickm  |  Owner:
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  029-backport 028-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by nickm):

 This appears to be breaking jenkins builds everyplace 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] #20556 [Applications/Tor bundles/installation]: pt-PT Tor Browser bundles are diguised pt-BR bundles

[Tor Bug Tracker & Wiki]

#20556: pt-PT Tor Browser bundles are diguised pt-BR bundles
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  bundles/installation   |
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  assigned => needs_information


Comment:

 phoul said we use the pt-BR strings for our stuff (Tortbutton) etc. So, I
 am curious what is actually wrong with our bundles. Are the Mozilla
 strings wrong as well? I somehow doubt that as we download the pt-PT
 bundle for Portugese. So, it seems we mix them and want to have pure pt-BR
 bundles instead? Or pure pt-PT ones?

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

Re: [tor-bugs] #20556 [Applications/Tor bundles/installation]: pt-PT Tor Browser bundles are diguised pt-BR bundles

[Tor Bug Tracker & Wiki]

#20556: pt-PT Tor Browser bundles are diguised pt-BR bundles
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  bundles/installation   |
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * owner:  erinn => tbb-team
 * status:  new => assigned


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20556 [Applications/Tor bundles/installation]: pt-PT Tor Browser bundles are diguised pt-BR bundles

[Tor Bug Tracker & Wiki]

#20556: pt-PT Tor Browser bundles are diguised pt-BR bundles
-+-
 Reporter:  gk   |  Owner:  erinn
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  bundles/installation   |   Keywords:  tbb-
 Severity:  Normal   |  usability
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 isabela reported that our pt-PT bundles are actually pt-BR ones and we
 should fix that as this confuses users.

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

Re: [tor-bugs] #20107 [Core Tor/Tor]: somthings wrong about function channel_get_actual_remote_address()

[Tor Bug Tracker & Wiki]

#20107: somthings wrong about function channel_get_actual_remote_address()
-+-
 Reporter:  DLP_ripper   |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.7
 Severity:  Normal   | Resolution:
 Keywords:  channel ip address 028-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 > when we use it in function command_process_created_cell

 I'm fairly confused here.  There isn't actually any call to
 channel_get_actual_remote_address() in command_process_created_cell(), or
 in command.c at all, as far as I can tell.

 Any thoughts here?

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

Re: [tor-bugs] #19563 [Core Tor/Tor]: Test: add unit test for tor_htonll() and tor_ntohll()

[Tor Bug Tracker & Wiki]

#19563: Test: add unit test for tor_htonll() and tor_ntohll()
--+
 Reporter:  dgoulet   |  Owner:
 Type:  task  | Status:  needs_revision
 Priority:  Low   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  test easy |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by dgoulet):

 * status:  new => needs_revision
 * reviewer:   => dgoulet
 * milestone:  Tor: 0.2.??? => Tor: 0.3.0.x-final


Comment:

 Yes actually! That test file should definitely use `tor_htonll()`. Feel
 free to fix that in a separate commit.

 About, your patch, looks good! I would simply test the edge cases that is
 the UINT64 max and 0. Also, I would define the expected "little endian"
 and "big endian" value as const variables instead of just "n" and then
 copy 4 times the expected value of converted n. It will just make things
 clearer and avoid us to typo anything.

 Moving it to 030 milestone. Also, next time, set the patch to
 `needs_review`, will be easier for us to spot that it actually needs
 review :). Big thanks 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] #20107 [Core Tor/Tor]: somthings wrong about function channel_get_actual_remote_address()

[Tor Bug Tracker & Wiki]

#20107: somthings wrong about function channel_get_actual_remote_address()
-+-
 Reporter:  DLP_ripper   |  Owner:
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.7
 Severity:  Normal   | Resolution:
 Keywords:  channel ip address 028-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  new => needs_information


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

Re: [tor-bugs] #20551 [Core Tor/Tor]: Implicit conversion warnings with openssl 1.1 on 32-bit platforms

[Tor Bug Tracker & Wiki]

#20551: Implicit conversion warnings with openssl 1.1 on 32-bit platforms
---+---
 Reporter:  nickm  |  Owner:
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  029-backport 028-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * 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

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

[Tor Bug Tracker & Wiki]

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

Comment (by nickm):

 This LGTM modulo dgoulet's question above.  Once you decide whether to
 change that, please merge_ready. :)

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

Re: [tor-bugs] #20529 [Core Tor/Tor]: Check the directory for each rend service, not just the last one

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => merge_ready


Comment:

 that commit looks good to me.  We can take it with the rest of that branch
 when we merge 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] #19563 [Core Tor/Tor]: Test: add unit test for tor_htonll() and tor_ntohll()

[Tor Bug Tracker & Wiki]

#19563: Test: add unit test for tor_htonll() and tor_ntohll()
--+--
 Reporter:  dgoulet   |  Owner:
 Type:  task  | Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  test easy |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+--

Comment (by icanhasaccount):

 Heya - I added an attempt at this on the following branch:

 https://github.com/mintytoast/tor-stuff/tree/bug_19563

 One thing I noticed - in test_util_format.c there is a macro to define
 htonll:

   #if !defined(HAVE_HTONLL) && !defined(htonll)
   #ifdef WORDS_BIGENDIAN
   #define htonll(x) (x)
   #else
   static uint64_t
   htonll(uint64_t a)
   {
 return htonl((uint32_t)(a>>32)) |
 (((uint64_t)htonl((uint32_t)a))<<32);
   }
   #endif
   #endif

 Should the test case using the above be changed to use tor_htonll? If so I
 can do this in a separate patch.

 Thank you in advance for your time in reading this comment.

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

Re: [tor-bugs] #20529 [Core Tor/Tor]: Check the directory for each rend service, not just the last one

[Tor Bug Tracker & Wiki]

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

Comment (by nickm):

 (It's no longer the last commit; it's
 1747f28861e1f5ce8fc5c8cb3eaad0c7f2297dc9)

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

Comment (by nickm):

 teor: fwiw, the patch looks good, but IIUC it doesn't resolve the problem
 above?


 >would you say it is safe to use the tor I built without the mman
 functionality?

 ice: it should be just fine.  The windows memory mapping code (which Tor
 uses when HAVE_SYS_MMAN_H is not defined) is probably a much better choice
 for Windows users.

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  merge_ready => closed
 * resolution:   => fixed
 * milestone:  Tor: 0.2.9.x-final => Tor: 0.2.8.x-final


Comment:

 Seems okay to me.  Merging to 028 and forward.  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] #20553 [Core Tor/Tor]: Memory leak in crypto_write_public_key_to_string() with OpenSSL master

[Tor Bug Tracker & Wiki]

#20553: Memory leak in crypto_write_public_key_to_string() with OpenSSL master
---+---
 Reporter:  nickm  |  Owner:
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.2.8.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  029-backport 028-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * milestone:  Tor: 0.2.9.x-final => Tor: 0.2.8.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] #20553 [Core Tor/Tor]: Memory leak in crypto_write_public_key_to_string() with OpenSSL master

[Tor Bug Tracker & Wiki]

#20553: Memory leak in crypto_write_public_key_to_string() with OpenSSL master
---+---
 Reporter:  nickm  |  Owner:
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  029-backport 028-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

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


Comment:

 okay. Merged to 0.2.8 and forward

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => needs_revision


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

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

[Tor Bug Tracker & Wiki]

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

Comment (by nickm):

 I've had another pass through.  This looks very close to done.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by mcs):

 Replying to [comment:39 arthuredelstein]:
 > I have added two prefs: privacy.window.maxInnerWidth and
 privacy.window.maxInnerHeight. Hopefully these will be enough to solve any
 such problems.

 Kathy and I were actually more concerned about removal of
 `extensions.torbutton.window.innerWidth` / `innerHeight`. Without those
 prefs, there should be no way to get a window that is wider than 1000
 pixels at startup, for example. I guess someone needs to make the call on
 whether it is okay to remove this functionality.

 > Here's the new version:
 >
 > https://github.com/arthuredelstein/tor-browser/commit/19459+14
 > https://github.com/arthuredelstein/torbutton/commit/19459+1

 The changes looked okay to Kathy and me, but when we tested on a Retina
 Mac with Sierra (OSX 10.12.1), we saw incorrect results (content window
 size was 1300 x 700 at startup). Here is the output from the
 `nsXULWindow::ResizeToRoundedDimensions()` printf logging:
 {{{
 scaling factor: 2.00
 window size: 2000 x 1558
 avail screen size: 2880 x 1746
 primary content shell: 200 x 200
 target content size: 800, 200

 window size: 2600 x 1558
 avail screen size: 1440 x 873
 primary content shell: 200 x 200
 }}}
 (notice the `primary content shell` output). If we comment out the call to
 quantizeBrowserSize() inside torbutton.js, the output looks correct (and
 the content window size is 1000 x 700):
 {{{
 scaling factor: 2.00
 window size: 2400 x 1604
 avail screen size: 2880 x 1746
 primary content shell: 2400 x 1400
 target content size: 2000, 1400

 window size: 2000 x 1604
 avail screen size: 1440 x 873
 primary content shell: 2000 x 1400
 }}}

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

Re: [tor-bugs] #20459 [Core Tor/Tor]: ewma_cmp_cmux never considers policies different

[Tor Bug Tracker & Wiki]

#20459: ewma_cmp_cmux never considers policies different
---+---
 Reporter:  pastly |  Owner:
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.2.6.2-alpha
 Severity:  Normal | Resolution:  fixed
 Keywords:  029-backport, review-group-11  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by pastly):

 Ready for some graphs? This data was collected from two shadow
 simulations. Each has 500 relays and 7500 clients. The one line summary of
 the results (to me) is: the ewma fix does no harm by the metrics I
 gathered.

 qtime.shadow.results.pdf shows the amount of time a cell spends in the
 kernel outbound buffer after leaving Tor and becoming bytes. As you can
 see, no change.

 shadow.results.pdf shows a lot.

 - Time to download `x` bytes are for each different type of client.
 Clients with a smaller `x` behave a lot like web browsers. Clients with
 larger `x` are near continuous bulk downloads. Looks like no change.
 - A bunch of probably self-explanatory graphs all showing no change.
 - 60 second moving average read (pg 22) and write (pg 25). We give the
 network 30 simulation minutes for every relay/client to boot up and reach
 steady state, then measure for 10 simulation minutes. 'After' seems more
 stable than 'before', which would explain the better read and write
 performance for 'after'.

 So, IMO, the fix causes no harm and is beneficial. I can answer any
 questions about what graphs mean, what the simulations consist of, etc.

 I will attach the files right after hitting submit on this. Because I
 can't do it all at once ... ?

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

 * status:  new => needs_information


Comment:

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

 teor, should we keep this in 029 then? Or the ticket at all?

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

Re: [tor-bugs] #17975 [Core Tor/Tor]: Introduce OutboundExitAddress to enable exit-only traffic to go via a different IP address

[Tor Bug Tracker & Wiki]

#17975: Introduce OutboundExitAddress to enable exit-only traffic to go via a
different IP address
-+-
 Reporter:  naif |  Owner:
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  lorax, yawning, isaremoved, review-  |  Actual Points:
  group-11   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Notes:
   * Changes file should mention the ticket number.
   * Commit message should mention the author.

   * parse_outbound_addresses has gotten really complicated, and full of
 duplicate code.  Maybe it's possible to refactor it to be cleaner?  This
 "adr_found[i]" stuff is fairly inelegant.
   * Would it make more sense to have the syntax be "OutboundBindAddress
 Exit 1.2.3.4" ?
   * conn_get_outbound_address falls back to the Exit address when the OR
 address is null.  That doesn't make sense to me.  Why did the user say
 OutboundBindAddressExit if they meant OutboundBindAddress?
   * Other outbound connection types are possible.  For example, directory
 connections, DNS lookups, and local connections to hidden services.
 Should those get handled too?  Should they get treated as if they were
 exit?

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => needs_revision


Comment:

 Question: Why don't we try to create the directory in
 `rend_config_services()` (for each service that your patch does) instead
 of in `rend_service_load_all_keys()` which is called much later in
 config.c. Basically, I think if we do ask for creation when configuring
 the services, we then have no need for it in the load keys function. I did
 the test and works well.

 The rest lgtm so whatever you decide, feel free to `merge_ready` 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] #20241 [Core Tor/Tor]: Fix compilation on osx sierra (10.12)

[Tor Bug Tracker & Wiki]

#20241: Fix compilation on osx sierra (10.12)
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.8.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  osx, TorCoreTeam201609, review-  |  Actual Points:  .1
  group-11, 028-backport |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  osx, TorCoreTeam201609, review-group-11 => osx,
 TorCoreTeam201609, review-group-11, 028-backport


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

Re: [tor-bugs] #20376 [Core Tor/Tor]: Do not mark circs for close again after relay_send_command_from_edge()

[Tor Bug Tracker & Wiki]

#20376: Do not mark circs for close again after relay_send_command_from_edge()
-+
 Reporter:  twim |  Owner:  twim
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:  implemented
 Keywords:  review-group-11  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 looks okay; 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] #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:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 okay, squashed and merged .  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] #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:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Ah! Thanks for the clarification. :)

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

Re: [tor-bugs] #20553 [Core Tor/Tor]: Memory leak in crypto_write_public_key_to_string() with OpenSSL master

[Tor Bug Tracker & Wiki]

#20553: Memory leak in crypto_write_public_key_to_string() with OpenSSL master
---+---
 Reporter:  nickm  |  Owner:
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  029-backport 028-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 lgtm; Seems worth it for backport as memleaks can be a source of DoS, that
 falls well under our policy of backporting security bugs for stable 028.

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

Comment (by cypherpunks):

 Regarding the question in the commit message for this ticket see
 [http://vimdoc.sourceforge.net/htmldoc/recover.html#swap-file], especially
 the part that says

 {{{
 The name of the swap file is normally the same as the file you are
 editing,
 with the extension ".swp".
 ...
 - If this file already exists (e.g., when you are recovering from a crash)
 a
   warning is given and another extension is used, ".swo", ".swn", etc.
 }}}

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  closed => reopened
 * version:  Tor: unspecified =>
 * resolution:  fixed =>
 * parent:  #20082 =>
 * milestone:  Tor: 0.3.0.x-final => Tor: 0.2.???


Comment:

 #20082 won't add an option after all. So we should still keep this open as
 maybe one day we will want the option to delay descriptor upload. I'm also
 un-parenting the ticket so it can be free! :)

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => needs_revision


Comment:

 Commented on the gitlab merge. I made some suggestion on simplifying this
 even more. I might have said stupid things so feel free to express any
 disagreement :). Thanks twim!

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

Re: [tor-bugs] #20376 [Core Tor/Tor]: Do not mark circs for close again after relay_send_command_from_edge()

[Tor Bug Tracker & Wiki]

#20376: Do not mark circs for close again after relay_send_command_from_edge()
-+
 Reporter:  twim |  Owner:  twim
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  review-group-11  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 Ok I'll put this one in `merge_ready` as two of us already looked at it.
 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] #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:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Thanks Chelsea, great catch! Fix pushed.

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

Re: [tor-bugs] #17306 [Core Tor/Stem]: Split up controller.py's integ tests

[Tor Bug Tracker & Wiki]

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

Comment (by atagar):

 Thanks Neel! This ticket is pretty old and since then I've had time to
 think about a good alternate way to structure our tests. Rather than
 breaking up test functions think we should aim for the test modules so
 they relate to a single class or topic. That is to say instead of...

 {{{
 class TestController(unittest.TestCase):
   ... tests everything...
 }}}

 ... we have...

 {{{
 class TestControllerCommands(unittest.TestCase):
   ... tests GETINFO, GETCONF, etc...

 class TestHiddenServices(unittest.TestCase):
   ... tests hidden service functions...
 }}}

 There could be merit to breaking up the functions as you did here too.

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

Re: [tor-bugs] #20555 [Core Tor/Tor]: Stream isolation for DNS (was: stream isolation for DNS and hidden service descriptor cache)

[Tor Bug Tracker & Wiki]

#20555: Stream isolation for DNS
--+--
 Reporter:  adrelanos |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  dns   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * keywords:   => dns
 * milestone:   => Tor: 0.2.???


Comment:

 For HS cache isolation, we have #15938 so renaming this ticket to only
 mention DNS stream isolation which I couldn't find a ticket about it but
 kind of vaguely remembering one so if anyone finds it, duplicate this one.
 Multiple tickets exists about "stream isolation" like #15458 an #19859.
 Maybe we should make a parent ticket with all the childs if anyone is up
 for that? :) Thanks adrelanos 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] #20463 [User Experience/Translations]: Translate the download page

[Tor Bug Tracker & Wiki]

#20463: Translate the download page
--+-
 Reporter:  arthuredelstein   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  User Experience/Translations  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arthuredelstein):

 Replying to [comment:2 phoul]:
 > For localization, is download-easy.html preferred over
 torbrowser.html.en?

 I was thinking perhaps a hybrid of the two would be nice. I like the
 simplicity of download-easy, but I think maybe a short explanation of
 "What is Tor Browser?" should be added there.

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

Comment (by ice):

 Replying to [comment:11 cypherpunks]:
 > Replying to [comment:9 ice]:
 > > The branch and master are missing the configure script. If I am
 expected to generate it, please advise as to how as I am not that familiar
 with the automake build system.
 > You can run the `autogen.sh` script situated in the root directory.

 Yes I've already done that and the output of the resulting configure
 script is attached above.

 I have built it now but unfortunately the test.exe crashes (twice). Apart
 from enclosing the few lines that the test printed out (attached file
 test-output-fmp.txt), I am not sure how else to help.

 Before I forget: would you say it is safe to use the tor I built without
 the mman 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] #19043 [Core Tor/Tor]: prop224: Implementation of ESTABLISH_INTRO cell

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => merge_ready


Comment:

 OK! I have a branch that is mature enough for Nick to take a look.
 It can be found in my repo at `ticket19043_030_02`.

 It basically allows Tor to parse and handle ESTABLISH_INTRO cells and also
 map them with circuits (using the new HS circuitmap subsystem). It's also
 able to generate ESTABLISH_INTRO cells, but this is just done to generate
 unit test data.

 It's squashed and rebased on git master. When the prop224 HSDir branch
 (#17238) gets merged, this branch will require some minimal edit so that
 we move some stuff to the `hs_common.c` file introduced by #17238 (there
 is an XXX about that). I will do that and rebase it when the time comes.

 I also tested it on chutney today and the current HS functionality seems
 to work just fine. More manual testing is always good.

 WRT unit testing, here is the coverage:
 {{{
 File 'src/or/hs_circuitmap.c'
 Lines executed:99.05% of 105

 File 'src/or/hs_intropoint.c'
 Lines executed:84.52% of 84

 File 'src/or/hs_service.c'
 Lines executed:80.39% of 51
 }}}
 Please note that `hs_service.c` is unused by real code yet (it's just
 there basically to generate unittest vectors).

 Please let me know if you need me to do anything else here.

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

[tor-bugs] #20555 [Core Tor/Tor]: stream isolation for DNS and hidden service descriptor cache

[Tor Bug Tracker & Wiki]

#20555: stream isolation for DNS and hidden service descriptor cache
--+-
 Reporter:  adrelanos |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Seems like Tor's DNS cache ({{{CacheIPv4DNS}}}, {{{CacheIPv6DNS}}}) and
 caching of hidden service descriptors is cached globally.

 The first connection in stream one resolves all DNS or hidden service
 descriptors. But follow up connections in separate streams to the same
 website do not resolve and use Tor's cache.

 So webservers could provide a slightly unique version of their website per
 visitor. Each visitors browser could be instructed to load additional
 content from varying hostnames. Due to caching vs non-caching it might be
 possible to make visitors pseudonymous rather than anonymous.

 The problem is that Tor's cache is global and not stream isolated.

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

 * 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

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.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy refactor  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

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


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

Re: [tor-bugs] #20463 [User Experience/Translations]: Translate the download page

[Tor Bug Tracker & Wiki]

#20463: Translate the download page
--+-
 Reporter:  arthuredelstein   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  User Experience/Translations  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by phoul):

 For localization, is download-easy.html preferred over torbrowser.html.en?

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

Re: [tor-bugs] #6897 [Archived/Vidalia]: Tor Browser Bundle - Vidalia Does No Retain GTK Themes When Restarting

[Tor Bug Tracker & Wiki]

#6897: Tor Browser Bundle - Vidalia Does No Retain GTK Themes When Restarting
---+---
 Reporter:  DasFox |  Owner:  chiiph
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  TorBrowserBundle 2.2.x-stable
Component: |Version:
  Archived/Vidalia |
 Severity:  Normal | Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by cypherpunks):

 * status:  new => closed
 * keywords:  Vidalia =>
 * resolution:   => wontfix
 * severity:   => Normal


Comment:

 Vidalia has been discontinued.

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

 I cherry-picked the strings (commit
 269031f7aba449312189f73753e616fb82e5af48).

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

Re: [tor-bugs] #20554 [Core Tor/Tor]: Refactor circuit_expire_building

[Tor Bug Tracker & Wiki]

#20554: Refactor circuit_expire_building
--+
 Reporter:  chelseakomlo  |  Owner:
 Type:  enhancement   | Status:  new
 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:|Sponsor:
--+
Changes (by dgoulet):

 * component:  - Select a component => Core Tor/Tor
 * 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] #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:
-+-

Comment (by cypherpunks):

 Replying to [comment:9 ice]:
 > The branch and master are missing the configure script. If I am expected
 to generate it, please advise as to how as I am not that familiar with the
 automake build system.
 You can run the `autogen.sh` script situated in the root directory.

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

[tor-bugs] #20554 [- Select a component]: Refactor circuit_expire_building

[Tor Bug Tracker & Wiki]

#20554: Refactor circuit_expire_building
--+-
 Reporter:  chelseakomlo  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:  refactoring
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 circuit_expire_building() is large and hard to follow- it can be
 constructed from smaller functions. Unit tests can also be added for
 extracted functions.

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

Comment (by ice):

 Okay. Enclosing configure output for branch fix-mingw-pagesize. Will try
 to build it and report back shortly.

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

Re: [tor-bugs] #20553 [Core Tor/Tor]: Memory leak in crypto_write_public_key_to_string() with OpenSSL master

[Tor Bug Tracker & Wiki]

#20553: Memory leak in crypto_write_public_key_to_string() with OpenSSL master
---+---
 Reporter:  nickm  |  Owner:
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  029-backport 028-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

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


Comment:

 Fix in branch `bug20553_028`.  I'm merging this to master, and putting for
 consideration for backport.

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

Re: [tor-bugs] #20553 [Core Tor/Tor]: Memory leak in crypto_write_public_key_to_string() with OpenSSL master

[Tor Bug Tracker & Wiki]

#20553: Memory leak in crypto_write_public_key_to_string() with OpenSSL master
---+---
 Reporter:  nickm  |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  029-backport 028-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by nickm):

 To reproduce, build with --enable-expensive-hardening and an appropriate
 version of OpenSSL.  Then run ./src/test/test crypto/pk .  You'll see:
 {{{
 =
 ==29032==ERROR: LeakSanitizer: detected memory leaks

 Direct leak of 16 byte(s) in 1 object(s) allocated from:
 #0 0x7f2f849e1e60 in malloc (/lib64/libasan.so.3+0xc6e60)
 #1 0x7f2f83c197ed in CRYPTO_zalloc
 (/home/nickm/opt/openssl//lib/libcrypto.so.1.1+0x15f7ed)

 Indirect leak of 32 byte(s) in 1 object(s) allocated from:
 #0 0x7f2f849e1e60 in malloc (/lib64/libasan.so.3+0xc6e60)
 #1 0x7f2f83c197ed in CRYPTO_zalloc
 (/home/nickm/opt/openssl//lib/libcrypto.so.1.1+0x15f7ed)

 SUMMARY: AddressSanitizer: 48 byte(s) leaked in 2 allocation(s).
 OK
 }}}

 Looking at the OpenSSL source in bss_mem.c, this appears to have been
 introduced in their 9fe9d0461ea4bcc, which is in 1.1.

 I'd call this an openssl bug, except our code here is just plain bizarre.

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

 Replying to [comment:10 gk]:
 > dcf: Could you prepare a new tag for meek with the commit up for review
 here (in case you think the changes are okay)? I am fine putting that into
 6.0.6 as well. For this we need a new tag by next Tuesday, thanks. FWIW
 the changes look good to me, too, although I have a hard time parsing the
 second sentence of the commit message. Seems to be missing something
 there. But might be fixable just with a `git commit --amend`.

 Oops. The commit message should read "This fixes a problem '''where'''
 meek-client-torbrowser"

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20553 [Core Tor/Tor]: Memory leak in crypto_write_public_key_to_string() with OpenSSL master

[Tor Bug Tracker & Wiki]

#20553: Memory leak in crypto_write_public_key_to_string() with OpenSSL master
--+---
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  029-backport 028-backport
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 The expensive-hardening version of the tests had a memory leak when we
 were encoding public keys.  The fix is easy -- I don't know why we
 programmed it the way we did in the first place.

 Found on https://jenkins.torproject.org/job/tor-ci-linux-master-expensive-
 hardening/ARCHITECTURE=amd64,SUITE=sid/425/consoleFull -- so is that
 openssl 1.1 too?

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

Re: [tor-bugs] #20552 [Core Tor/Tor]: Advertise support for ed25519 link handshake using subprotocol versions

[Tor Bug Tracker & Wiki]

#20552: Advertise support for ed25519 link handshake using subprotocol versions
---+
 Reporter:  nickm  |  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201611  |  Actual Points:  0
Parent ID:  #15054 | Points:  .5
 Reviewer: |Sponsor:  SponsorU-must
---+
Changes (by nickm):

 * status:  new => needs_review
 * keywords:   => TorCoreTeam201611
 * actualpoints:   => 0


Comment:

 My branch `feature20552` has the code here.  Much easier than I thought.
 Need to think about how this works for bridges, though.

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

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

 [https://dxr.mozilla.org/mozilla-
 esr45/source/security/nss/lib/pk11wrap/pk11cxt.c#48 This] is about wrong
 slot:
 {{{
 if ((cx->ownSession) && (cx->slot->isThreadSafe)) {
 }}}
 Probably points to freed memory, else NULL would trigger for all another
 platforms too. If correct then should be reproducible for hardened Tor
 Browser too.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20552 [Core Tor/Tor]: Advertise support for ed25519 link handshake using subprotocol versions

[Tor Bug Tracker & Wiki]

#20552: Advertise support for ed25519 link handshake using subprotocol versions
--+
 Reporter:  nickm |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #15054
   Points:|   Reviewer:
  Sponsor:|
--+
 Now that #15055 is merged, #15056 will want to know which relays support
 its link protocol extensions.  But to do that, we'll need to expose the
 fact in descriptors.  The canonical way to do that is now with subprotocol
 versions (see prop#264).

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

Re: [tor-bugs] #20552 [Core Tor/Tor]: Advertise support for ed25519 link handshake using subprotocol versions

[Tor Bug Tracker & Wiki]

#20552: Advertise support for ed25519 link handshake using subprotocol versions
--+
 Reporter:  nickm |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #15054| Points:  .5
 Reviewer:|Sponsor:  SponsorU-must
--+
Changes (by nickm):

 * points:   => .5
 * sponsor:   => SponsorU-must


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

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

 Applied the tor-launcher changes to master, maint-0.2.10 and maint-0.2.9
 (commit 5ac452d86f93ee15ba3722afc606be862e8f3686,
 4eee281bf774f8cf4f2d8a2549573b7a89f72407 and
 0082643cd0b88f34cb56501b6631307616b8cc1d).

 dcf: Could you prepare a new tag for meek with the commit up for review
 here (in case you think the changes are okay)? I am fine putting that into
 6.0.6 as well. For this we need a new tag by next Tuesday, thanks. FWIW
 the changes look good to me, too, although I have a hard time parsing the
 second sentence of the commit message. Seems to be missing something
 there. But might be fixable just with a `git commit --amend`.

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

Re: [tor-bugs] #20551 [Core Tor/Tor]: Implicit conversion warnings with openssl 1.1 on 32-bit platforms (was: Implicit conversion warnings with openssl 1.1)

[Tor Bug Tracker & Wiki]

#20551: Implicit conversion warnings with openssl 1.1 on 32-bit platforms
---+---
 Reporter:  nickm  |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  029-backport 028-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

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


Old description:



New description:

 {{{
 13:25:05 src/common/tortls.c:1650:30: error: implicit conversion loses
 integer precision: 'uint64_t' (aka 'unsigned long long') to 'unsigned
 long' [-Werror,-Wshorten-64-to-32]
 13:25:05   result->last_write_count = BIO_number_written(bio);
 13:25:05~ ^~~
 13:25:05 src/common/tortls.c:1651:29: error: implicit conversion loses
 integer precision: 'uint64_t' (aka 'unsigned long long') to 'unsigned
 long' [-Werror,-Wshorten-64-to-32]
 13:25:05   result->last_read_count = BIO_number_read(bio);
 13:25:05   ~ ^~~~
 13:25:05 src/common/tortls.c:2266:7: error: implicit conversion loses
 integer precision: 'uint64_t' (aka 'unsigned long long') to 'unsigned
 long' [-Werror,-Wshorten-64-to-32]
 13:25:05   r = BIO_number_read(SSL_get_rbio(tls->ssl));
 13:25:05 ~ ^~~
 13:25:05 src/common/tortls.c:2287:7: error: implicit conversion loses
 integer precision: 'uint64_t' (aka 'unsigned long long') to 'unsigned
 long' [-Werror,-Wshorten-64-to-32]
 13:25:05   w = BIO_number_written(wbio);
 13:25:05 ~ ^~~~
 13:25:05 4 errors generated.
 }}}

--

Comment:

 Branch `bug20551_028` has the fix here.  I'm applying it to master.  How
 far back to backport?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20551 [Core Tor/Tor]: Implicit conversion warnings with openssl 1.1

[Tor Bug Tracker & Wiki]

#20551: Implicit conversion warnings with openssl 1.1
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+


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

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

Comment (by nickm):

 I've added comments there, and squashed the branch into a feature15055_v2,
 and merged it.  Tests pass!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  closed
 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, |  implemented
  027-triaged-1-in, 028-triaged, |  Actual Points:
  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 nickm):

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


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

Comment (by ice):

 The branch and master are missing the configure script. If I am expected
 to generate it, please advise as to how as I am not that familiar with the
 automake build system.

 Also, kindly inform me if the tor I built without the mmap functionality
 is safe to use. I attempted to build tor only because the latest tor I
 have was complaining that I have an outdated version; and until I started
 my attempt, the torproject did not post an updated build in the form of
 the Expert package (the one included in the torbrowser is the "outdated"
 one I use). So can I use the one I built safely?

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

Re: [tor-bugs] #20550 [Metrics/CollecTor]: implement SanitizedBridgeExtraInfoDescriptor

[Tor Bug Tracker & Wiki]

#20550: implement SanitizedBridgeExtraInfoDescriptor
---+-
 Reporter:  iwakeh |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #20542 | Points:
 Reviewer: |Sponsor:
---+-
Description changed by iwakeh:

Old description:

> Create the two classes `SanitizedBridgeExtraInfoDescriptor` and
> `SanitizedBridgeExtraInfoDescriptorTest`.
> `SanitizedBridgeExtraInfoDescriptor` should extend
> `BridgeExtraInfoDescriptor` all else analogously to #20249.

New description:

 Create the two classes `SanitizedBridgeExtraInfoDescriptor` and
 `SanitizedBridgeExtraInfoDescriptorTest`.
 `SanitizedBridgeExtraInfoDescriptor` should extend
 `BridgeExtraInfoDescriptor` all else analogously to #20549.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20550 [Metrics/CollecTor]: implement SanitizedBridgeExtraInfoDescriptor

[Tor Bug Tracker & Wiki]

#20550: implement SanitizedBridgeExtraInfoDescriptor
---+
 Reporter:  iwakeh |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #20542
   Points: |   Reviewer:
  Sponsor: |
---+
 Create the two classes `SanitizedBridgeExtraInfoDescriptor` and
 `SanitizedBridgeExtraInfoDescriptorTest`.
 `SanitizedBridgeExtraInfoDescriptor` should extend
 `BridgeExtraInfoDescriptor` all else analogously to #20249.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20549 [Metrics/CollecTor]: implement SanitizedBridgeServerDescriptor

[Tor Bug Tracker & Wiki]

#20549: implement SanitizedBridgeServerDescriptor
---+
 Reporter:  iwakeh |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #20542
   Points: |   Reviewer:
  Sponsor: |
---+
 `SanitizedBridgeServerDescriptor` should extend `BridgeServerDescriptor`.
 It receives a `BridgeServerDescriptor` at construction time and sanitizes
 the descriptor.
 All getters should only supply sanitized data; this explicitely includes
 method from the Descriptor interface like getRawDescriptorBytes.

 In addition, a `SanitizedBridgeServerDescriptorTest` should be created
 that verifies the sanitation and data integrity.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20548 [Metrics]: Handle bad input more consistently in metrics code bases

[Tor Bug Tracker & Wiki]

#20548: Handle bad input more consistently in metrics code bases
-+-
 Reporter:  karsten  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We started thinking about handling bad input while sanitizing bridge
 descriptors in CollecTor (#19834) and while reading relay descriptors in
 Onionoo (#20412).  But before we implement any changes we should
 generalize our strategies for handling bad input to avoid solving the same
 problem over and over.  The result of this discussion can also serve as
 guide for future code.

 What we're not covering here (but what we should think about anyway) is
 how we're handling issues during processing that are not directly related
 to bad input, like problems with sanitizing bridge IP addresses.

 So, we can distinguish a couple of use cases where we're handling
 descriptors as input:
  1. CollecTor downloads descriptors from the directory or TorDNSEL or
 Torperf or processes previously downloaded descriptors.
  2. CollecTor synchronizes descriptors from other CollecTor instances.
  3. CollecTor reads previously uploaded bridge descriptors and produces
 sanitized versions of them.
  4. Metrics, Onionoo, ExoneraTor, and other applications download
 descriptors from CollecTor and use them locally.

 The requirements on input data are quite different for these four use
 cases.  Let's go through them:
  1. As of a few weeks ago we're storing and serving descriptors even if
 metrics-lib cannot parse them.  The idea is that CollecTor shouldn't
 decide what goes into the archive, but the directory authorities (or
 TorDNSEL and Torperf) should.  As long as we can detect the descriptor
 type, extract the publication date, and possibly calculate the digest, we
 can accept a descriptor.
  2. The requirements are pretty much the same as for 1.
  3. We need to be very picky about bridge descriptors, in particular about
 unknown parts, because those might contain sensitive information that we'd
 rather not copy over to sanitized bridge descriptors.
  4. Most applications would want to skip bad descriptors and not bother
 much about it.  As of a few days ago, they all use metrics-lib for parsing
 descriptors.

 So much about the differences.  Let's also list the commonalities or
 possible goals for common behavior:
  - Regardless of the chosen strategy, we should apply it to all variants
 of descriptor badness.  This may sound obvious, but we're currently not
 doing this.  For example, if we encounter an invalid "a" line in a bridge
 descriptor, we skip that line, whereas an invalid "r" line makes us skip
 the entire descriptor.  This is part of what we're trying to streamline in
 #19834, even though this case is not explicitly listed there.
  - Whenever we encounter an error in processing a descriptor, we should
 attempt to recover and continue with subsequent good descriptors.  The
 reason is that descriptors in a common source can come from different
 original sources, and we cannot blame valid descriptors for following a
 faulty descriptor.  This is the cause for #20412.

 This is just the start.  Let's add more thoughts to this ticket and
 assemble a guide that we can apply to existing tickets and future code
 changes.

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

Re: [tor-bugs] #20542 [Metrics/CollecTor]: structure bridgedescs and modernize

[Tor Bug Tracker & Wiki]

#20542: structure bridgedescs and modernize
---+--
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #20518 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by iwakeh):

 * status:  new => assigned
 * owner:   => iwakeh


Comment:

 Outline:

 The bridgedescs module
 1. reads descriptors supplied locally from a bridge auth (currently
 bifroest, formerly tonga, in future possibly more)
 1. verifies the auth-fingerprint
 1. parses and
 1. sanitizes the descriptors and
 1. adds them to the local storage
 1. keeping some statistics about the import.

 A `BridgeMain` class should be added to facilitate this process.
 The input tarballs need to be verified that they origin from a known and
 trusted authority.
 The (compressed) tarballs should be parsed using metrics-lib
 DescriptorReader.
 Each resulting Descriptor is sanitized by encapsulating it with
 `SanitizedBridge*Descriptor` extending `Bridge*Descriptor` (analogously to
 the `*Persistence` classes in o.t.c.persist package).
 These `SanitizedBridge*Descriptor`s can be written to the two storage
 location by using the appropriate `*Persistence` classes.

 `BridgeSnapshotReader` can be reduced to simply find all input tars in the
 given directory and after verifying the supplying authority provide a list
 of valid tar (possibly compressed) files.  It doesn't need to unpack or
 parse these files.

 Parsing is accomplished using metrics-lib `DescriptorReader`; the
 resulting Descriptors are sanitized and stored as described above.

 Thus, the two new classes `SanitizedBridgeServerDescriptor` and
 `SanitizedBridgeExtraInfoDescriptor` have to be implemented (cf.
 respective child tickets).  After that the processing logic can be
 assembled in `BridgeMain`.
 The 'stale descriptors check' (currently in SanitizedBridgesWriter) can be
 performed while processing the descriptors.


 What did I overlook?  What needs to be 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] #20547 [Core Tor/Chutney]: Fix typo in Chutney's bootstrap-network.sh

[Tor Bug Tracker & Wiki]

#20547: Fix typo in Chutney's bootstrap-network.sh
--+-
 Reporter:  larsl |  Owner:  teor
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:  chutney
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 There's a one-character typo in bootstrap-network.sh. The attached patch
 fixes 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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #20514, #20516, #20515

[Tor Bug Tracker & Wiki]

Batch modification to #20514, #20516, #20515 by iwakeh:
milestone to CollecTor 1.2.0

--
Tickets URL: 

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

Re: [tor-bugs] #19828 [Metrics/CollecTor]: Extend descriptorCutOff in CollecTor's RelayDescriptorDownloader by 6 hours

[Tor Bug Tracker & Wiki]

#19828: Extend descriptorCutOff in CollecTor's RelayDescriptorDownloader by 6 
hours
---+-
 Reporter:  karsten|  Owner:  iwakeh
 Type:  defect | Status:  assigned
 Priority:  Low|  Milestone:  CollecTor 1.2.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #8799  | Points:
 Reviewer: |Sponsor:
---+-
Changes (by iwakeh):

 * parent:   => #8799


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