Opened 8 months ago

Closed 8 months ago

Last modified 4 months ago

#28300 closed enhancement (wontfix)

Scrolling support for tor-prompt is needed

Reported by: wagon Owned by: atagar
Priority: Medium Milestone:
Component: Core Tor/Stem Version: Tor: 0.3.4.8
Severity: Normal Keywords: tor-prompt
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (13)

comment:1 Changed 8 months ago by wagon

Keywords: tor-prompt added

comment:2 Changed 8 months ago by atagar

Resolution: wontfix
Status: assignedclosed

Hi wagon. tor-prompt uses your terminal's readline module. It isn't a curses interface like nyx so I don't have that level of control over scrolling (readline just provides standard terminal output, and as such relies on your normal window scrolling).

Sorry!

comment:3 Changed 7 months ago by wagon

It isn't a curses interface like nyx so I don't have that level of control over scrolling

OK, thanks! An alternative could be Nyx with special config options, were only connections window is shown.

comment:4 Changed 7 months ago by wagon

There is another question related to tor-prompt vs Nyx control interpreter. In tor-prompt double Tab key suggests possible completions for commands, but this doesn't work in Nyx interpreter. Can it be added to Nyx too? It is very convenient feature.

Then, as concerns commands themselves, Nyx lists some outdated variants. For example, when I use GETINFO status/version/num-concurring and GETINFO status/version/num-versioning 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

Should these commands be removed from interpreter's /help GETINFO listing?

If Sandbox 1 is set in torrc, during each start Nyx does something inappropriate to Tor forcing it to complain in log:

[err] sandbox_getaddrinfo(): Bug: (Sandbox) failed to get address [hostname redacted]! (on Tor 0.3.4.9 )

Is it OK? Should it be fixed?

There are many commands with * at the end. Does it always mean that some value must be substituted instead of *? For example, I didn't find any valid substitution for GETINFO config/* (config/defaults and config/names are separate and documented commands).

In Nyx connections window the value published is printed as information about selected relay. What ControlPort command Nyx uses to get its value? /var/lib/tor/cached-microdescs file?

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?

Yes, I could add extra options to get more information accessible through Nyx and ControlPort, but my question is mainly about default Tor configuration.

comment:5 Changed 7 months ago by atagar

In tor-prompt double Tab key suggests possible completions for commands, but this doesn't work in Nyx interpreter. Can it be added to Nyx too? It is very convenient feature.

Thanks wagon, glad you like it! Sadly autocompletion is a feature of readline so I can't add it to Nyx (similar to how I can't port scrolling to readline). In this case it's technically possible, but it would be quite a bit of work.

Should these commands be removed from interpreter's /help GETINFO listing?

Thanks! I'll look into it. The GETINFO command list comes from tor itself so I'll see if it includes anything saying what commands are deprecated. If not then this might require a tor change.

[err] sandbox_getaddrinfo(): Bug: (Sandbox) failed to get address [hostname redacted]! (on Tor 0.3.4.9 )

