Improve and refactor circuit isolation code

With !38 (merged), we now have working circuit isolation code. Here are some follow-up items for %Arti 0.0.1 release: basic anonymity. We should probably talk about these before going ahead and doing them, however: most of these involve some design thinking.

• Possibly: Split the Usage types and the Isolation types into separate types, such that they can be used and tested independently. Maybe the concrete TargetCircUsage and SupportedCircUsage types ought to be .
• Possibly: Instead of IsolationToken, support isolation profiles with multiple fields, like we do in Tor. This would let us get rid of IsolationMap in tor-client. Perhaps "isolation" should be represented with a a trait and CircMgr should be parameterized with it?
• Test coverage on IsolationMap, assuming we keep it.
• A function on TorClient to return a clone of the TorClient whose streams are always isolated from the original TorClient.
• Configurable isolation for different types of field in tor-client, like tor has today.
• Integration tests that make sure that streams that are supposed to be isolated are in fact assigned to different circuits.

changed milestone to %Arti 0.0.1 release: basic anonymity

added Backlog label

assigned to @dgoulet

added Next label and removed Backlog label

added Doing label and removed Next label

mentioned in merge request !78 (closed)

added Backlog label and removed Doing label

added Next label and removed Backlog label

Taking this over since @dgoulet is busy; I'll see how much of !78 (closed) I can repurpose here.

assigned to @nickm and unassigned @dgoulet

added Doing label and removed Next label

mentioned in merge request !104 (merged)

marked the checklist item A function on TorClient to return a clone of the TorClient whose streams are always isolated from the original TorClient. as completed

Okay; !104 (merged) has covered the important API piece, and set the stage for later work. That's enough for 0.0.1.

changed milestone to %Arti 0.1.0 release: Okay for experimental embedding

added Backlog label and removed Doing label

unassigned @nickm

added Sponsor 119 label

added Next label and removed Backlog label

added Backlog label and removed Next label

added API Break label

We had a conversation about this in a pad:

@Diziet

isolation tokens, should they be serialize or something ?

@eta

they're supposed to be completely opaque, but maybe the API design is unclear

@nickm

I don't think so; it doesn't make sense to share them between processes or over the network

@Diziet

A system which handles multiple isolated callers might save information about those callers to disk. Currently, it would need to construct fresh isolation tokens on every restart, rather than just serializing them with the rest of its state. OTOH making them serialize (or equivalent) would mean writing something about what it means to load them and/or combine loaded ones with newly-generated ones.

@nickm

Yeah, that is an issue. If we can send these tokens across processes, then we need to worry about having the ones that I generate now collide with the ones that I'm deserializing. My inclination would be to maybe hold off here until we have >=1 users that want this, so that their needs can help drive our design.

mentioned in issue #279 (closed)

marked this issue as related to #279 (closed)

changed milestone to %Arti 1.0.0: Ready for production use

added Roadmap label

mentioned in issue #331 (closed)

added Security label

changed time estimate to 36h

Marking as Needs Scope. There's uncertainty here about how much of C tor's flexibility is actually needed here.

added Needs Scope label

added Roadmap::Future label and removed Backlog label

added Backlog label and removed Roadmap::Future label

Taking this for now, at least as far as figuring out the scope and design go.

assigned to @nickm

Closed by !377 (merged). See #414 (closed) for followup.

closed

marked the checklist item Possibly: Instead of IsolationToken, support isolation profiles with multiple fields, like we do in Tor. This would let us get rid of IsolationMap in tor-client. Perhaps "isolation" should be represented with a a trait and CircMgr should be parameterized with it? as completed