Opened 12 years ago

Last modified 3 years ago

#586 closed defect (Fixed)

alpha users accumulating hashedcontrolpassword lines

Reported by: arma Owned by:
Priority: Low Milestone: 0.2.0.x-rc
Component: Core Tor/Tor Version: 0.2.0.9-alpha
Severity: Keywords:
Cc: arma, edmanm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In Tor 0.2.0.13-alpha, I added this feature:

  • Allow multiple HashedControlPassword config lines, to support multiple controller passwords.

But since Vidalia launches Tor by listing a newly generated
HashedControlPassword on the command-line, every time you
launch Vidalia and change thing and saveconf, it will append
that new HashedControlPassword to your torrc.

So my ~/.vidalia/torrc has 8 of them now. I bet there are people
who have even more.

It occurs to me that options given on the command line might not
need to be saved during a saveconf. But it's far too late to act
on that realization.

The best idea I've got is to change HashedControlPassword back so
you can only have one, and add a new config option
AlternateHashedControlPassword which lets you set multiple and
acts like the current one.

Then we should clear out the extra lines in the current torrcs,
and that new feature is still around in case somebody wants to
use it.

Anybody have a better answer?

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (11)

comment:1 Changed 12 years ago by nickm

This sounds like a vidalia bug, not a tor problem.

Tor is IMO doing the right thing now.

comment:2 Changed 12 years ago by nickm

If we want a workaround, though, the initial thought of making saveconf not apply to options set via the command
line seems best for a longterm basis, if a little tricky to implement. Maybe there could be a way to mark some
options as ephemeral and not to be saved (via the command line and/or via the controller)?

comment:3 Changed 12 years ago by edmanm

I'm cool with calling this a Vidalia bug. Though, obviously, I don't know what the expected behavior for Vidalia
should be then. Promise to never say SAVECONF when we've started Tor with a random password?

comment:4 Changed 12 years ago by arma

Well, we already have a way to mark certain config options as ephemeral:

    /* Don't save 'hidden' control variables. */
    if (!strcmpstart(fmt->vars[i].name, "__"))
      continue;

But one of the big challenges here is that Vidalia doesn't know what version
of Tor it's launching until after it's launched it -- so any change in how
we expect Vidalia to launch Tor needs to consider that.

One option would be for Vidalia to run tor --version first, and then either
launch with HashedControlPassword if tor is an old version, or with
a new config option that we add called __HashedControlPassword if it's a
new version.

(This is similar to my original suggestion, but maybe it's different enough
that Nick will like this one more.)

In any case we'd need to deal with the fallout from the bug during 0.2.0.13-alpha
up through 0.2.0.17-alpha. My first thought is to blow away extra lines when
we're loading a torrc from an old version -- but then I realized that the torrc
doesn't say what version wrote it! Can we use the version the state file says, or
might they get out of sync?

I guess Vidalia could be the one that does the cleanup -- if it is launching Tor
as normal with a random password, then it clears the previously set
HashedControlPassword lines. But I don't like that much going forward.

Last edited 3 years ago by arma (previous) (diff)

comment:5 Changed 11 years ago by nickm

If we add a new __SessionHashedControlPassword (just like HashedControlPassword, but ephemeral,
so that it's only for the given session), that would be fine.

Another option would be to add something like a "user" tag to HashedControlPassword, so Vidalia could
say HashedControlPassword Vidalia 16:C4184E7289B52B3E609F095768C5E9D6E67FC2CF6BDC571FEA143C5488
and then later only remove the lines with "Vidalia" in them. That's more like what real password mgt systems do.

I'm not completely sure the right way to migrate away from the old cruft.

Last edited 5 years ago by arma (previous) (diff)

comment:6 Changed 11 years ago by nickm

Suggestion: have vidalia blow all the old ones away if it can, by noticing its version has changed.

It might also be neat to have SAVECONF insert a comment saying what version
generated the file. Make this into a magic comment Tor can parse. Perhaps something like

##$LAST-SAVED-BY Tor 0.2.0.20-rc (rLotsandlots) HASH .

comment:7 Changed 11 years ago by nickm

__HashedControlSessionPassword added in r13543. Now the only problem is getting rid of the old stuff.

Last edited 5 years ago by arma (previous) (diff)

comment:8 Changed 11 years ago by arma

In r13683 I made it so running old Vidalias on the new Tor won't cause
new lines to appear.

Seems to me that the best answer for the old lines, given that neither
Tor nor Vidalia have a way of telling what version their config file
came from, is to ignore them. People who like editing their torrc files
will notice them (possibly complain or file bug reports) and remove them.
People who never touch their torrc will never know about them.

comment:9 Changed 11 years ago by arma

This seems resolved to me, at least as much as we're going to resolve it. Closing.

comment:10 Changed 11 years ago by arma

flyspray2trac: bug closed.

comment:11 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.