Please file a ticket with the 'Core Tor / Tor' component for this one. 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 (ie, not err runlevel or say it's a tor bug).

There are many commands with * at the end. Does it always mean that some value must be substituted instead of *?

Yup. For more information on all the commands see https://gitweb.torproject.org/torspec.git/tree/control-spec.txt

In Nyx connections window the value published is printed as information about selected relay. What ControlPort command Nyx uses to get its value?

Nyx gets the published attribute from the consensus ('GETINFO ns/id/<fingerprint>' or 'GETINFO ns/name/<nickname>').

comment:6 Changed 7 months ago by wagon

Please file a ticket with the 'Core Tor / Tor' component for this one.

Done: #28358.

For more information on all the commands see ​https://gitweb.torproject.org/torspec.git/tree/control-spec.txt

OK, then it's core Tor's bug:

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.

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/*" is not present:

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 syntax "option/*" implies that something not listed here (in list of options) should be substituted (e.g. fingerprint of a relay, IP address, etc.).

Nyx gets the published attribute from the consensus ('GETINFO ns/id/<fingerprint>' or 'GETINFO ns/name/<nickname>')

Thank you, I found it. I was selectively blind because I though it should printed at separate line in the output. :)

Could you reply also on my question about tor versions?

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?

comment:7 Changed 7 months ago by wagon

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?

See ticket #28676.

comment:8 Changed 7 months ago by atagar

Could you reply also on my question about tor versions?

Sounds like your other ticket's covering that. If you need something from me let me know.

comment:9 Changed 6 months ago by wagon

Sounds like your other ticket's covering that.

Yes. Both problems I reported about in above comments are appeared to be core Tor issues: #28757, #28760.

If you need something from me let me know.

I think you could add SAFECOOKIE auth example from this comment to doc page as I suggested.

comment:10 Changed 4 months ago by atagar

Hi wagon, sorry about the long multi-month lack of a reply. Your demo is perfect, works like a charm. Added it to our faq...

https://gitweb.torproject.org/stem.git/commit/?id=2cd7bff

comment:11 in reply to:  10 Changed 4 months ago by wagon

Replying to atagar:

Hi wagon, sorry about the long multi-month lack of a reply. Your demo is perfect, works like a charm. Added it to our faq...

Thanks, atagar! In the sentence

This demonstration will use xxd to for hex conversion and openssl for crypto.

"to" is not needed. isn't it?

I did my example in a single shell session to get variables working in the last auth command. That's why I had to suspend telnet session and then resume it later, after calculations. Otherwise, we need two different shells and necessary variables in both of them. I hope it is clear from your example too, but I would explicitly add some clarification between code samples that we: 1) suspend telnet, then 2) do openssl command in the same shell, and then 3) resume the same telnet session.

This was the reason for ^] key and then z (to suspend telnet) and for fg (to resume telnet session).

comment:12 Changed 4 months ago by atagar

Thanks wagon! Fixed the typo and adjusted the wording a tad...

https://gitweb.torproject.org/stem.git/commit/?id=85e96a0

I realized from your example that you backgrounded the telnet session, but wasn't sure how best to communicate that. I assumed by presenting additional terminal commands that the reader would realize they needed another prompt, but no harm in calling it out.

On a side note, were you the person that pointed out that tor-prompt is a bit slow? If so then I just improved that a bit...

https://gitweb.torproject.org/stem.git/commit/?id=0fc61dd

comment:13 Changed 4 months ago by wagon

Fixed the typo and adjusted the wording a tad...

Thanks!

I assumed by presenting additional terminal commands that the reader would realize they needed another prompt, but no harm in calling it out.

I wrote my example assuming that reader doesn't need another prompt. It was correct. When you change instruction to the case when 2nd prompt is used, you have to adjust the commands appropriately.

Just read your current version. You see that CookieString and ClientNonce were defined as variables only in the first prompt, where telnet was called. So, if you run the command

printf '%s%s%s\n' "${CookieString}" "${ClientNonce}" "${ServerNonce}" | xxd -r -p ...

in the second prompt, variables CookieString and ClientNonce will not be known there.

I would fix it as follows. I'ld remove the line

CookieString="$(xxd -u -p -c32 < /home/atagar/.tor/control_auth_cookie)"

from the place, where it is now (as telnet doesn't needs it at the first step), but after your words

we have our authentication cookie without divulging its content...

I would write these commands:

CookieString="$(xxd -u -p -c32 < /home/atagar/.tor/control_auth_cookie)"
ClientNonce="9C653314CC4CC2C695999CE84EB1B0045E3D59B6AFFE615D624DB4870DD7041E"
ServerNonce="1C2E73C41FA8537FDD3A59C2ECBE26DFC85E0A05389373AD8C130C0F5795A036"
printf '%s%s%s\n' "${CookieString}" "${ClientNonce}" "${ServerNonce}" | xxd -r -p \
> | openssl dgst -sha256 -binary -hmac "Tor safe cookie authentication controller-to-server hash" \
> | xxd -p -u -c32
A733E09A65E2A6030BF6710D800370FC3AD28E1D2545E1692D160545D93CEE68

Now it should be fine.

were you the person that pointed out that tor-prompt is a bit slow? If so then I just improved that a bit...

Yes. Thanks! I copy your comment to original ticket thread.

Note: See TracTickets for help on using tickets.