[tor-bugs] #14899 [Tor]: Enable Tor to work without using filesystem for cached files

[Tor Bug Tracker & Wiki]

#14899: Enable Tor to work without using filesystem for cached files
---------------------------------------------+-----------------------------
 Reporter:  naif                             |          Owner:
     Type:  enhancement                      |         Status:  new
 Priority:  Medium                           |      Milestone:  Tor:
Component:  Tor                              |  unspecified
 Severity:  Normal                           |        Version:
 Keywords:  globaleaks-wants needs-proposal  |     Resolution:
Parent ID:                                   |  Actual Points:
  Sponsor:                                   |         Points:
---------------------------------------------+-----------------------------
Changes (by naif):

 * severity:   => Normal


Comment:

 Regarding the open design questions i think that:

 a) Assume that the Application controlling a Tor initialization that way,
 will gives to Tor the latests version of the states/versions of those
 data-structures dumped just before shutting it down
 b) This feature should only apply to Tor clients (that need to work, for
 example, in a mobile application w/out filesystem I/O)
 c) A possibility could be to work like a "Blob" that represent exactly the
 actual filesystem stored files, leveraging the very same validation
 routines possibly without writing additional validation codes
 d) It's nice the idea to enable a "write" feature to be issues only with
 Tor clients that starts with "DisableNetwork 1", leaving to the third
 party application logic the duty to "feed" the valid startup files via Tor
 CP. An application willing to use that feature would first need to startup
 Tor with "DisableNetwork 1" and something like "DisableStateFilesWrite 1",
 then somehow tell Tor to "Startup 1st time the Network"
 e) If Tor Control Protocol enable to a client to "register" for
 asynchronous events, it would be really nice to be able to have the third
 party application to listen for changes in the data structure (example:
 cached-certs), so it will be able to receiver the latests updated version
 of that "blobs" from Tor and store it a database

 That way the application logic would be minimized, a txtorcon API could
 provide a set of asynchronous callback to a Twisted application to store
 the different data-structure that Tor would like to write/update, into the
 third party managed Tor database.

 That kind of constraints and limits would probably still allow filesystem
 free operations for Tor Clients being integrated into third party
 application, by limiting the possible risks and the application logic
 mistake that could happen, having a sort of "simple PIPE" between Tor ->
 TorCP -> TorCP Client -> TxTorConn -> Application-using-TxTorConn ->
 Application-Database and vice-versa.

 What do you think?

 Come to the dark side, we have Italian Red Wine! (not cookies!) :-)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14899#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online