Published by DNSEL or TorBEL to indicate what ip address exit relay X had at timestamp Y. Karsten mentioned on #7987 (moved) that this may be relevant for a metrics-lib replacement.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items 0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items 0
Link issues together to show that they're related.
Learn more.
This will skip anything prior to the first 'ExitNode'. The TorDNSEL spec is a tad less formal than other spec types so this is probably appropriate though in most other cases extra content like this is disallowed.
The spec says entries are...
(ExitNode | Published | LastStatus | ExitAddress*)*
Which indicates seems to indicate that the ExitAddress appears zero or more times. Won't the above have problems if ExitAddress doesn't appear for an entry?
+class TorDnsel(Descriptor):
Mind if we rename this class to TorDNSEL?
+ :var list exit_addresses: list of (str address, datetime date) tuples consisting of the found exit address and the time
This should have an asterisk too since the list will always exist (it has a default value of being empty), and lets also mention that it's IPv4 addresses.
+ for keyword, values in entries.items():+ value, _ = values[0]
Lets balk with a validation error if we get any block content.
+ elif keyword == "ExitAddress":+ for value, _ in values:+ address, date = value.split(" ", 1)+ if validate and not stem.util.connection.is_valid_ipv4_address(address):+ raise ValueError("ExitAddress isn't a valid IPv4 address: %s" % address)+ try:+ date = datetime.datetime.strptime(date, "%Y-%m-%d %H:%M:%S")+ except ValueError:+ if validate:+ raise ValueError("ExitAddress found time wasn't parsable: %s" % value)+ self.exit_addresses.append((address, date))
This worries me a little bit because if 'validate' is False then the date we append could be either a datetime or str. Lets continue (skip the entry) when date can't be parsed and validate is False.
Would you mind some assertions about the parsed values? Also, a test or two with invalid content would be nice. For instance, we should probably have a test that parses content without any ExitAddress considering the issue mentioned earlier.
(ExitNode | Published | LastStatus | ExitAddress*)*
but it also says, The document consists of an arbitrary number of entries each consisting of *four* or more lines.
and *One* or more test results for this relay consisting of the found exit address and the time, in UTC, when the test was performed.
So, although it uses the regex star, I think it means plus.
(ExitNode | Published | LastStatus | ExitAddress+)*
Could you interpret it that way? Maybe we should get that updated?
Just to confirm, are you fine with this and your future stem contributions being in the public domain? For an explanation of why I need to ask see here.
Could you interpret it that way? Maybe we should get that updated?
Certainly sounds like it. The spec starts with "This document is an attempt to make sense of the exit list format that TorDNSEL publishes without the original TorDNSEL author being around." so I suppose anything it says should be taken with a grain of salt.