#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 _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs