internal circuit building algorithm uses routers introduced by controller
The mechanism by which Tor constructs circuits internally freely incorporates routers introduced by the controller. In some cases this is desirable, such as when a controller exists for the purpose of feeding Tor additional router descriptors to use. In other cases this is undesirable, such as when a controller exists for the purpose of providing Tor with router descriptors for special use (e.g. Blossom). Adding an optional entry to the descriptor is insufficient, since a Tor controller could plausibly be trying to give a Tor client in one Tor network a descriptor that is used in another Tor network. Thus, we must store some internal state about whether a given descriptor is PUBLIC, meaning that Tor MAY use it to construct circuits internally, or PRIVATE, meaning that controllers MAY but Tor MAY NOT use it in constructing circuits. I propose that we modify the POSTDESCRIPTOR controller command to allow an extra argument that specifies the purpose of this router:
"+POSTDESCRIPTOR" (SP "PRIVATE") CRLF Descriptor CRLF "." CRLF
If "PRIVATE" is specified, then Tor MAY NOT use this descriptor to build circuits. (Preserves backwards compatibility)
Also, we may want to change the purpose of a descriptor, so I propose an additional controller command:
"SETDESCPURPOSE" SP ServerID SP {0,1}
If 0, then Tor will set the purpose of this descriptor to PRIVATE. If 1, then Tor will set the purpose of this descriptor to PUBLIC.
[Automatically added by flyspray2trac: Operating System: All]