Re: [tor-bugs] #27299 [Core Tor/Tor]: hsv3: Clarify timing sources around hsv3 code

[Tor Bug Tracker & Wiki]

#27299: hsv3: Clarify timing sources around hsv3 code
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs hsv3 refactoring easy |  Actual Points:
  technical-debt |
Parent ID:  #23764   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Replying to [comment:5 ffmancera]:
 > Replying to [comment:3 asn]:
 > > > I saw that we are using `approx_time()` which is an alias of
 `time(NULL)`, but at the same time and in the same file, we are using
 both. As `approx_time.h` has different utilities for timing, we should use
 it instead of `time(NULL)`. What do you think?
 > > >
 > >
 > > Yes, I think we should be using `approx_time()` instead of
 `time(NULL)` everywhere. I don't see a reason not to.
 > >
 > > One of the problems with HS timing is that lots of the time sources
 come from the main event loop where `time(NULL)` is used.
 >
 > Then we should refactor all time resources, using only approx_time()
 over all the code right? I have a patch for this specific task. I will do
 a pull request if you are fine with that :-)

 You mean ALL over the codebase? Not sure how to evaluate the correctness
 of such a refactoring. Do you think there is a clear way to show that it
 does not break anything or change any behavior?

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

Re: [tor-bugs] #27299 [Core Tor/Tor]: hsv3: Clarify timing sources around hsv3 code

[Tor Bug Tracker & Wiki]

#27299: hsv3: Clarify timing sources around hsv3 code
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs hsv3 refactoring easy |  Actual Points:
  technical-debt |
Parent ID:  #23764   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ffmancera):

 Replying to [comment:3 asn]:
 > > I saw that we are using `approx_time()` which is an alias of
 `time(NULL)`, but at the same time and in the same file, we are using
 both. As `approx_time.h` has different utilities for timing, we should use
 it instead of `time(NULL)`. What do you think?
 > >
 >
 > Yes, I think we should be using `approx_time()` instead of `time(NULL)`
 everywhere. I don't see a reason not to.
 >
 > One of the problems with HS timing is that lots of the time sources come
 from the main event loop where `time(NULL)` is used.

 Then we should refactor all time resources, using only approx_time() over
 all the code right? I have a patch for this specific task. I will do a
 pull request if you are fine with that?

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

Re: [tor-bugs] #27299 [Core Tor/Tor]: hsv3: Clarify timing sources around hsv3 code

[Tor Bug Tracker & Wiki]

#27299: hsv3: Clarify timing sources around hsv3 code
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs hsv3 refactoring easy |  Actual Points:
  technical-debt |
Parent ID:  #23764   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  tor-hs hsv3 refactoring easy => tor-hs hsv3 refactoring easy
 technical-debt
 * sponsor:  Sponsor8-can =>
 * parent:  #23605 => #23764


Comment:

 We won't do this as part of sponsor 8, but we'll need this for #23764.

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

Re: [tor-bugs] #27299 [Core Tor/Tor]: hsv3: Clarify timing sources around hsv3 code

[Tor Bug Tracker & Wiki]

#27299: hsv3: Clarify timing sources around hsv3 code
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs hsv3 refactoring easy  |  Actual Points:
Parent ID:  #23605| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+

Comment (by asn):

 Replying to [comment:1 ffmancera]:
 > I am going to work on this patch. This seems to be huge because there is
 a lot of files using timing sources in `src/features/hs`. I am going to
 add some notes in the ticket if there is no problem.

 Agreed that this is an abstract enough task that keeping notes will be
 useful.

 > I saw that we are using `approx_time()` which is an alias of
 `time(NULL)`, but at the same time and in the same file, we are using
 both. As `approx_time.h` has different utilities for timing, we should use
 it instead of `time(NULL)`. What do you think?

 Yes, I think we should be using `approx_time()` instead of `time(NULL)`
 everywhere. I don't see a reason not to.

 One of the problems with HS timing is that lots of the time sources come
 from the main event loop where `time(NULL)` is used.

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

Re: [tor-bugs] #27299 [Core Tor/Tor]: hsv3: Clarify timing sources around hsv3 code

[Tor Bug Tracker & Wiki]

#27299: hsv3: Clarify timing sources around hsv3 code
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs hsv3 refactoring easy  |  Actual Points:
Parent ID:  #23605| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by teor):

 * sponsor:   => Sponsor8-can
 * parent:   => #23605


Comment:

 I think we should use approx_time() consistently, because it saves CPU on
 some platforms.

 Tentatively assigning to Sponsor 8.

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

Re: [tor-bugs] #27299 [Core Tor/Tor]: hsv3: Clarify timing sources around hsv3 code

[Tor Bug Tracker & Wiki]

#27299: hsv3: Clarify timing sources around hsv3 code
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs hsv3 refactoring easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by ffmancera):

 I am going to work on this patch. This seems to be huge because there is a
 lot of files using timing sources in `src/features/hs`. I am going to add
 some notes in the ticket if there is no problem.

 I saw that we are using `approx_time()` which is an alias of `time(NULL)`,
 but at the same time and in the same file, we are using both. As
 `approx_time.h` has different utilities for timing, we should use it
 instead of `time(NULL)`. What do you think?

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

[tor-bugs] #27299 [Core Tor/Tor]: hsv3: Clarify timing sources around hsv3 code

[Tor Bug Tracker & Wiki]

#27299: hsv3: Clarify timing sources around hsv3 code
--+--
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs hsv3 refactoring easy
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 A big source of bugs and confusions (e.g. #26980, #26930) in the HSv3 code
 stem from the fact that it uses various timing sources to compute time
 periods, SRV, etc. Some parts of the code use `time(NULL)`, others use the
 current consensus valid-after, and others use the voting-schedule.

 The code is currently not clear in which timing source is used in each
 case. As an example, some functions take as input `now` but they only use
 it to get a live consensus to use its valid-after, but that may confuse a
 reader that the `now` is used as the time source (e.g.
 `should_rotate_descriptors()` that caused the #26930 confusion).

 We should try to clarify and improve the function signatures around the
 HSv3 codebase on this regard.

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