Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T16:15:01Zhttps://gitlab.torproject.org/legacy/trac/-/issues/28718Simplify configuration options2020-06-13T16:15:01ZjugaSimplify configuration optionsPrograms should allow in this order: cli options, user configuration files passed by cli, environment variables, system configuration files and program defaults.
There seems there's not a common easy way to achieve this in Python.
sbws a...Programs should allow in this order: cli options, user configuration files passed by cli, environment variables, system configuration files and program defaults.
There seems there's not a common easy way to achieve this in Python.
sbws accepts cli and user configuration files in a complicated way.
The program defaults are provided as a configuration file which might not be that convenient seems confuses where to find the defaults.
Maybe an external library like https://github.com/bw2/ConfigArgParse (supported in Debian) or some other design can help to simplify this.sbws: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28667Obtain the new descriptors and network status documents by signals instead of...2022-03-03T15:23:50ZjugaObtain the new descriptors and network status documents by signals instead of every 5minThe network status and descriptors are obtained every 5min https://gitweb.torproject.org/sbws.git/tree/sbws/lib/relaylist.py#n144.
Is there any reason for that?.
I think torflow obtain them as they come.
It could be done with stem using:...The network status and descriptors are obtained every 5min https://gitweb.torproject.org/sbws.git/tree/sbws/lib/relaylist.py#n144.
Is there any reason for that?.
I think torflow obtain them as they come.
It could be done with stem using:
```
controller.add_event_listener(
listener_fn, EventType.NS, EventType.NEWDESC)
```
Also, instead overwriting those values, Relay could have a dictionary (key would be the timestamp) with a subset of the attributes of document, in case we might need to calculate median/mean of those attributes
Edit: fix typosbws: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28282Refactor bandwidth file generation code2020-06-13T16:14:19ZjugaRefactor bandwidth file generation codeInitially, `v3bwfile.py` was just converting measurement `Result`s to a `Bandwidth file` lines format.
Then we started to apply scaling methods and filtering the measurements to satisfy certain restrictions.
To don not have to modify cod...Initially, `v3bwfile.py` was just converting measurement `Result`s to a `Bandwidth file` lines format.
Then we started to apply scaling methods and filtering the measurements to satisfy certain restrictions.
To don not have to modify code in other file/classes, all of that was implemented in `v3bwfile.py` classes/methods, but it should be moved to either an intermediate file/classes that deal with the statistics calculations (and not the format) or modify `Results` to be able to perform those calculations.
Edit: fix typosbws: unspecifiedjugajugahttps://gitlab.torproject.org/legacy/trac/-/issues/27892Split the non-stats part of the stats module into different modules2020-06-13T15:32:14ZNick MathewsonSplit the non-stats part of the stats module into different modulesPart of rephist.c is about predicted ports, which aren't really stats.
Part of geoip.c is about stats, but part is about mapping IPs to countries, which isn't stats.
Let's fix this while we can.Part of rephist.c is about predicted ports, which aren't really stats.
Part of geoip.c is about stats, but part is about mapping IPs to countries, which isn't stats.
Let's fix this while we can.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/27864Split router.c and routerkeys.c into separate modules2020-06-13T15:32:13ZNick MathewsonSplit router.c and routerkeys.c into separate modulesTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/27662refactor networkstatus_parse_vote_from_string()2020-06-13T15:31:13ZTracrefactor networkstatus_parse_vote_from_string()As of [1c62adb65baa99c92f937318c452955306301643](https://gitweb.torproject.org/tor.git/tree/src/feature/nodelist/routerparse.c?id=1c62adb65baa99c92f937318c452955306301643#n3395), the function is 628 lines long. It could be split into cal...As of [1c62adb65baa99c92f937318c452955306301643](https://gitweb.torproject.org/tor.git/tree/src/feature/nodelist/routerparse.c?id=1c62adb65baa99c92f937318c452955306301643#n3395), the function is 628 lines long. It could be split into calling 3 helper functions instead.
**Trac**:
**Username**: cyberpunksTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27417refactor conn_close_if_marked() in main.c2020-06-13T15:30:36ZTracrefactor conn_close_if_marked() in main.c
**Trac**:
**Username**: cyberpunks
**Trac**:
**Username**: cyberpunksTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27362(sub-)packages outside of core (cli) should not need to know about confs and ...2020-06-13T16:13:51Zjuga(sub-)packages outside of core (cli) should not need to know about confs and argsThat would help to have a more modular design and use other (sub)packages and (sub)modules without the need of creating ConfigParser and ArgumentParser objects.
It also would help to simplify tests configurations.
Additionally, a progra...That would help to have a more modular design and use other (sub)packages and (sub)modules without the need of creating ConfigParser and ArgumentParser objects.
It also would help to simplify tests configurations.
Additionally, a program should take into account in this order:
- cli arguments
- environment variables
- user configuration files
- system configuration files
- program defaults
That is currently almost match. but it would be better if they all can be took into account in a simpler way.
This is not for MVP, but creating the ticket cause i'm creating new code taking this into account, and would be nice to change at some point.
Some tickets, as #27358, happen because of this.sbws: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27345Make tor use chutney mixed+hs-v2 and bridges+hs-v22020-06-13T15:30:19ZteorMake tor use chutney mixed+hs-v2 and bridges+hs-v2Currently, tor uses mixed+hs-v23 (which doesn't actually run v3 onion services), and bridges+hs (which doesn't say what version it uses).
We can do better.Currently, tor uses mixed+hs-v23 (which doesn't actually run v3 onion services), and bridges+hs (which doesn't say what version it uses).
We can do better.Tor: 0.3.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/26564Tor compilation fails when cross-compiling for macOS2020-06-13T15:27:22ZGeorg KoppenTor compilation fails when cross-compiling for macOSOur latest nightly build is failing when (cross)-compiling `tor` for macOS:
```
CC src/lib/process/env.o
src/lib/process/env.c:40:11: warning: implicit declaration of function '_NSGetEnviron' is invalid in C99 [-Wimplicit-functio...Our latest nightly build is failing when (cross)-compiling `tor` for macOS:
```
CC src/lib/process/env.o
src/lib/process/env.c:40:11: warning: implicit declaration of function '_NSGetEnviron' is invalid in C99 [-Wimplicit-function-declaration]
return *_NSGetEnviron();
^
src/lib/process/env.c:40:10: error: indirection requires pointer operand ('int' invalid)
return *_NSGetEnviron();
^~~~~~~~~~~~~~~~
1 warning and 1 error generated.
Makefile:7498: recipe for target 'src/lib/process/env.o' failed
```Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/26502Stop using the fallback blacklist, and delete it2020-06-13T16:06:29ZteorStop using the fallback blacklist, and delete itWe require relay operators to opt-in to being fallbacks, and we won't ever switch to opt-out. (See #24789.)
So we don't need the fallback blacklist any more.
We should stop loading the blacklist in the script, then delete it.We require relay operators to opt-in to being fallbacks, and we won't ever switch to opt-out. (See #24789.)
So we don't need the fallback blacklist any more.
We should stop loading the blacklist in the script, then delete it.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/26478Unify bandwidth related terms in dir-spec and Tor code.2020-06-13T15:27:04ZjugaUnify bandwidth related terms in dir-spec and Tor code.Unifying these terms would make following what these bandwidth do in the code and the spec less confusing.
For instance:
- what is called `bandwidthrate` [0] in the code when building the descriptor, it is called `bandwidth-avg` in `dir-...Unifying these terms would make following what these bandwidth do in the code and the spec less confusing.
For instance:
- what is called `bandwidthrate` [0] in the code when building the descriptor, it is called `bandwidth-avg` in `dir-spec.txt` [1].
- what is called `bandwidthcapacity` [2] in the code, it is called `bandwidth-observed` in `dir-spec.txt`[1]
I don't know if it is prefered to modify terms in the spec or in the code.
It'd be also helpful to add formulae or more detailed descriptions on how the different bandwidth terms are generated in dir-spec.txt
[0] https://gitweb.torproject.org/tor.git/tree/src/or/router.c#n2370
[1] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n427
[2] https://gitweb.torproject.org/tor.git/tree/src/or/router.c#n2376Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26426Remove dmalloc support2020-06-13T15:26:51ZNick MathewsonRemove dmalloc supportDmalloc hasn't had a new release since 2007, and I haven't seen anybody run it in ages. It's been superseded by stuff like gperftools and asan.Dmalloc hasn't had a new release since 2007, and I haven't seen anybody run it in ages. It's been superseded by stuff like gperftools and asan.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/26296Refactor cell crypto to pre/post crypto operations2020-06-13T15:26:22ZChelsea KomloRefactor cell crypto to pre/post crypto operationsThe process of crypting a cell should be split so that parallelism can later be cleanly introduced.
In short, we should separate logic that occurs before the crypto operation(s) and afterward. This should be done so that a "unit of wor...The process of crypting a cell should be split so that parallelism can later be cleanly introduced.
In short, we should separate logic that occurs before the crypto operation(s) and afterward. This should be done so that a "unit of work" becomes crypting a cell (where one or more crypto operations can occur), and logic that happens before/after cryption is cleanly separated.
This is pre-work that is required for #1749.Tor: unspecifiedChelsea KomloChelsea Komlohttps://gitlab.torproject.org/legacy/trac/-/issues/26270Move dirauth module code from src/or/dirauth to src/dirauth2020-06-13T15:26:12ZAlexander Færøyahf@torproject.orgMove dirauth module code from src/or/dirauth to src/dirauthDuring the modularization discussion at the network team Seattle hackfest we decided to move the dirauth module code from src/or/dirauth to src/dirauth.During the modularization discussion at the network team Seattle hackfest we decided to move the dirauth module code from src/or/dirauth to src/dirauth.Tor: 0.3.5.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/26036macOS regression in crypto_rand.c refactor2020-06-13T15:25:28ZTaylor YumacOS regression in crypto_rand.c refactorThe refactoring that created crypto_rand.c is missing includes of sys/syscall.h and sys/random.h. sys/random.h is needed for `getentropy()` on macOS 10.12 Sierra. Omitting sys/syscall.h might also cause us to fail to detect a `getrando...The refactoring that created crypto_rand.c is missing includes of sys/syscall.h and sys/random.h. sys/random.h is needed for `getentropy()` on macOS 10.12 Sierra. Omitting sys/syscall.h might also cause us to fail to detect a `getrandom()` syscall on Linux when that's supported.Tor: 0.3.4.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/25990module: Better safeguard authdir_mode_v3() if dirauth module is disabled2020-06-13T15:25:16ZDavid Gouletdgoulet@torproject.orgmodule: Better safeguard authdir_mode_v3() if dirauth module is disabledWe need to safeguard somehow the `authdir_mode_v3()` so it can NEVER return true if the dirauth module is disabled.
One option here is to move this function to the dirauth module and NOP it by returning false if the module is not enable...We need to safeguard somehow the `authdir_mode_v3()` so it can NEVER return true if the dirauth module is disabled.
One option here is to move this function to the dirauth module and NOP it by returning false if the module is not enabled.
An other option is to #ifdef `HAVE_MODULE_DIRAUTH` in the function directly. I'm kind of less enthusiastic about it but maybe it is better, dunno yet.Tor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/25989module: Improve dirauth module by extracting more code2020-06-13T15:25:15ZDavid Gouletdgoulet@torproject.orgmodule: Improve dirauth module by extracting more codeAfter #25610, we've identified items to pursue as a second milestone in the dirauth modularization effort.
One of these is to start extracting dirauth specific code from `directory.c`, `dirserv.c` and `networkstatus.c` which have a lot ...After #25610, we've identified items to pursue as a second milestone in the dirauth modularization effort.
One of these is to start extracting dirauth specific code from `directory.c`, `dirserv.c` and `networkstatus.c` which have a lot of things that are dirauth only. Basically, everything that handles vote document should be extracted into the dirauth module, among other things.
The trick is to start looking at `NS_TYPE_VOTE` and `authdir_mode_v3()` to find which part are dirauth only.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25964Remove hs_index_t fetch, and use one of the stores instead2020-06-13T15:25:09ZteorRemove hs_index_t fetch, and use one of the stores insteadSplit off from https://trac.torproject.org/projects/tor/ticket/23094#comment:9
Replying to [#23094:comment:3 asn]:
> After our #23387 refactoring of hsdir index logic Nick suggested that we don't need to keep all 3 around in memory, sin...Split off from https://trac.torproject.org/projects/tor/ticket/23094#comment:9
Replying to [#23094:comment:3 asn]:
> After our #23387 refactoring of hsdir index logic Nick suggested that we don't need to keep all 3 around in memory, since two of them are always identical:
> https://oniongit.eu/asn/tor/merge_requests/6#note_1201
We need to:
* analyse the state machine of fetch, store_first, and store_second to make sure that fetch is always equal to store_first or store_second
* work out the condition that we can use to select betweeen store_first or store_second when we want fetch
* write a function that produces fetch from a hsdir_index_t, and use it instead of fetchTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25839conn: Move connection bandwidth stuff into its own file2020-06-13T15:24:30ZDavid Gouletdgoulet@torproject.orgconn: Move connection bandwidth stuff into its own fileIn connection.c, we have the connection's bw management which means there are lots of functions only dealing with the `global_bucket` and per-connection rw bucket.
We could move all this to its own file like `connection_bw.c` to offload...In connection.c, we have the connection's bw management which means there are lots of functions only dealing with the `global_bucket` and per-connection rw bucket.
We could move all this to its own file like `connection_bw.c` to offload connection.c making it nicer, clearer and more modularized.Tor: unspecified