Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:13Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33956Define and use TOR_ADDRPORT_BUF_LEN2020-06-13T15:53:13ZteorDefine and use TOR_ADDRPORT_BUF_LENIn #33918, we discovered a bug where IPv6 addresses were being truncated in logs.
During the fix, we noticed that we had a TOR_ADDR_BUF_LEN, but no equivalent constant for addresses and ports. The new TOR_ADDRPORT_BUF_LEN should allow s...In #33918, we discovered a bug where IPv6 addresses were being truncated in logs.
During the fix, we noticed that we had a TOR_ADDR_BUF_LEN, but no equivalent constant for addresses and ports. The new TOR_ADDRPORT_BUF_LEN should allow space for:
* TOR_ADDR_BUF_LEN
* IPv6 brackets (2, if not included in TOR_ADDR_BUF_LEN already)
* the port separator (1)
* the port (5)
We should check for other truncation errors while making this change.Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33739Authority-mode keys and certificates should be owned by dirauth module2020-06-13T15:52:35ZNick MathewsonAuthority-mode keys and certificates should be owned by dirauth moduleRight now these functions are defined in the relay module, when only dirauths need them:
* get_my_v3_authority_cert
* get_my_v3_authority_signing_key
* get_my_v3_legacy_cert
* get_my_v3_legacy_signing_key
We should move them alo...Right now these functions are defined in the relay module, when only dirauths need them:
* get_my_v3_authority_cert
* get_my_v3_authority_signing_key
* get_my_v3_legacy_cert
* get_my_v3_legacy_signing_key
We should move them along with related fields and support functions, to feature/dirauth.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32887Remove use of NS() macros to make our code more indentable?2020-06-13T15:49:46ZNick MathewsonRemove use of NS() macros to make our code more indentable?clang-format doesn't do very well with our NS() macros defined in test.h. And we don't actually use those macros very much, and we haven't used them for new tests in a while. Shall we remove them?clang-format doesn't do very well with our NS() macros defined in test.h. And we don't actually use those macros very much, and we haven't used them for new tests in a while. Shall we remove them?Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31074Use tor_queue.h macros in config_line_t2020-06-13T15:43:20ZNick MathewsonUse tor_queue.h macros in config_line_tThe config_line_t linked list could be refactored to use the TOR_SLIST macros in tor_queue.hThe config_line_t linked list could be refactored to use the TOR_SLIST macros in tor_queue.hTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30968Refactor unit test asserts so they log context2020-06-13T15:42:57ZteorRefactor unit test asserts so they log contextIn #30721, I created some complex macros to preserve line numbers when the unit tests fail.
We could refactor these macros into functions, if the tiny test assertions supported context.
catalyst suggests allowing file and line numbers ...In #30721, I created some complex macros to preserve line numbers when the unit tests fail.
We could refactor these macros into functions, if the tiny test assertions supported context.
catalyst suggests allowing file and line numbers (and functions?):
> I think I see that the problem is buried in the `TT_DECLARE()` macro in `tinytest_macros.h`. I think it's possible to work around it, but it might be nontrivial. (Rough sketch: redefine `TT_DECLARE()` in helper functions to read file and line info from function parameters, and make file and line numbers explicit parameters to helper functions.)
I suggest allowing a format string, which could also print the data that we're testing. (For the tor_addr_port_lookup() tests, the best context is the address string.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30816Remove ping ::1 from tor's test-network-all and simplify the logic2020-06-13T15:42:20ZteorRemove ping ::1 from tor's test-network-all and simplify the logicAfter #30459 is merged into chutney, and everyone updates, we can remove the complicated checks for IPv6 from tor's test-network-all.After #30459 is merged into chutney, and everyone updates, we can remove the complicated checks for IPv6 from tor's test-network-all.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30721tor_addr_port_lookup() is overly permissive2020-06-13T15:42:01Zteortor_addr_port_lookup() is overly permissiveLike tor_addr_parse() in #23082, tor_addr_port_lookup() also allows square brackets around IPv4 addresses.
But it's slightly less permissive: it requires a terminating `]`.
For example, this command line should be rejected, but it is n...Like tor_addr_parse() in #23082, tor_addr_port_lookup() also allows square brackets around IPv4 addresses.
But it's slightly less permissive: it requires a terminating `]`.
For example, this command line should be rejected, but it is not:
```
tor ORPort [127.0.0.1]:9001
```Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/30155If we are still using the shell to launch tests, have a separate script for e...2020-06-13T13:31:00ZteorIf we are still using the shell to launch tests, have a separate script for each testFollow up for #30063 and #30154.Follow up for #30063 and #30154.https://gitlab.torproject.org/legacy/trac/-/issues/30154Use the built-in unittest module for chutney's unit tests2020-06-13T13:30:59ZteorUse the built-in unittest module for chutney's unit testsFollow-up to #30063.Follow-up to #30063.https://gitlab.torproject.org/legacy/trac/-/issues/30153Add a command to chutney and test-network.sh that prints the default option v...2020-06-13T13:30:59ZteorAdd a command to chutney and test-network.sh that prints the default option valuesFollow up to #30059.
We should make a chutney command and a test-network.sh command that prints their default option values.
Maybe we could even import the defaults from chutney into test-network.sh.
Then we can update the README to s...Follow up to #30059.
We should make a chutney command and a test-network.sh command that prints their default option values.
Maybe we could even import the defaults from chutney into test-network.sh.
Then we can update the README to say:
"For the default values of these options, run..."https://gitlab.torproject.org/legacy/trac/-/issues/29726Rename constants, variables, classes, methods, functions2020-06-13T16:15:40ZjugaRename constants, variables, classes, methods, functionsSome ideas are in https://pad.riseup.net/p/rGfvR7ZsvtoZ.
It would be nice to create first a list of all the things to rename and the proposed new names.
It should be done file for file as possible and be reviewed/merged fast to avoid m...Some ideas are in https://pad.riseup.net/p/rGfvR7ZsvtoZ.
It would be nice to create first a list of all the things to rename and the proposed new names.
It should be done file for file as possible and be reviewed/merged fast to avoid many merge conflicts.
Only a part of this was https://github.com/torproject/sbws/issues/202.sbws: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29721Refactor RelayList2020-06-13T16:15:38ZjugaRefactor RelayListRefactor 1:
It should probably have a dictionary of relays instead of a list, so that it is not needed to convert the list to dictionary in resultdump.
It should be then named `Relays` or `RelayDict`
In https://github.com/torproject/sbws...Refactor 1:
It should probably have a dictionary of relays instead of a list, so that it is not needed to convert the list to dictionary in resultdump.
It should be then named `Relays` or `RelayDict`
In https://github.com/torproject/sbws/issues/219 it was proposed to change the list to a set, but that's only used to exclude authorities in the prioritizer, which should also be a method in RelayList.sbws: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29718Include a refactor plan2020-06-13T16:15:36ZjugaInclude a refactor planThe parent ticket have some children tickets and we collected some ideas in https://pad.riseup.net/p/rGfvR7ZsvtoZ, but there are other ideas not collected.The parent ticket have some children tickets and we collected some ideas in https://pad.riseup.net/p/rGfvR7ZsvtoZ, but there are other ideas not collected.sbws: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29717Refactor Relay and RelayList to be able to initialize them without Tor's cont...2020-06-13T16:15:36ZjugaRefactor Relay and RelayList to be able to initialize them without Tor's controllerIt would be easier to create unit tests without the need of having a stem's Controller instance, but only providing consensus and relay descriptor documents.It would be easier to create unit tests without the need of having a stem's Controller instance, but only providing consensus and relay descriptor documents.sbws: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29716Change the way the consensus is received2020-06-13T16:15:35ZjugaChange the way the consensus is receivedCurrently it receives the new consensuses using https://stem.torproject.org/api/control.html#stem.control.Controller.get_network_statuses, which uses the cached-consensus and might not be updated.
It should probably receive the new conse...Currently it receives the new consensuses using https://stem.torproject.org/api/control.html#stem.control.Controller.get_network_statuses, which uses the cached-consensus and might not be updated.
It should probably receive the new consensuses as soon as they arrive using an event listener https://stem.torproject.org/api/control.html#stem.control.Controller.add_event_listener, instead of every x time.sbws: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29108Refactor crypto_digest.c to have fewer ifdefs2020-06-13T15:36:52ZNick MathewsonRefactor crypto_digest.c to have fewer ifdefsOur current crypto_digest.c is a maze of twisty little ifdefs, and OpenSSL keccak support in #28837 will make it even more so. We ought to refactor it so that it's less idiosyncratic.
Possibly we should take the same approach as in the...Our current crypto_digest.c is a maze of twisty little ifdefs, and OpenSSL keccak support in #28837 will make it even more so. We ought to refactor it so that it's less idiosyncratic.
Possibly we should take the same approach as in the other crypto_ops modules, and divide it into an OpenSSL portion, a NSS portion, and a common portion.Tor: 0.4.1.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/29057Adapt bandwidth file classes to be compatible with stem (descriptors, etc) do...2020-06-13T16:15:21ZjugaAdapt bandwidth file classes to be compatible with stem (descriptors, etc) documentsso that the code can be moved to stem, as commented in #29056so that the code can be moved to stem, as commented in #29056sbws: unspecifiedjugajugahttps://gitlab.torproject.org/legacy/trac/-/issues/29048Remove unused code2020-06-13T16:15:20ZjugaRemove unused codesbws: unspecifiedjugajugahttps://gitlab.torproject.org/legacy/trac/-/issues/29047Improve code style following PEP8 and PEP2572020-06-13T16:15:19ZjugaImprove code style following PEP8 and PEP257sbws: unspecifiedjugajugahttps://gitlab.torproject.org/legacy/trac/-/issues/28905Please install packages for twisted gettor2020-06-13T16:56:14ZIsrael LeivaPlease install packages for twisted gettorA code refactor has been made to gettor using twisted (see #28152). The following packages are needed for it to work:
gcc python2.7 python-dev virtualenv sqlite3 python-pip
Thanks.A code refactor has been made to gettor using twisted (see #28152). The following packages are needed for it to work:
gcc python2.7 python-dev virtualenv sqlite3 python-pip
Thanks.