Re: [tor-bugs] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
---+--
 Reporter:  wagon  |  Owner:  atagar
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:  Tor: 0.3.4.8
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor-prompt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (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 [[https://stem.torproject.org/faq.html|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
 [[http://ea5faa5po25cf7fb.onion/projects/tor/ticket/28877#comment:6|original
 ticket thread]].

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
---+--
 Reporter:  wagon  |  Owner:  atagar
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:  Tor: 0.3.4.8
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor-prompt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (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

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
---+--
 Reporter:  wagon  |  Owner:  atagar
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:  Tor: 0.3.4.8
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor-prompt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by wagon):

 Replying to [comment:10 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).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
---+--
 Reporter:  wagon  |  Owner:  atagar
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:  Tor: 0.3.4.8
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor-prompt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (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

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
---+--
 Reporter:  wagon  |  Owner:  atagar
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:  Tor: 0.3.4.8
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor-prompt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (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
 [[http://ea5faa5po25cf7fb.onion/projects/tor/ticket/28295#comment:7|this
 comment]] to doc page as I suggested.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
---+--
 Reporter:  wagon  |  Owner:  atagar
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:  Tor: 0.3.4.8
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor-prompt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
---+--
 Reporter:  wagon  |  Owner:  atagar
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:  Tor: 0.3.4.8
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor-prompt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
---+--
 Reporter:  wagon  |  Owner:  atagar
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:  Tor: 0.3.4.8
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor-prompt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by wagon):

 > 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?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
---+--
 Reporter:  wagon  |  Owner:  atagar
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:  Tor: 0.3.4.8
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor-prompt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (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/' or 'GETINFO ns/name/').

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
---+--
 Reporter:  wagon  |  Owner:  atagar
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:  Tor: 0.3.4.8
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor-prompt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (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 [[https://nyx.torproject.org/#missing_relay_details|extra
 options]] to get more information accessible through Nyx and
 `ControlPort`, but my question is mainly about default Tor configuration.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
---+--
 Reporter:  wagon  |  Owner:  atagar
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:  Tor: 0.3.4.8
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor-prompt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
---+--
 Reporter:  wagon  |  Owner:  atagar
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:  Tor: 0.3.4.8
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor-prompt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by atagar):

 * status:  assigned => closed
 * resolution:   => wontfix


Comment:

 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!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
---+--
 Reporter:  wagon  |  Owner:  atagar
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:  Tor: 0.3.4.8
 Severity:  Normal | Resolution:
 Keywords:  tor-prompt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by wagon):

 * keywords:   => tor-prompt


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
--+---
 Reporter:  wagon |  Owner:  atagar
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Component:  Core Tor/Stem
  Version:  Tor: 0.3.4.8  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
 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`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs