#28921: tor-prompt command 'GETINFO desc/all-recent > /dev/null' fails
---------------------------+-----------------------------------
Reporter: wagon | Owner: atagar
Type: defect | Status: needs_information
Priority: Medium | Milestone:
Component: Core Tor/Stem | Version:
Severity: Normal | Resolution:
Keywords: descriptor | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
---------------------------+-----------------------------------
Comment (by wagon):
> You misunderstand - my question was what python version are you using
when you get this exact stacktrace. Do you get stacktraces with both
python 2.7 and 3.4? If so then please provide the stacktrace you get for
each since they should not be identical.
OK, now it should be more clear. Old version, 1.6.0, which works fine, was
installed using `pip3`:
{{{
$ pip3 show stem
---
Name: stem
Version: 1.6.0
Location: /usr/local/lib/python3.4/dist-packages
Requires:
}}}
Inside `tor-prompt` it reports itself as 3.4.2:
{{{
>>> import sys; print(sys.version)
3.4.2 (default, Sep 25 2018, 22:02:39)
[GCC 4.9.2]
}}}
A header of `tor-prompt` file is `#!/usr/bin/python3`.
Now, let's consider new version installed from git. In `tor-prompt` it
says:
{{{
>>> import sys; print(sys.version)
2.7.9 (default, Sep 25 2018, 20:42:16)
[GCC 4.9.2]
}}}
A header of `tor-prompt` executable is `#!/usr/bin/env python`.
In my system both python2 and python3 are installed. Due to `python` in
header git version fails. If I edit this file by replacing `python` by
`python3`, the error disappears.
I think you should stick to python3 version in your git code if user has
`python3` installed. Just `python` should be used only as a fallback, when
user doesn't have the third version. Thus, since everything works in
`python3`, and `python2` will not be supported someday anyway, you could
fix headers and mark this ticket as resolved.
> I'm having difficulty seeing how version 1.7.0 could succeed in this
respect
It was 1.6.0. However, as I've just written, both version works with
`python3`.
> This is incorrect. Eavesdropping on a guard simply tells you that
someone is using tor. Not where they're going. Deanonymization, say via a
correlation attack, requires monitoring both your entry *and* exit
traffic.
I look at this from simple theoretical point of view. Anonymity is
indistinguishability of somebody (particular user) on so-called "anonymity
set" (all tor users). If nothing is known about you except of "your are
tor user" you get the best anonymity achievable in Tor network.
If you start logging to trac with a particular user name, you are no
longer (ideally) anonymous, but pseudonymous. It means anybody can see
what you are doing in Tor network, but nobody knows who you are.
Pseudonymous users are less anonymous.
Then, if somebody knows even more information about you or your network
connection, your "anonymity set" reduces more. When nothing is known about
you except your habit to use tor, you are one in 2 millions, so the
anonymity set is big which makes it hard to geolocate you. If your guard
is known, for powerful adversary your anonymity set is reduced to the
number of tor users who selected particular guard node. It is about 1
thousand users. As you see, by disclosing your guard you reduce your
anonymity set 2000 times which makes targeted correlation attacks simpler.
To get basic idea what is anonymity in network, look at definitions used
for [[https://en.wikipedia.org/wiki/Mix_network|Chaum mixes]] and see how
they [[https://www.freehaven.net/anonbib/|were developed further in Tor
routing protocol]]. First Tor papers with Roger and Nick should be easy
for you to read.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28921#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
