Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:35:45Zhttps://gitlab.torproject.org/legacy/trac/-/issues/28877'GETINFO desc/fingerprints' command to get known relays2020-06-13T15:35:45ZTrac'GETINFO desc/fingerprints' command to get known relaysIf `UseMicrodescriptors` is set to 0 in Tor client, the command `GETINFO desc/all-recent` returns very huge listing which interpreter cannot manage properly. If amount of memory is big, after finishing this command Nyx starts to response...If `UseMicrodescriptors` is set to 0 in Tor client, the command `GETINFO desc/all-recent` returns very huge listing which interpreter cannot manage properly. If amount of memory is big, after finishing this command Nyx starts to response slowly on any keyboard input everywhere and in all its windows, not only in interpreter window (restart of Nyx helps). If amount of resources is not that big, it may crash with the following log (I tired to kill it, because my operating system hanged):
```
Traceback (most recent call last):
File "/path/to/nyx_git/nyx/run_nyx", line 14, in <module>
nyx.main()
File "/path/to/nyx_git/nyx/nyx/__init__.py", line 177, in main
nyx.starter.main()
File "/path/to/nyx_git/nyx/stem/util/conf.py", line 289, in wrapped
return func(*args, config = config, **kwargs)
File "/path/to/nyx_git/nyx/nyx/starter.py", line 122, in main
nyx.curses.halt()
File "/path/to/nyx_git/nyx/nyx/curses.py", line 565, in halt
with CURSES_LOCK:
File "/usr/lib/python2.7/threading.py", line 168, in acquire
me = _get_ident()
KeyboardInterrupt
Exception in thread Event notifier (most likely raised during interpreter shutdown):Exception in thread Tor listener (most likely raised during interpreter shutdown):
Traceback (most recent call last):
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
File "/usr/lib/python2.7/threading.py", line 763, in run
File "/path/to/nyx_git/nyx/stem/control.py", line 978, in _event_loop File "/usr/lib/python2.7/threading.py", line 763, in run
<type 'exceptions.AttributeError'>: 'NoneType' object has no attribute 'Empty'
File "/path/to/nyx_git/nyx/stem/control.py", line 947, in _reader_loop
<type 'exceptions.AttributeError'>: 'NoneType' object has no attribute 'ControllerError'
```
Nyx version is [[one](http://ea5faa5po25cf7fb.onion/projects/tor/ticket/28332#comment:7|this)].
**Trac**:
**Username**: wagonTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28812Duplicates of nodes descriptors can be found in consensus files2020-06-13T15:35:30ZTracDuplicates of nodes descriptors can be found in consensus filesSometimes file `cached-microdesc-consensus` contains duplicates of some Tor nodes which differ only by keys. For example, today (Mon Dec 10 17:17:29 UTC 2018) I saw these duplicates:
```
r Petibonum KDU6jCRTrb2O4BRxMMRdnGegVNc 2018-12-1...Sometimes file `cached-microdesc-consensus` contains duplicates of some Tor nodes which differ only by keys. For example, today (Mon Dec 10 17:17:29 UTC 2018) I saw these duplicates:
```
r Petibonum KDU6jCRTrb2O4BRxMMRdnGegVNc 2018-12-10 15:21:54 92.137.2.39 443 8080
m pEBO+WeONS3MuvMCPHWM1QOJiMGVWjTucOdGHMmBRNc
s Running V2Dir Valid
v Tor 0.2.9.16
pr Cons=1-2 Desc=1-2 DirCache=1 HSDir=1 HSIntro=3 HSRend=1-2 Link=1-4 LinkAuth=1 Microdesc=1-2 Relay=1-2
w Bandwidth=0 Unmeasured=1
r Petibonum bwz/Y5pp8y6UH51RU28xDghyqrc 2018-12-10 15:44:54 92.137.2.39 443 8080
m +Zq4u8cRhLR4ry1bEPidvOtULBP/PCAsioLRZnRa1gQ
s Running V2Dir Valid
v Tor 0.2.9.16
pr Cons=1-2 Desc=1-2 DirCache=1 HSDir=1 HSIntro=3 HSRend=1-2 Link=1-4 LinkAuth=1 Microdesc=1-2 Relay=1-2
w Bandwidth=95
```
Is it a bug? Now [[node](https://metrics.torproject.org/rs.html#details/28353A8C2453ADBD8EE0147130C45D9C67A054D7|this)] is out of consensus.
**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-finalhttps://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/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/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/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/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/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/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/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/28921tor-prompt command 'GETINFO desc/all-recent > /dev/null' fails2019-06-17T15:46:29ZTractor-prompt command 'GETINFO desc/all-recent > /dev/null' failsIf redirection is used, it fails:
```
$ tor-prompt --run 'GETINFO desc/all-recent' 1>/dev/null
Traceback (most recent call last):
File "/path/to/stem/tor-prompt", line 8, in <module>
stem.interpreter.main()
File "/path/to/stem/st...If redirection is used, it fails:
```
$ tor-prompt --run 'GETINFO desc/all-recent' 1>/dev/null
Traceback (most recent call last):
File "/path/to/stem/tor-prompt", line 8, in <module>
stem.interpreter.main()
File "/path/to/stem/stem/interpreter/__init__.py", line 151, in main
interpreter.run_command(args.run_cmd, print_response = True)
File "/path/to/stem/stem/util/conf.py", line 289, in wrapped
return func(*args, config = config, **kwargs)
File "/path/to/stem/stem/interpreter/commands.py", line 381, in run_command
print(output)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u021b' in position 1237805: ordinal not in range(128)
```
If redirection is not used, it works.
I think atagar is right in his comment:
> I suspect the issue is that you're using python3, and that `tor-prompt` is using `print()` which expect unicode. Server descriptors can have non-ascii content on contact lines which can cause the stacktrace you cited above.
> I probably need to add some escaping within `tor-prompt`.
**Trac**:
**Username**: wagonDamian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/28902GETINFO commands with huge outputs slow down interpreter curses interface2019-01-06T05:12:12ZTracGETINFO commands with huge outputs slow down interpreter curses interfaceIf you go to Nyx interpreter, run some commands, then press ESC and arrow up, you see that scrolling back in history is very fast and smooth.
Now do the following:
1. Run `GETINFO desc/all-recent` command 3 times to get very huge output...If you go to Nyx interpreter, run some commands, then press ESC and arrow up, you see that scrolling back in history is very fast and smooth.
Now do the following:
1. Run `GETINFO desc/all-recent` command 3 times to get very huge output.
2. Press ESC and then press HOME to get at the top of scroll buffer.
3. Press arrow up and arrow down keys many times to scroll up/down.
4. Press ENTER to return to command interface.
5. Run some command with small output, e.g. `GETINFO info/names`.
6. Press ESC and try to scroll few lines up by pressing arrow up many times.
You will see that scrolling is very slow. You need few seconds to scroll just few lines up in the buffer.
Nyx version is [[one](http://ea5faa5po25cf7fb.onion/projects/tor/ticket/28332#comment:7|this)]. The ticket is filed by atagar's [[http://ea5faa5po25cf7fb.onion/projects/tor/ticket/28877#comment:3|request]]:
> I suspect your initial hypothesis about the reason Nyx is freezing is inaccurate. Feel free to file a separate ticket with the `nyx --debug` output when Nyx freezes so I can see what's up.
**Trac**:
**Username**: wagonDamian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/28807Ask authority operators to set `MaxAdvertisedBandwidth 0` in their torrcs2020-06-13T16:03:58ZTracAsk authority operators to set `MaxAdvertisedBandwidth 0` in their torrcsCurrently, it seems that Tor clients don't use DA nodes for construction of circuits because all DA's bandwidth is set to 20, which is a very low value. To move unneeded client traffic out of DA nodes completely, we could have some `torr...Currently, it seems that Tor clients don't use DA nodes for construction of circuits because all DA's bandwidth is set to 20, which is a very low value. To move unneeded client traffic out of DA nodes completely, we could have some `torrc` option on client's side (which disables construction of such circuits) and on DA's side (which block client's requests to use the DA as a node in its circuits). Additionally, use of DA nodes in clients circuits may be governed by some consensus values published by DA nodes.
In general, in testing Tor network with a small number of nodes, enabling this option may be undesirable, but in the main Tor network it may help DA nodes to decrease their load. Also, this explicit solution may be more clean than the current probabilistic approach which relies on a small bandwidth value set for DA nodes.
This task was originally discussed in [[comment](http://ea5faa5po25cf7fb.onion/projects/tor/ticket/28676#comment:15|another)] with teor.
**Trac**:
**Username**: wagonhttps://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/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/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/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/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/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 Johnson