Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2019-01-04T22:40:03Zhttps://gitlab.torproject.org/legacy/trac/-/issues/28153Nyx memory leaks2019-01-04T22:40:03ZTracNyx memory leaksI had this problem twice. If `nyx` is running more than 1-2 days, it starts to consume more resources (I think, it is RAM). Finally, system becomes very slow and unresponsive until `nyx` (2.0.4 installed using `python3-pip`) is killed by...I had this problem twice. If `nyx` is running more than 1-2 days, it starts to consume more resources (I think, it is RAM). Finally, system becomes very slow and unresponsive until `nyx` (2.0.4 installed using `python3-pip`) is killed by system OOM-killer. This is what I see in `/var/log/messages` after that:
```
Purging GPU memory, 0 bytes freed, XXXXXXX bytes still pinned.
nyx invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
nyx cpuset=/ mems_allowed=0
CPU: 0 PID: XXXXX Comm: nyx Not tainted 3.16.0-7-amd64 #1 Debian [redacted]
Hardware name: [redacted]
0000000000000000 ffffffff81534df4 00000000000201da 0000000000000000
ffffffff81533956 0000000000000000 ffff880099938000 ffffffffa054d5ab
ffff880099950000 01ffffff8115e3d3 ffff880028f59550 ffffffff81730612
Call Trace:
[<ffffffff81534df4>] ? dump_stack+0x5d/0x78
[<ffffffff81533956>] ? dump_header+0x95/0x1fd
[<ffffffffa054d5ab>] ? i915_gem_shrinker_oom+0x15b/0x1c0 [i915]
[<ffffffff8114c20d>] ? oom_kill_process+0x21d/0x370
[<ffffffff8114bdad>] ? find_lock_task_mm+0x3d/0xa0
[<ffffffff8114c9ce>] ? out_of_memory+0x4be/0x4f0
[<ffffffff81153386>] ? __alloc_pages_nodemask+0xca6/0xcf0
[<ffffffff81193bd6>] ? alloc_pages_current+0xa6/0x160
[<ffffffff8114ae9c>] ? filemap_fault+0x1bc/0x440
[<ffffffff81172430>] ? __do_fault+0x40/0xc0
[<ffffffff811769eb>] ? handle_mm_fault+0xf2b/0x15b0
[<ffffffff8105b6cb>] ? __do_page_fault+0x1ab/0x470
[<ffffffff810dd5c3>] ? SyS_futex+0x73/0x170
[<ffffffff8153d058>] ? page_fault+0x28/0x30
```
Tor is configured as client only. It is neither a relay nor an onion service.
**Trac**:
**Username**: wagonDamian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/28294Nyx crashes at graph resizing2018-11-05T17:10:28ZTracNyx crashes at graph resizingNyx (2.0.4 installed using `python3-pip`) has reproducible crash if the following is done:
1. Press `g` for graph resizing.
2. Press `down arrow` many times until `Events` sub-window will be completely hidden.
3. Nyx crashes with the fo...Nyx (2.0.4 installed using `python3-pip`) has reproducible crash if the following is done:
1. Press `g` for graph resizing.
2. Press `down arrow` many times until `Events` sub-window will be completely hidden.
3. Nyx crashes with the following log:
```
Traceback (most recent call last):
File "/usr/local/bin/nyx", line 9, in <module>
load_entry_point('nyx==2.0.4', 'console_scripts', 'nyx')()
File "/usr/local/lib/python3.4/dist-packages/nyx/__init__.py", line 176, in main
nyx.starter.main()
File "/usr/local/lib/python3.4/dist-packages/stem/util/conf.py", line 289, in wrapped
return func(*args, config = config, **kwargs)
File "/usr/local/lib/python3.4/dist-packages/nyx/starter.py", line 118, in main
nyx.curses.start(nyx.draw_loop, acs_support = config.get('acs_support', True), transparent_background = True, cursor = False)
File "/usr/local/lib/python3.4/dist-packages/nyx/curses.py", line 217, in start
curses.wrapper(_wrapper)
File "/usr/lib/python3.4/curses/__init__.py", line 94, in wrapper
return func(stdscr, *args, **kwds)
File "/usr/local/lib/python3.4/dist-packages/nyx/curses.py", line 215, in _wrapper
function()
File "/usr/local/lib/python3.4/dist-packages/nyx/__init__.py", line 243, in draw_loop
keybinding.handle(key)
File "/usr/local/lib/python3.4/dist-packages/nyx/panel/__init__.py", line 84, in handle
self._action()
File "/usr/local/lib/python3.4/dist-packages/nyx/panel/graph.py", line 504, in _resize_graph
nyx_interface().redraw()
File "/usr/local/lib/python3.4/dist-packages/nyx/__init__.py", line 716, in redraw
panel.redraw(force = force, top = occupied)
File "/usr/local/lib/python3.4/dist-packages/nyx/panel/__init__.py", line 175, in redraw
self._last_draw_size = nyx.curses.draw(self._draw, top = self._top, height = self.get_height(), draw_if_resized = draw_dimension)
File "/usr/local/lib/python3.4/dist-packages/nyx/curses.py", line 740, in draw
curses_subwindow = CURSES_SCREEN.subwin(subwindow_height, subwindow_width, top, left)
_curses.error: curses function returned NULL
```
**Trac**:
**Username**: wagonDamian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/28295Non-interactive way to supply ControlPort password for nyx and tor-prompt is ...2019-01-06T05:43:05ZTracNon-interactive way to supply ControlPort password for nyx and tor-prompt is neededWhen Tor's `ControlPort` requires password authentication, `nyx` and `tor-prompt` ask it interactively. However, it must be also a way to specify the password in a command line or in config file. Earlier it was possible with `arm`'s opti...When Tor's `ControlPort` requires password authentication, `nyx` and `tor-prompt` ask it interactively. However, it must be also a way to specify the password in a command line or in config file. Earlier it was possible with `arm`'s option `startup.controlPassword`, which no longer works with `nyx`.
**Trac**:
**Username**: wagonDamian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/28296Nyx shows wrong IP address for ControlPort connection2019-01-10T08:07:58ZTracNyx shows wrong IP address for ControlPort connectionNyx (2.0.4 installed using `python3-pip`) connects to Tor's `ControlPort` through `127.0.0.1:9051`, but in the window with circuit and other connections it shows
`127.0.0.1:PORT (??) --> REAL_IP_ADDRESS:9051 nyx (XXX) + 1.8m (CON...Nyx (2.0.4 installed using `python3-pip`) connects to Tor's `ControlPort` through `127.0.0.1:9051`, but in the window with circuit and other connections it shows
`127.0.0.1:PORT (??) --> REAL_IP_ADDRESS:9051 nyx (XXX) + 1.8m (CONTROL)`
where `REAL_IP_ADDRESS` is a real source IP for outgoing Tor packets to Internet. In this setup Tor is not listening at `REAL_IP_ADDRESS:9051`, i.e. `nyx`'s information is confusing. Instead of real IP `127.0.0.1` must be written:
`127.0.0.1:PORT (??) --> 127.0.0.1:9051 nyx (XXX) + 1.8m (CONTROL)`
**Trac**:
**Username**: wagonDamian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/28297Control interpreter in nyx does not do line splitting2019-01-04T23:09:49ZTracControl interpreter in nyx does not do line splittingWhen `GETINFO circuit-status` is typed in control interpreter of `nyx` (2.0.4), long lines are not split. Therefore, full `tor`'s reply cannot be seen. It looks like (names of Tor nodes are fake):
```
>>> GETINFO circuit-status
250+circ...When `GETINFO circuit-status` is typed in control interpreter of `nyx` (2.0.4), long lines are not split. Therefore, full `tor`'s reply cannot be seen. It looks like (names of Tor nodes are fake):
```
>>> GETINFO circuit-status
250+circuit-status=
XXXX BUILT $FINGERPRINT~NODENAME,$FINGERPRINT~nodeone,$FINGE
XXXX BUILT $FINGERPRINT~NODENAME,$FINGERPRINT~nodetwotwo2,$F
XXXX BUILT $FINGERPRINT~NODENAME,$FINGERPRINT~node11,$FINGER
XXXX BUILT $FINGERPRINT~NODENAME,$FINGERPRINT~nodethree1,$FI
XXXX BUILT $FINGERPRINT~NODENAME,$FINGERPRINT~tnode,$FINGERP
XXXX BUILT $FINGERPRINT~NODENAME,$FINGERPRINT~Unnamed,$FINGE
XXXX BUILT $FINGERPRINT~NODENAME,$FINGERPRINT~anothernode,$F
XXXX BUILT $FINGERPRINT~NODENAME,$FINGERPRINT~nodenew2,$FING
.
250 OK
```
Other commands which output long lines may also have this problem.
Interestingly, contrary to `nyx`, `tor-prompt` do line splitting correctly.
**Trac**:
**Username**: wagonDamian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/28299Custom colors for Nyx and tor-prompt are needed2019-01-02T00:35:11ZTracCustom colors for Nyx and tor-prompt are neededIf `color_interface true` is selected for Nyx, some elements are highlighted, but their colors cannot be changed. It would be good to add `nyxrc` options for custom colors. `tor-prompt` also needs config options to select colors.
**Trac...If `color_interface true` is selected for Nyx, some elements are highlighted, but their colors cannot be changed. It would be good to add `nyxrc` options for custom colors. `tor-prompt` also needs config options to select colors.
**Trac**:
**Username**: wagonDamian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/28300Scrolling support for tor-prompt is needed2019-03-03T09:10:29ZTracScrolling support for tor-prompt is neededControl Interpreter of Nyx has very convenient type of scrolling, where ESC allows us to scroll buffer using `up`/`down` arrows, `PageUp`/`PageDown`, and `Home`/`End` keys. Though scrolling can be done with the help of terminal itself or...Control Interpreter of Nyx has very convenient type of scrolling, where ESC allows us to scroll buffer using `up`/`down` arrows, `PageUp`/`PageDown`, and `Home`/`End` keys. Though scrolling can be done with the help of terminal itself or with the help of some environments such as `screen`, it would be convenient to have Nyx-like scrolling working also in `tor-prompt`.
**Trac**:
**Username**: wagonDamian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/28332Nyx configurashion editor reproducibly crashes if custom ordering is set2018-11-07T17:54:45ZTracNyx configurashion editor reproducibly crashes if custom ordering is setNyx 2.0.4 at Linux. How to reproduce:
1. Go to configuration editor.
2. Press `s` and select the following order: `Is Set`, `Name`, `Description`.
3. "Toggle filtering" by pressing `a`.
4. Nyx immediately crashes with the followi...Nyx 2.0.4 at Linux. How to reproduce:
1. Go to configuration editor.
2. Press `s` and select the following order: `Is Set`, `Name`, `Description`.
3. "Toggle filtering" by pressing `a`.
4. Nyx immediately crashes with the following log:
```
Traceback (most recent call last):
File "/usr/local/bin/nyx", line 9, in <module>
load_entry_point('nyx==2.0.4', 'console_scripts', 'nyx')()
File "/usr/local/lib/python3.4/dist-packages/nyx/__init__.py", line 176, in main
nyx.starter.main()
File "/usr/local/lib/python3.4/dist-packages/stem/util/conf.py", line 289, in wrapped
return func(*args, config = config, **kwargs)
File "/usr/local/lib/python3.4/dist-packages/nyx/starter.py", line 118, in main
nyx.curses.start(nyx.draw_loop, acs_support = config.get('acs_support', True), transparent_background = True, cursor = False)
File "/usr/local/lib/python3.4/dist-packages/nyx/curses.py", line 217, in start
curses.wrapper(_wrapper)
File "/usr/lib/python3.4/curses/__init__.py", line 94, in wrapper
return func(stdscr, *args, **kwds)
File "/usr/local/lib/python3.4/dist-packages/nyx/curses.py", line 215, in _wrapper
function()
File "/usr/local/lib/python3.4/dist-packages/nyx/__init__.py", line 243, in draw_loop
keybinding.handle(key)
File "/usr/local/lib/python3.4/dist-packages/nyx/panel/__init__.py", line 84, in handle
self._action()
File "/usr/local/lib/python3.4/dist-packages/nyx/panel/config.py", line 258, in _toggle_show_all
self._sort_content()
File "/usr/local/lib/python3.4/dist-packages/nyx/panel/config.py", line 325, in _sort_content
self._all_content = sorted(self._all_content, key = lambda entry: [entry.sort_value(field) for field in self._sort_order])
File "/usr/local/lib/python3.4/dist-packages/nyx/panel/config.py", line 325, in <lambda>
self._all_content = sorted(self._all_content, key = lambda entry: [entry.sort_value(field) for field in self._sort_order])
File "/usr/local/lib/python3.4/dist-packages/nyx/panel/config.py", line 325, in <listcomp>
self._all_content = sorted(self._all_content, key = lambda entry: [entry.sort_value(field) for field in self._sort_order])
File "/usr/local/lib/python3.4/dist-packages/nyx/panel/config.py", line 128, in sort_value
return self.description
File "/usr/local/lib/python3.4/dist-packages/nyx/panel/config.py", line 148, in description
return getattr(manual(self.name), 'description')
AttributeError: 'NoneType' object has no attribute 'description'
```
I guess it would also crash with many other types of ordering.
**Trac**:
**Username**: wagonDamian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/28334Text fields wider than the screeen cropped2019-12-21T22:25:20ZTracText fields wider than the screeen croppedNyx 2.0.4 at Linux.
The first problem exist with all options: if I select some option, then press `Enter` (so, start editing it), and then press `ESC`, all old values for the option are erased (value becomes `none`). This behavior confu...Nyx 2.0.4 at Linux.
The first problem exist with all options: if I select some option, then press `Enter` (so, start editing it), and then press `ESC`, all old values for the option are erased (value becomes `none`). This behavior confuses users, because normally `ESC` should keep old version of values. To my opinion, if I really need to make it `none` I should manually remove old values (or press `ctrl+u`) and then press `Enter`.
The second problem exist with options which have very long list of values. For example, you can consider `torrc` with a long list of `SocksPort` options or a long list of values for `ExcludeNodes` option. If you select such option in configuration editor (press `Enter`), only the first part of values' list will be shown. Other lengthy part of values list will not be printed and will not be accessible for editing (it is considered as non-existing). I guess it is related to the problem of line splitting ([[https://trac.torproject.org/projects/tor/ticket/28297|#28297]]). Since the first part of accessible values may end at any character (when end of line is reached), if I don't do anything, but just print `Enter`, I may get an error
`Unacceptable option value: Invalid SocksPort configuration (press any key)`
As `nyx` gives to Tor wrong option values, there are many warnings in a log file of `tor` itself, e.g.:
`Controller gave us config lines that didn't validate: Invalid SocksPort configuration`
Thus, if you accidentally press `Enter` on any option with too long list of values, you get trapped in inescapable situation: `ESC` will erase all old values, `Enter` will change them too (possibly with some errors). It is impossible to preserve status quo.
**Trac**:
**Username**: wagonDamian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/28356DataDirectoryGroupReadable and CacheDirectoryGroupReadable conflicts forcing ...2020-06-13T15:33:52ZTracDataDirectoryGroupReadable and CacheDirectoryGroupReadable conflicts forcing sandboxed Tor to crash== Problem 1
By default `DataDirectory` and `CacheDirectory` is the same. On Debian it is `/var/lib/tor`. If you set `DataDirectoryGroupReadable 1` in `torrc` (and forget about `CacheDirectoryGroupReadable`) and then restart Tor, you ex...== Problem 1
By default `DataDirectory` and `CacheDirectory` is the same. On Debian it is `/var/lib/tor`. If you set `DataDirectoryGroupReadable 1` in `torrc` (and forget about `CacheDirectoryGroupReadable`) and then restart Tor, you expect granting permissions to this directory. However, Tor will not do that, but change `drwx--S---` permission to `drwx------` for this directory (which is itself not logical---removing permissions instead of granting them). Tor will also issue a warning:
```
[warn] Fixing permissions on directory /var/lib/tor
```
Later this warning will be repeated at each startup of Tor. I think that this warning should be improved, e.g.:
```
[warn or err] DataDirectoryGroupReadable and CacheDirectoryGroupReadable links to the same directory. You have to set both of them to 1 of both of them to 0.
```
Maybe you have another suggestion (e.g., if any of these options is 1, another is 1 too). `man torrc` doesn't tell anything about this conflict. It should be addressed in man page too.
== Problem 2
The situation is worse when your `torrc` has `Sandbox` enabled:
```
DataDirectoryGroupReadable 1
CacheDirectoryGroupReadable 1
Sandbox 1
```
In this case Tor successfully starts, but if you issue `SIGNAL RELOAD` command (e.g., using `tor-prompt`), Tor immediately crashes with the log:
```
============================================================ T= XXXXXXXXXX
(Sandbox) Caught a bad syscall attempt (syscall chmod)
/usr/bin/tor(+0x1a4d66)[0x556326474d66]
/lib/x86_64-linux-gnu/libc.so.6(chmod+0x7)[0x7f63c91b4807]
/lib/x86_64-linux-gnu/libc.so.6(chmod+0x7)[0x7f63c91b4807]
/usr/bin/tor(+0xfafed)[0x5563263cafed]
/usr/bin/tor(set_options+0x2ed)[0x5563263d42dd]
/usr/bin/tor(options_init_from_string+0x4c7)[0x5563263d6d97]
/usr/bin/tor(options_init_from_torrc+0x471)[0x5563263d72f1]
/usr/bin/tor(+0x55531)[0x556326325531]
/usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0xe35)[0x7f63ca776a15]
/usr/bin/tor(do_main_loop+0x25f)[0x556326325e3f]
/usr/bin/tor(tor_run_main+0x1165)[0x556326328315]
/usr/bin/tor(tor_main+0x3a)[0x55632632032a]
/usr/bin/tor(main+0x19)[0x556326320099]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f63c90fab45]
/usr/bin/tor(+0x500e9)[0x5563263200e9]
```
Should `Sandbox` be in conflict with these option? If yes, this should be documented in man page, and Tor has to complain an error during startup.
== Problem 3
Suppose, you disable `Sandbox`, but keep the options `DataDirectoryGroupReadable` and `CacheDirectoryGroupReadable` in place. During start Tor sets directory permissions to `drwxr-x---` allowing `debian-tor` group to list files.
If you later grant read access to any file in this directory, Tor will remove this access soon. E.g., `state` file loses its group read permission at each Tor's startup. Other files may lose it less frequently. We are trapped in the situation where `DataDirectoryGroupReadable` and `CacheDirectoryGroupReadable` are useless: what's the goal to be able to read directory's content, bit be unable to read any file inside it?
Earlier it was in less conflict with different tools which control Tor, because it was recommended to run each tool on behalf of `debian-tor` user. Now it is recommended to run it from another user who is a member of `debian-tor` group (see discussion in [[https://trac.torproject.org/projects/tor/ticket/25890|#25890]]), but "group approach" also fails...
**Trac**:
**Username**: wagonTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28358Nyx forces Tor error: sandbox_getaddrinfo(): Bug: (Sandbox) failed to get add...2020-06-13T15:33:53ZTracNyx forces Tor error: sandbox_getaddrinfo(): Bug: (Sandbox) failed to get addressIf `Sandbox 1` is set in `torrc`, Nyx (both stable 2.0.4 and [[version](https://trac.torproject.org/projects/tor/ticket/28332#comment:7|git)]) makes Tor write the error in log file:
```
[err] sandbox_getaddrinfo(): Bug: (Sandbox) failed...If `Sandbox 1` is set in `torrc`, Nyx (both stable 2.0.4 and [[version](https://trac.torproject.org/projects/tor/ticket/28332#comment:7|git)]) makes Tor write the error in log file:
```
[err] sandbox_getaddrinfo(): Bug: (Sandbox) failed to get address [hostname redacted]! (on Tor 0.3.4.9 )
```
This is always written only once, during startup of Nyx.
atagar [[https://trac.torproject.org/projects/tor/ticket/28300#comment:5|suggested]] me to file this ticket. He assumes that the bug is on Tor's side:
> It sounds like simply calling `GETINFO address` causes its sandboxing code to issue a bug warning. This is either uncovering a bug on their side or this log message should be downgraded (i.e., not err runlevel or say it's a Tor bug).
**Trac**:
**Username**: wagonTor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28361Allow few nodes-list options in torrc2020-06-13T15:33:54ZTracAllow few nodes-list options in torrcThere are many options in `torrc` which accept lists of nodes, countries, etc.:
```
ExcludeNodes node,node,...
ExcludeExitNodes node,node,...
ExitNodes node,node,...
EntryNodes node,node,...
NodeFamily node,node,...
Tor2webRendezvousPoi...There are many options in `torrc` which accept lists of nodes, countries, etc.:
```
ExcludeNodes node,node,...
ExcludeExitNodes node,node,...
ExitNodes node,node,...
EntryNodes node,node,...
NodeFamily node,node,...
Tor2webRendezvousPoints node,node,...
HSLayer2Nodes node,node,...
HSLayer3Nodes node,node,...
TestingDirAuthVoteExit node,node,...
TestingDirAuthVoteGuard node,node,...
TestingDirAuthVoteHSDir node,node,...
```
Maybe I have not list all of them. Values for these options may be very long lists. It would be very convenient to write it as, e.g.:
```
ExcludeNodes node0,nodeX
ExcludeNodes node1
ExcludeNodes node2
ExcludeNodes node3,nodeY,nodeZ
```
I cannot see any reason why only one such option can be specified in `torrc`. It makes management of long lists very hard, because one needs to add `\` symbols, take into account some restrictions on comments within these lists, etc.
**Trac**:
**Username**: wagonTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28363Make a torrc option which prevents Tor from falling asleep2020-06-13T15:33:55ZTracMake a torrc option which prevents Tor from falling asleepNow, if Tor client doesn't see any activity within certain period of time on its `SocksPort`, it closes all circuits and disconnects from Internet. This may lead to troubles with some ISPs, where manual intervention is needed to connect ...Now, if Tor client doesn't see any activity within certain period of time on its `SocksPort`, it closes all circuits and disconnects from Internet. This may lead to troubles with some ISPs, where manual intervention is needed to connect to Internet again. It would be good to have an option which allows users to specify this period of inactivity manually (so it can be set to some big value), or an option which disables this behavior completely.
**Trac**:
**Username**: wagonTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28642Tor browser cannot connect to SOCKS server if it is not specified by IP address2020-06-16T00:58:42ZTracTor browser cannot connect to SOCKS server if it is not specified by IP addressI have tor running at another host with IP 10.0.0.1. It is accessible by tor-browser running on 10.0.0.2 via network connection. In TBB 8.0.3, if I put in `/path/to/Browser/TorBrowser/Data/Browser/profile.default/user.js` an option
```
u...I have tor running at another host with IP 10.0.0.1. It is accessible by tor-browser running on 10.0.0.2 via network connection. In TBB 8.0.3, if I put in `/path/to/Browser/TorBrowser/Data/Browser/profile.default/user.js` an option
```
user_pref("network.proxy.socks", "10.0.0.1");
```
it works fine. However, if I put
```
user_pref("network.proxy.socks", "myproxy");
```
where `myproxy` is added to `/etc/hosts` as `10.0.0.1 myproxy`, tor-browser cannot connect. Original firefox 60.3.0 (8.0.3 is based on this version) works fine if proxy is specified as `myproxy`. Is it a feature or bug? Do we have some workaround for this?
**Trac**:
**Username**: wagonhttps://gitlab.torproject.org/legacy/trac/-/issues/28675Deprecate standard cookie authentication2020-06-13T15:34:59ZTracDeprecate standard cookie authenticationAccording to Tor [[https://gitweb.torproject.org/torspec.git/tree/control-spec.txt|specs]], cookie authentication is deprecated:
> the COOKIE authentication method has been deprecated and will be removed from a future version of Tor.
...According to Tor [[https://gitweb.torproject.org/torspec.git/tree/control-spec.txt|specs]], cookie authentication is deprecated:
> the COOKIE authentication method has been deprecated and will be removed from a future version of Tor.
Now standard applications such as tor-browser and stem/Nyx use safecookie mechanism. If somebody needs to authenticate with safecookie at commandline, it can be done [[https://trac.torproject.org/projects/tor/ticket/28295#comment:7|too]].
As intermediate step before complete removal of standard cookie authentication I suggest to add a `torrc` option which disables it by default (e.g. `DisableStandardCookieAuthentication 1`). If some old application still needs it, this option can be changed to 0.
It was discussed [[https://trac.torproject.org/projects/tor/ticket/28295#comment:7|here]] in relation to Nyx.
**Trac**:
**Username**: wagonTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28676Tor versions of Tor nodes should be accessible through ControlPort2020-06-13T15:35:00ZTracTor versions of Tor nodes should be accessible through ControlPortIf extra `torrc` options (such as `FetchUselessDescriptors`) are not used, Tor's `ControlPort` commands `GETINFO ns/id/FINGERPINT` and `GETINFO ns/name/nickname` do not print Tor versions of the corresponding nodes. Their versions still ...If extra `torrc` options (such as `FetchUselessDescriptors`) are not used, Tor's `ControlPort` commands `GETINFO ns/id/FINGERPINT` and `GETINFO ns/name/nickname` do not print Tor versions of the corresponding nodes. Their versions still can be read from a file `/var/lib/tor/cached-microdesc-consensus` (lines `v Tor x.x.x.x`) directly, but I cannot see any reason why applications cannot learn them from `ControlPort` too. Also, I didn't find other `ControlPort` commands which print these Tor versions.
This problem [[disccused](https://trac.torproject.org/projects/tor/ticket/28300#comment:4|was)] in relation to Nyx:
> Inverse situation is with Tor version: it is shown in `/var/lib/tor/cached-microdesc-consensus` but Nyx does not show it in information about relays (connections window). Can relay's Tor version be learned from `ControlPort` too?
**Trac**:
**Username**: wagonTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28682Carml lacks PGP singatures and instructions for secure installation2018-12-17T09:13:13ZTracCarml lacks PGP singatures and instructions for secure installationMeejah's carml isn't listed as officially supported by Tor Project, but meejah is somehow listed among Tor people and carml itself is officially [[https://blog.torproject.org/exploring-tor-carml|advertised]] in Tor blog. So, I suppose th...Meejah's carml isn't listed as officially supported by Tor Project, but meejah is somehow listed among Tor people and carml itself is officially [[https://blog.torproject.org/exploring-tor-carml|advertised]] in Tor blog. So, I suppose this ticket can be accepted here.
== Problem 1: no signatures
Correct me if I'm wrong. There are no PGP signatures of [[releases](https://github.com/meejah/carml/releases|carml)] anywhere at [[pages](https://carml.readthedocs.io/en/latest/releases.html|project)] (however, txtorcon library is signed).
== Problem 2: no python3 docs
[[on installation](https://carml.readthedocs.io/en/latest/installation.html|Documentation)] is written for python2 instead of python3. However, support of python3 is claimed. In particular, there is no `virtualenv` command for python3, as `pyvenv` [[used](https://askubuntu.com/questions/279959/how-to-create-a-virtualenv-with-python3-3-in-ubuntu|is)] instead.
== Problem 3: no secure installation of carml dependencies
`pip install <projectname>` with automatic download of all dependencies from repository, as recommended in documentation, should never be used in secure environments, because packages in this repository are not signed (even if they are signed, their signatures are not checked by default). Actually, some dependencies (probably, old versions) can be installed as standard Debian packages, but `pip` will not be able to see them by default (especially in `pyvenv` environment). There is only one way to install it securely:
1. Download carml bunndle and its signature.
2. Download bundles for **all** carml dependencies and their signatures.
3. Verify signatures of all downloaded bundles manually (don't ask me what to do if somebody release his code without signatures).
4. Disconnect from network.
5. Install carml and its dependencies as `pip install /path/to/local-bundle`
6. Create some symlinks, so carml can find all dependencies it needs.
This is what I expect to see in documentation. For instance, for Nyx it was done [[so](https://trac.torproject.org/projects/tor/ticket/28332#comment:7|exactly)] (but it has only one dependence, Stem):
1. Download Nyx, its signature, and verify it.
2. Download Stem, its signature, and verify it.
3. Install Stem, install Nyx, create necessary symlink.
As a workaround I'ld suggest to put all necessary dependencies in signed carml bundle, so users will not suffer during assembling of this constructor.
**Trac**:
**Username**: wagonmeejahmeejahhttps://gitlab.torproject.org/legacy/trac/-/issues/28757Remove deprecated ControlPort commands from GETINFO info/names listing2020-06-13T15:35:19ZTracRemove deprecated ControlPort commands from GETINFO info/names listingIf `GETINFO` commands `status/version/num-concurring` and `status/version/num-versioning` are used in Nyx or `tor-prompt`, Tor writes to its log file:
```
[warn] status/version/num-concurring is deprecated; it no longer gives useful inf...If `GETINFO` commands `status/version/num-concurring` and `status/version/num-versioning` are used in Nyx or `tor-prompt`, Tor writes to its log file:
```
[warn] status/version/num-concurring is deprecated; it no longer gives useful information
[warn] status/version/num-versioning is deprecated; it no longer gives useful information
```
These commands should be removed from interpreter's `/help GETINFO` listing. They are deprecated according to [[https://gitweb.torproject.org/torspec.git/tree/control-spec.txt|control-spec.txt]]:
```
"status/version/num-concurring"
"status/version/num-versioning"
These options are deprecated; they no longer give useful information.
```
[[0.2.0.30](https://blog.torproject.org/tor-02030-released-stable|since)] (more than 10 years):
> o Newly deprecated features:
> - The `status/version/num-versioning` and `status/version/num-concurring` `GETINFO` controller options are no longer useful in the v3 directory protocol: treat them as deprecated, and warn when they're used.
Probably, there are also other deprecated commands in `/help` listing. They should be removed too.
P.S. Initially it was reported in [[comment](https://trac.torproject.org/projects/tor/ticket/28300#comment:4|this)]. teor [[http://ea5faa5po25cf7fb.onion/projects/tor/ticket/28676#comment:8|recommended]] to create separate ticket.
**Trac**:
**Username**: wagonTor: 0.4.0.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/28760Option/* format for ControlPort options needs to be homogeneous2020-06-13T15:35:19ZTracOption/* format for ControlPort options needs to be homogeneousAccording to [[https://gitweb.torproject.org/torspec.git/tree/control-spec.txt|control-spec.txt]]:
> The OptionPrefix form indicates a number of options beginning with the prefix. So if `config/*` is listed, other options beginning with...According to [[https://gitweb.torproject.org/torspec.git/tree/control-spec.txt|control-spec.txt]]:
> The OptionPrefix form indicates a number of options beginning with the prefix. So if `config/*` is listed, other options beginning with `config/` will work, but `config/*` itself is not an option.
In Nyx and `tor-prompt` interpreters' `/help`, if the format `Option/*` is used to name a group of options (each of them is still described separately), it must be done for everything. However, e.g., we have many options inside `accounting`, but key `accounting/*` doesn't exist:
```
accounting/bytes - Number of bytes read/written so far in the accounting interval.
accounting/bytes-left - Number of bytes left to write/read so far in the accounting interval.
accounting/enabled - Is accounting currently enabled?
accounting/hibernating - Are we hibernating or awake?
accounting/interval-end - Time when the accounting period ends.
accounting/interval-start - Time when the accounting period starts.
accounting/interval-wake - Time to wake up in this accounting period.
```
Compare it with:
```
config/* - Current configuration values.
config/defaults - List of default values for configuration options. See also config/names
config/names - List of configuration options, types, and documentation.
```
If grouping syntax is used, it should be used everywhere (for all groups) or nowhere. Otherwise, it is confusing, because for many other options the syntax `option/*` implies that something not listed here (in list of options) should be substituted (e.g. fingerprint of a relay, IP address, etc.).
P.S. At first glance it looks like Nyx controller interpreter's bug, but atagar [[https://trac.torproject.org/projects/tor/ticket/28300#comment:5|says]] that it is taken literally from `control-spec.txt`. Initially it was reported in [[comment](https://trac.torproject.org/projects/tor/ticket/28300#comment:6|this)]. Separate ticket was created because of [[suggestion](https://trac.torproject.org/projects/tor/ticket/28676#comment:8|teor's)].
**Trac**:
**Username**: wagonTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28805ControlPort has undocumented behavior2020-06-16T01:13:04ZTracControlPort has undocumented behavior== Problem 1
`ControlPort`'s value can be set to address:port though `man torrc` says that only port can be specified.
== Problem 2
Option `ControlPort` can be set few times to bind to different "address:port"s. This is also not docum...== Problem 1
`ControlPort`'s value can be set to address:port though `man torrc` says that only port can be specified.
== Problem 2
Option `ControlPort` can be set few times to bind to different "address:port"s. This is also not documented. Other options which can be set multiple times are explicitly documented with a statement like
```
This directive can be specified multiple times to bind to multiple addresses/ports
```
for `SocksPort`.
Original comment about these issues is [[http://ea5faa5po25cf7fb.onion/projects/tor/ticket/28676#comment:15|here]].
**Trac**:
**Username**: wagonTor: 0.4.0.x-final