[tor-bugs] #20224 [Metrics/CollecTor]: Fix `BridgeDescriptorMappingsLimit` config option

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Oct 3 18:42:43 UTC 2016


#20224: Fix `BridgeDescriptorMappingsLimit` config option
-------------------------------+------------------------------
 Reporter:  karsten            |          Owner:
     Type:  defect             |         Status:  needs_review
 Priority:  Low                |      Milestone:
Component:  Metrics/CollecTor  |        Version:
 Severity:  Normal             |     Resolution:
 Keywords:                     |  Actual Points:
Parent ID:                     |         Points:
 Reviewer:                     |        Sponsor:
-------------------------------+------------------------------

Comment (by karsten):

 Hmm, no, that seems wrong or at least confusing, and on second thought my
 patch above is wrong or at least confusing, too.

 Here's a table with some timestamps that seem to be relevant here:

 ||= Row=||= `BridgeDescriptorMappingsLimit`=||= ''Milliseconds since the
 epoch''=||=''ISO-8601 date/time'' =||
 || 1|| `0`|| `1475517323620`|| AD 2016-10-03 17:55:23.620 ||
 || 2|| `6120.7468`|| `946684799999`|| AD 1999-12-31 23:59:59.999 ||
 || 3|| `17077.7468`|| `-1`|| AD 1969-12-31 23:59:59.999 ||
 || 4|| `17102.6019`|| `-Integer.MAX_VALUE = -2147483647`|| AD 1969-12-07
 03:28:36.353 ||
 || 5|| `-Integer.MAX_VALUE = -2147483647`|| `-185541111583476380`|| BC
 5877475-12-05 17:55:23.620 ||

 Explanations for these rows:
  1. This is the current date/time, so if we had put in `0` as value for
 `BridgeDescriptorMappingsLimit`, that's what the cut off time would have
 been.
  2. This is what we had put in before using `Integer.MAX_VALUE` as
 parameter default value, and this date in 1999 is indeed small enough that
 no bridge descriptor could have been published earlier.
  3. This is what I had in mind in my patch above: pick `-1` as smallest
 possible time in milliseconds since the epoch, but only because I had
 misread 1999 as 1969.  Oops.
  4. That's what I think you're suggesting above, and I think it doesn't
 really make sense to use this threshold to decide whether or not to fall
 back to a date in 1999.
  5. Here's the explanation for this bug, which I found out today: we're
 not looking at an integer overflow/underflow, we're looking at BC dates
 rather than AD dates, and we're not including AD/BC in the output date
 format.  Ugh!

 My suggestion is to cut off at `1999-12-31 23:59:59` by hard-coding that
 date/time in milliseconds as threshold.  Untested code:

 {{{
        SimpleDateFormat formatter = new SimpleDateFormat(
            "yyyy-MM-dd HH:mm:ss");
        formatter.setTimeZone(TimeZone.getTimeZone("UTC"));
        long cutTime = System.currentTimeMillis() - 24L * 60L * 60L * 1000L
            * limitBridgeSanitizingInterval);

        final long MIN_CUT_TIME = 946684799999L;
        if (cutTime > MIN_CUT_TIME) {
          this.bridgeSanitizingCutOffTimestamp = formatter.format(cutTime);
        } else {
          this.bridgeSanitizingCutOffTimestamp = "1999-12-31 23:59:59";
        }
 }}}

 Does this make sense?  If so, want to submit another patch?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20224#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list