| Commit message (Collapse) | Author | Age |
| ... | |
| | | |
| | |
| | |
| | |
| | |
| | | |
In the initialisor of Dist.IPBasedDistributor, the `ipCatagories` and
`answerParameters` both default to `None` and then they are immediately
iterated over.
|
| | | |
| | |
| | |
| | |
| | | |
General exceptions here are never raised, and all exceptions which are
raised are handled by the calling function, parseRLine().
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There were some cases raised within the unittests where, when the IP
address had failed to parse, `networkstatus.parseALine()` would return
an `addr.PortList` and `None` (for the IP). Having a PortList without an
IP address is useless, so instead we should deal with parsing the IP
first, and checking its validity. Then, if we have the IP, we should
parse and check the ports, then create the PortList.
* CHANGE logic of the bridgedb.parse.networkstatus.parseALine()
function so that all of the parsing takes place in one `try:`
block, and the `except`s catch any and all raised errors, logging
messages and reseting variables to None as appropriate.
* ADD a FutureWarning if we ever see a networkstatus document with a
valid IPc4 address as one of its `ORAddress`es, because this means
that tor/torspec and the descriptors have changed format.
* CHANGE networkstatus.parseALine() to only return a PortList if an IP
address was successfully parsed.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Rather than raising exceptions during parsing, we should try to log
appropriate messages. If the error had a known cause, i.e. one that is
due to a badly formatted descriptor, then we should make note of the
relevant information from the bad descriptor, and reset any affected
variables to None.
If the error is possibly do to a newly implemented change in the
descriptor format in tor, we should likewise log the event, generate a
loud warning about a possible descriptor format change, and continue as
before. In networkstatus documents and [bridge-]server-descriptors, it
is possible that the `ORAddress` lines may soon change (#9729):
1. to allow more than one ORAddress line, and
2. to allow extra IPv4 addresses in the ORAddress lines.
Additionally, remove exception and handlers which are never raised in
parseRLine().
1. The catch for `IndexError`s in networkstatus.parseRLine() is
removed:
At the beginning of `parseRLine()`, a `NetworkstatusParsingError` is
raised if there are less than eight fields in the descriptor, so
there is no way that an `IndexError` would ever get raised. Coverage
branch reports also show that this `except:` block is never touched.
2. Remove the `InvalidNetworkstatusDescriptorDigest` exception class:
…as well as all corresponding code for raising and handling it. The
way it was used, there is no possible way that these lines will get
executed, because the descriptor digest will either be a str or
None. If None, then an error is raised earlier for having too few
fields in the 'r'-line. If a str, then `binascii.a2b_base64() will
always produce some kind of string, and its exceptions are handled
separate. Therefore, there is no way for the descriptor digest to be
0, None, or False.
In `bridgedb.parse.networkstatus.parseRLine()` function:
* CHANGE to catch and handle all `InvalidNetworkstatusRouterIdentity`,
and `NetworkstatusParsingErrors`, exceptions raised during parsing.
* REMOVE unnecessary `except IndexError` block.
* REMOVE `InvalidNetworkstatusDescriptorDigest` exception class.
* CHANGE logging of caught exceptions to use `exc`, not
`exc.message`. The later has been deprecated since Python2.6.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The lines following this one (i.e. ``stable = 'Stable' in flags``)
ensure that if a particular flags isn't present in the flags, then the
variable is false; there is no need to set each variable twice.
* REMOVE duplicate variable instantiation/setting from
bridgedb.parse.networkstatus.parseSLine() function.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Before, it was only printing whatever was originally found in the
networkstatus line, *not* which flags we had successfully parsed. Since
we only actually care that we are correctly able to parse relevant
flags, that is what the log message should contain.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
It isn't used anywhere else, and it would be silly to import it from
here, so there is no reason to have it at the module level.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
* ADD documentation on default variables and how the unittest setup methods
are used.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This ensures that an addr.InvalidPort exception is raised when an invalid port
is discovered, without continuing to parse the rest of the ports. The end
result, i.e. when/if an exception is raised, stays exactly the same. This just
operates more efficiently when there is a bad port number.
|
| | | |
| | |
| | |
| | | |
This ensures that the return value has truthiness.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
We only want to know if it is IPv4 or IPv6, *not* if it conforms to all kinds
of crazy routing RFCs.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ / |
|
| |\ \ |
|
| | | | |
|
| |/ /
| |
| |
| |
| | |
Base64 padding will only ever result in a maximum of two trailing '='s
characters, not a gazillion.
|
| | | |
|
| | | |
|
| | | |
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The sphinx.ext.todo seem not to be working…
It is supposed to work, I believe, by putting the following into a
docstring:
class Foo(object):
"""A foo.
.. todo:: Do something about bar.
"""
And then the `.. todolist::` directive in Sphinx will find all such
`.. todo::` directives in your code, and put them in a list (the way I
was doing it, these would be on the index.html page) with links to where
the `.. todo::` is in the source code.
However, this seems to *only* work in docstrings proper in Python, the
following do *not* get picked up by the `.. todolist::` Sphinx
directive:
* Normal Python inline comments, i.e.:
# .. todo:: There is this thing we should do.
* Sphinx attribute inline comments, i.e.:
#: .. todo:: There is also another thing we should do.
Because all of the TODOs in BridgeDB are currently within normal Python
inline comments, the `.. todolist::` on the index page doesn't include
anything, and thus there is an awkward looking, giant, blank header with
nothing underneath it. Thus, I'm taking out the header, but leaving in
the `.. todolist::` directive (so that we *can* use `.. todo::` in a
proper docstring in the future and it will be automatically included in
the documentation here).
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ / |
|
| | | |
|
| |\ \ |
|
| | | | |
|
| | | | |
|