Skip to content
Snippets Groups Projects
New look: Off

Scrolling support for tor-prompt is needed

    • Closed Issue created by Trac @tracbot

    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: wagon

    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    • Trac added component::archived/stem owner::atagar priority::medium reporter::wagon resolution::wontfix severity::normal status::closed tor-prompt type::enhancement version::tor 0.3.4.8 labels

      added component::archived/stem owner::atagar priority::medium reporter::wagon resolution::wontfix severity::normal status::closed tor-prompt type::enhancement version::tor 0.3.4.8 labels

    • Trac
      Trac @tracbot ·
      Author

      Trac:
      Username: wagon
      Keywords: N/A deleted, tor-prompt added

    • A
      Damian Johnson @atagar ·

      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!

      Trac:
      Status: assigned to closed
      Resolution: N/A to wontfix

    • Trac
      Trac @tracbot ·
      Author

      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.

      Trac:
      Username: wagon

    • Trac
      Trac @tracbot ·
      Author

      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 [options] to get more information accessible through Nyx and ControlPort, but my question is mainly about default Tor configuration.

      Trac:
      Username: wagon

    • A
      Damian Johnson @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/' or 'GETINFO ns/name/').

    • Trac
      Trac @tracbot ·
      Author

      Please file a ticket with the 'Core Tor / Tor' component for this one. Done: [[https://trac.torproject.org/projects/tor/ticket/28358|#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/' or 'GETINFO ns/name/') 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?

      Trac:
      Username: wagon

    • Trac
      Trac @tracbot ·
      Author

      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 (moved).

      Trac:
      Username: wagon

    • A
      Damian Johnson @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.

    • Trac
      Trac @tracbot ·
      Author

      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 (moved), #28760 (moved). If you need something from me let me know. I think you could add SAFECOOKIE auth example from [comment] to doc page as I suggested.

      Trac:
      Username: wagon

    • A
      Damian Johnson @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

    • Trac
      Trac @tracbot ·
      Author

      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).

      Trac:
      Username: wagon

    • A
      Damian Johnson @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

    • Trac
      Trac @tracbot ·
      Author

      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 [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 [ticket thread].

      Trac:
      Username: wagon

    • Trac closed

      closed

    Please register or sign in to reply