Opened 7 years ago

Closed 6 years ago

#3898 closed enhancement (fixed)

If CookieAuth and PasswordAuth are both offered, and cookie fails, fall back to password

Reported by: arma Owned by: chiiph
Priority: Medium Milestone: Vidalia: 0.3.x
Component: Archived/Vidalia Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: #3476 Points:
Reviewer: Sponsor:

Description

The Tor 0.2.2.x deb, from 0.2.2.29-beta on, enables CookieAuthentication by default:
https://gitweb.torproject.org/debian/tor.git/blob/debian-0.2.2:/debian/patches/06_add_compile_time_defaults.dpatch

So Vidalia users on Debian/Ubuntu who had set HashedControlPassword in their torrc are bitten by a Vidalia bug: if the controlport's ProtocolInfo line says cookie and hashedpassword are both supported, Vidalia tries cookie, and if it fails it gives up.

If cookie fails but hashedpassword is also offered, Vidalia should try that one next.

Ideally we'd either support this in the Vidalia 0.2.x timeframe, or step up the schedule to ship Vidalia 0.3.x alongside the Tor 0.2.2 debs in whatever debian/ubuntu releases are coming next.

(I wonder how this order-of-operations interacts with the later controlsocket support.)

Child Tickets

Change History (9)

comment:1 Changed 7 years ago by arma

See #3892 and #3476, who I think are users bitten by this bugWlack of feature.

comment:2 Changed 7 years ago by arma

velope points out that Vidalia might want to try the one configured in Vidalia first (if it's offered in protocolinfo). Presumably the users getting bitten here explicitly configured their Vidalia to try hashedpassword, and then Vidalia forgot about that configuration choice when Tor presented a list of options in ProtocolInfo.

comment:3 Changed 7 years ago by Sebastian

This is also a documentation issue in tor. The CookieAuthentication manpage entry is poorly written:

If this option is set to 1, don’t allow any connections on the control port except when the connecting process knows the contents of a file named "control_auth_cookie", which Tor will create in its data directory.

This sure sounds like if you set CookieAuthentication 1, the controller can't use passwords anymore (which seems to be inaccurate, from a quick glance at the code)

comment:4 in reply to:  3 Changed 7 years ago by arma

Replying to Sebastian:

This is also a documentation issue in tor.

Right -- we changed Tor's behavior in Tor 0.2.0.7-alpha, and forgot to fix the man page or the controllers. I just committed a fix to the man page, which will be in 0.2.2.33 and got into 0.2.3.3-alpha. Thanks!

comment:5 Changed 7 years ago by chiiph

Status: newneeds_review

A possible fix for this is in my branch chiiph/bug3898_auth.

Here's the commitdiff:
https://gitweb.torproject.org/chiiph/vidalia.git/commitdiff/c195275f448cca06e61041fe4dc3ab7f0603d824

Given the structure of this part of the settings, Vidalia will give more priority to what tor says it supports (Cookie, HashedPasswd, in that order).

I wonder if we should backport this to stable. There's a planned 0.3.1-alpha release this month, so I'm inclined to add release it there.

comment:6 Changed 7 years ago by chiiph

Milestone: Vidalia-0.3.X

comment:7 Changed 7 years ago by arma

I opened #3958 for the parallel problem in pytorctl.

comment:8 Changed 7 years ago by arma

Parent ID: #3476

comment:9 Changed 6 years ago by chiiph

Resolution: fixed
Status: needs_reviewclosed

This has been merged to alpha, it'll be shipped with Vidalia 0.3.1

Note: See TracTickets for help on using tickets.