Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:35:22Zhttps://gitlab.torproject.org/legacy/trac/-/issues/28779Remove double function declarations in circuitpadding.c/test_circuitpadding.c2020-06-13T15:35:22ZGeorge KadianakisRemove double function declarations in circuitpadding.c/test_circuitpadding.cWe can use the STATIC macro to avoid defining every function twice.
We can also rearrange the circuitpadding.c functions so that we don't need to define them on top of the .c file.We can use the STATIC macro to avoid defining every function twice.
We can also rearrange the circuitpadding.c functions so that we don't need to define them on top of the .c file.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28778Rename some circuitpadding structs2020-06-13T15:35:21ZGeorge KadianakisRename some circuitpadding structsSee https://github.com/torproject/tor/pull/461#discussion_r231885343 and https://github.com/torproject/tor/pull/461#discussion_r232343640 for a discussion to rename some of the essential structs of circuitpadding to better reflect their ...See https://github.com/torproject/tor/pull/461#discussion_r231885343 and https://github.com/torproject/tor/pull/461#discussion_r232343640 for a discussion to rename some of the essential structs of circuitpadding to better reflect their semantics.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28777Split circuitpadding.c code into multiple modules2020-06-13T15:35:21ZGeorge KadianakisSplit circuitpadding.c code into multiple modulesCircuitpadding.c is pretty huge and we can split it into further modules.
A possible division could be:
- circuit padding code that deals with network/circuits etc.
- circuit padding code that deals with padding negotiation
- circuit pa...Circuitpadding.c is pretty huge and we can split it into further modules.
A possible division could be:
- circuit padding code that deals with network/circuits etc.
- circuit padding code that deals with padding negotiation
- circuit padding histogram-related code
- circuit padding distribution-related code
- circuit padding machine maintainance codeTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28737Redesign sbws torrc option configuration2020-06-13T16:15:03ZteorRedesign sbws torrc option configurationsbws' torrc option handling is broken.
Here's a better scheme:
1. sbws config.default.ini and config.ini contain the following sections:
* tor.options.launch: a minimal set of options that must be configured when tor is launched. The ...sbws' torrc option handling is broken.
Here's a better scheme:
1. sbws config.default.ini and config.ini contain the following sections:
* tor.options.launch: a minimal set of options that must be configured when tor is launched. The minimal set contains the data directory config, control config, and log config. The network is disabled at launch. The initial options are:
```
'DataDirectory': conf.getpath('tor', 'datadir'),
'PidFile': conf.getpath('tor', 'pid'),
# Because we need things from full server descriptors (namely for now: the
# bandwidth line)
'UseMicrodescriptors': '0',
'ControlSocket': conf.getpath('tor', 'control_socket'),
# Easier than password authentication
'CookieAuthentication': '1',
'Log': [
'NOTICE file {}'.format(os.path.join(conf.getpath('tor', 'log'),
'notice.log')),
],
# useful logging options for clients that don't care about anonymity
'SafeLogging': '0',
'LogTimeGranularity': '1',
'ProtocolWarnings': '1',
'DisableNetwork': '1',
```
* tor.options.runtime.(group_name): Zero or more groups of tor options that can be set at runtime. The network is enabled at runtime. The "50-default" group of options is:
```
# We will find out via the ControlPort and not setting something static
# means a lower chance of conflict
'SocksPort': 'auto',
# To avoid path bias warnings
'UseEntryGuards': '0',
c.set_conf('__LeaveStreamsUnattached', '1')
# Things needed to make circuits fail a little faster. We get the
# circuit_timeout as a string instead of an int on purpose: stem only
# accepts strings.
'LearnCircuitBuildTimeout': '0',
'CircuitBuildTimeout': conf['general']['circuit_timeout'],
'DisableNetwork': '0',
```
* Zero or more tor.runtime.ignore_failure.(group name): tor options that are set in groups at runtime, but ignored if they fail. #28692 and #28694 will add options to this list.
Options in config.ini override options with the same name in sbws.default.ini, with + and / having the same meaning as in a torrc file (+ appends, / removes). Launch options are applied first, then runtime options are applied in group name order. Tor will make later runtime options replace earlier runtime options, and launch options.
2. sbws gets its control socket from the launch_options ControlSocket option(s)
3. sbws gets its data directory, pid, log(s), and circuit build timeout using GETCONF
4. For backwards compatibility:
* if tor.extra_lines is present, it should be appended to tor.options.launch. sbws' option merging code never worked, so appending shouldn't cause any more issues than the existing code.
* if any of these sbws options are present in an old config file, synthesise options.launch from the sbws options. If options.launch is also present in the same config file, it overrides the synthetic options. (sbws' option merging never worked for these options.)
```
'DataDirectory': conf.getpath('tor', 'datadir'),
'PidFile': conf.getpath('tor', 'pid'),
'ControlSocket': conf.getpath('tor', 'control_socket'),
'Log': [
'NOTICE file {}'.format(os.path.join(conf.getpath('tor', 'log'),
'notice.log')),
],
# Things needed to make circuits fail a little faster. We get the
# circuit_timeout as a string instead of an int on purpose: stem only
# accepts strings.
'CircuitBuildTimeout': conf['general']['circuit_timeout'],
```
The final option order is:
* sbws creates options.launch, using the last option from:
* synthetic legacy config options from config.default.ini
* options.launch from config.default.ini
* synthetic legacy config options from config.ini
* options.launch from config.ini
* sbws appends extra_lines to options.launch, using the last extra_lines from:
* config.default.ini
* config.ini
* sbws creates options.runtime groups, using the last one of each group from:
* config.default.ini
* config.ini
sbws launches tor with options.launch, then applies each group of options.runtime in order.
This is a new feature, so it should go in sbws 1.1.sbws: unspecifiedhttps://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/28207Cleanup duplicate and near-duplicate chutney networks2020-06-13T13:30:40ZteorCleanup duplicate and near-duplicate chutney networksThere are a bunch of chutney networks that are duplicates or near-duplicates of each other.
Instead of duplicating code, we could turn the network code into a function, and then call it from all similar networks.There are a bunch of chutney networks that are duplicates or near-duplicates of each other.
Instead of duplicating code, we could turn the network code into a function, and then call it from all similar networks.https://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.org