Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T13:29:24Zhttps://gitlab.torproject.org/legacy/trac/-/issues/16806Chutney/integration tests for DNS server/client functionality2020-06-13T13:29:24ZNick MathewsonChutney/integration tests for DNS server/client functionalityhttps://gitlab.torproject.org/legacy/trac/-/issues/15418chutney: add debug command-line flag2020-06-13T13:29:17Zteorchutney: add debug command-line flagchutney has a debug variable `debug_flag` in `Traffic.py`.
This would be much easier to use if it was set from the command-line, or even automatically activated (at some level) on transmission failure.chutney has a debug variable `debug_flag` in `Traffic.py`.
This would be much easier to use if it was set from the command-line, or even automatically activated (at some level) on transmission failure.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/15419chutney: on failure, explain which connection failed2020-06-13T13:29:17Zteorchutney: on failure, explain which connection failedWhen there's a failure in the chutney data transmission tests, it would be really, really helpful to know which connection failed. The debug flag doesn't quite do this yet, but it's pretty close.
This is particularly important now that ...When there's a failure in the chutney data transmission tests, it would be really, really helpful to know which connection failed. The debug flag doesn't quite do this yet, but it's pretty close.
This is particularly important now that chutney supports three different types of connectivity tests (in the same network):
* client -> exit
* bridge client -> exit
* [bridge] client -> hidden service
Over two different protocols:
* IPv4
* IPv6 (currently bridges only)https://gitlab.torproject.org/legacy/trac/-/issues/15784Clarify Chutney exit policies for IPv4 and IPv6, including private addresses2020-06-13T13:29:19ZteorClarify Chutney exit policies for IPv4 and IPv6, including private addressesAllow chutney exits to exit to all private addresses.
Tidy up exit policies, so each part of the policy is clearly identified.
Document alternatives to work around #11264, the microdescriptor 2x /8 requirement for exits.
Prepare for r...Allow chutney exits to exit to all private addresses.
Tidy up exit policies, so each part of the policy is clearly identified.
Document alternatives to work around #11264, the microdescriptor 2x /8 requirement for exits.
Prepare for resolving #15353 by making sure the exit policies *should* work when localhost is the only available IP. This still requires further investigation.
Patch:
**Branch:** clarify-exit-policies
**Repository:** ​https://github.com/teor2345/chutney.gitteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/19322colntroller: add events for "I uploaded my own descriptor" or "I regenerated ...2020-06-13T14:58:29ZNick Mathewsoncolntroller: add events for "I uploaded my own descriptor" or "I regenerated my own descriptor"Tor: unspecifiedYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/14164Controller method to get our own descriptor2020-06-13T14:41:41ZtoralfController method to get our own descriptorI'm wondering why this pythin snippet
```
def main():
ControlPort = 9051
ProcessName = 'tor'
with Controller.from_port(port = ControlPort) as controller:
controller.authenticate()
#print " Tor version %s" % controller.get_...I'm wondering why this pythin snippet
```
def main():
ControlPort = 9051
ProcessName = 'tor'
with Controller.from_port(port = ControlPort) as controller:
controller.authenticate()
#print " Tor version %s" % controller.get_version()
try:
desc = controller.get_microdescriptor()
print " flags : %s" % desc.flags()
print " measured bandwidth : %i" % desc.measured()
except Exception as exc:
print exc
#pass
```
gives
```
Tor was unable to provide the descriptor for 'F1BE15429B3CE696D6807F4D4A58B1BFEC45C822'
```
Does this means that stems asks tor and tor doesn't know itself ?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19324controller: events for hidden service intro point changes, descriptor changes...2020-06-13T14:58:29ZNick Mathewsoncontroller: events for hidden service intro point changes, descriptor changes, uploads, etcTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19320controller: expose and adjust timer values2020-06-13T14:58:28ZNick Mathewsoncontroller: expose and adjust timer valuesWe're increasingly making our periodic timers first-class. If we give them names, then we can monitor (or adjust them) from the controller for testing purposes.We're increasingly making our periodic timers first-class. If we give them names, then we can monitor (or adjust them) from the controller for testing purposes.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19318controller: expose cache details.2020-06-13T14:58:27ZNick Mathewsoncontroller: expose cache details.It might be handy good to know, for each descriptor or other cached thing: where it's stored, how it's stored, what annotations on it, etc. We could have controller events for discarding things from the cache, cache compaction, etc.It might be handy good to know, for each descriptor or other cached thing: where it's stored, how it's stored, what annotations on it, etc. We could have controller events for discarding things from the cache, cache compaction, etc.Tor: unspecifiedYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/19323controller: expose Download timer/timeout/retry information2020-06-13T14:58:29ZNick Mathewsoncontroller: expose Download timer/timeout/retry informationTor: 0.2.9.x-finalAndrea ShepardAndrea Shepardhttps://gitlab.torproject.org/legacy/trac/-/issues/19319controller: GETINFO stats to expose OOM details2020-06-13T14:58:27ZNick Mathewsoncontroller: GETINFO stats to expose OOM detailsOur OOM handler keeps track of lots of memory-consumers. We could expose that info to the controller.Our OOM handler keeps track of lots of memory-consumers. We could expose that info to the controller.Tor: unspecifiedYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/19325controller: getinfo to get status of cpuworker queues2020-06-13T14:58:30ZNick Mathewsoncontroller: getinfo to get status of cpuworker queuesTor: unspecifiedYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/19326Examine fine-grained connection detail; expose via control API2020-06-13T14:58:30ZNick MathewsonExamine fine-grained connection detail; expose via control APIconnections have lots of fields on them, and not all are currently exposed via getinfo. For testing, it might be useful to list more.connections have lots of fields on them, and not all are currently exposed via getinfo. For testing, it might be useful to list more.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18685Fire a`STATUS_SERVER` event when the hibernation state changes.2020-06-13T14:55:53ZYawning AngelFire a`STATUS_SERVER` event when the hibernation state changes.Most of the hibernation related information is already exposed in a useful manner via `GETINFO`. As far as I can tell the only really other useful thing to do here is to fire an event whenever we enter/exit hibernation so that controlle...Most of the hibernation related information is already exposed in a useful manner via `GETINFO`. As far as I can tell the only really other useful thing to do here is to fire an event whenever we enter/exit hibernation so that controllers don't have to poll continuously via `GETINFO`.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18185Fix coding style according to PEP82020-06-13T13:29:39ZcypherpunksFix coding style according to PEP8The pep8 tool shows several minor PEP8 violations. Fixing these violations would makes it easier for future developers (including me) to check whether their patches are according to the PEP8 without having to ignore existing violations. ...The pep8 tool shows several minor PEP8 violations. Fixing these violations would makes it easier for future developers (including me) to check whether their patches are according to the PEP8 without having to ignore existing violations. Also having existing violations gives future developers less incentive to fix violations they introduce.cypherpunkscypherpunkshttps://gitlab.torproject.org/legacy/trac/-/issues/19033Fuzz out of bounds reads during nodelist processing2020-06-13T14:57:18ZteorFuzz out of bounds reads during nodelist processingWe want to make sure we fixed all the issues with nodelist processing in #19032.
arma says this could be SponsorS or SponsorU.We want to make sure we fixed all the issues with nodelist processing in #19032.
arma says this could be SponsorS or SponsorU.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18809Handle linked connections better during bootstrap2020-06-13T14:57:32ZteorHandle linked connections better during bootstrapbegindir connections advance directly to the CLIENT_SENDING state, even before their TLS connection is created.
So we need to modify the logic from #4483 that checks for consensuses that are downloading:
* is it a direct connection in s...begindir connections advance directly to the CLIENT_SENDING state, even before their TLS connection is created.
So we need to modify the logic from #4483 that checks for consensuses that are downloading:
* is it a direct connection in state after connecting, or
* a linked connection that's attached, or
* a linked connection that's in a state after sending
And then do the standard "extra consensus download check" when we're about to link a directory connection to a TLS connection.
Or arma may have a better idea.
I am not sure whether we should fix this in 0.2.8, because the current code works, but it's not optimal when too many TLS connections hang.
Tagging it just in case.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/16792Have a way to mark lines as "unreachable by unit tests"2020-06-13T15:15:02ZNick MathewsonHave a way to mark lines as "unreachable by unit tests"It would be great to have a way to tell the test coverage code "this line won't be reached by tests, so don't worry about it." This would let us have a prayer of reaching 100%.It would be great to have a way to tell the test coverage code "this line won't be reached by tests, so don't worry about it." This would let us have a prayer of reaching 100%.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/16808High coverage on connection_edge, addressmap2020-06-13T14:48:09ZNick MathewsonHigh coverage on connection_edge, addressmapThese functions get more than their share of bugs, and aren't very well reached by our current tests. We can use integration and unit tests for these.These functions get more than their share of bugs, and aren't very well reached by our current tests. We can use integration and unit tests for these.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16809High coverage on node/path selection functions2020-06-13T14:48:10ZNick MathewsonHigh coverage on node/path selection functionsThese functions are stupidly fragile, since bad behavior tends to happen only under rare circumstances. We should make sure that, through integration and unit tests, we hit all the cases. Note that coverage isn't enough if we don't chec...These functions are stupidly fragile, since bad behavior tends to happen only under rare circumstances. We should make sure that, through integration and unit tests, we hit all the cases. Note that coverage isn't enough if we don't check to make sure that the statistical distribution on paths is good, and the constraints are actually obeyed.Tor: unspecified