Make NumEntryGuards configurable by the consensus

I plan to move clients to using 1 guard rather than 3. But I'd like to do that in a way that we can move them over as a group, once enough people have upgraded. I think that calls for a consensus param.

I shall call it NumEntryGuards.

And the controversial point is that I want to put it into 0.2.4.x as a security fix.

The timeline will be for some folks to upgrade, then we stick it in the consensus as NumEntryGuards=1, then when nothing explodes, we change the default-if-it's-not-in-the-consensus to 1, and eventually we don't need to set the consensus param anymore.

changed milestone to %Tor: 0.2.4.x-final in legacy/trac

added component::core tor/tor in Legacy / Trac milestone::Tor: 0.2.4.x-final in Legacy / Trac parent::11480 in Legacy / Trac priority::medium in Legacy / Trac resolution::implemented in Legacy / Trac status::closed in Legacy / Trac tor-client in Legacy / Trac type::enhancement in Legacy / Trac labels

See my branch ticket12688.

I believe it applies cleanly to maint-0.2.4 and maint-0.2.5 and master.

And it's nice and short too. :)

Trac:
Status: new to needs_review

I picked 10 as an upper bound for what the consensus param can set. I could also see picking 3.

Hm. I see from legacy/trac#12206 (moved) that we might want to leave clients with three directory guards? Shall I add a consensus param for that too?

Ok, my branch now has a second commit on it, that adds a NumDirectoryGuards consensus param. I chose the magic value 0 to mean "ignore this consensus param and do what you used to do", and that's the default.

Trac:
Parent: N/A to legacy/trac#11480 (moved)

Looks good to me.

I pushed a third commit which updates the man page entries.

What will this do during bootstrapping? I guess we don't pick guards before we have a consensus, so we don't need to worry about clients using the no-consensus default.

Assuming I'm right there, this seems okay to me for 025. I am kinda nervous about 024, but I can defer to your judgment there.

Begin code review of arma's ticket12688 branch:

1e3af73898cc51a75298de08204fccaedf97da25:

• I think nickm is right about not picking guards before having a consensus, but I thought we were trying to get away from 3 guards? I'd feel slightly better if the default value passed into networkstatus_get_param() weren't the case we were trying to avoid, but I believe this is okay.

7ecc86463ca42ee37f0140006ef077847439e97b:

• I think this is okay.

5c7356468bc6e08fafbc3a84b06e90b471d63c3d:

• This is fine.

End code review.

Replying to andrea:

I thought we were trying to get away from 3 guards? I'd feel slightly better if the default value passed into networkstatus_get_param() weren't the case we were trying to avoid, but I believe this is okay.

My hope here is to exactly duplicate the current situation, just making it configurable via the consensus.

Then later, once enough people have upgraded that there won't be some weird partitioning thing going on for users who just upgraded, we can flip the switch in the consensus and move people to 1 guard.

(And if things go horribly in some unforseen way, we can move it back to 3 and maybe they'll go unhorribly again.)

(And if we flip the switch to 1 guard and it works smoothly, we can change the default from 3 to 1 in a future code update, and eventually we won't need the consensus param anymore.)

Okay. Fine by me, I think.

Merged.

Trac:
Resolution: N/A to implemented
Status: needs_review to closed

closed

moved from legacy/trac#12688 (moved)

added Feature label and removed 1 deleted label

added Client label and removed 1 deleted label