Re: [tor-bugs] #9444 [Tor bundles/installation]: Create deterministic TorBrowserBundles with Pluggable Transports

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#9444: Create deterministic TorBrowserBundles with Pluggable Transports
------------------------------------------+--------------------------
     Reporter:  bastik                    |      Owner:  erinn
         Type:  task                      |     Status:  needs_review
     Priority:  normal                    |  Milestone:
    Component:  Tor bundles/installation  |    Version:
   Resolution:                            |   Keywords:  flashproxy
Actual Points:                            |  Parent ID:
       Points:                            |
------------------------------------------+--------------------------

Comment (by GITNE):

 Replying to [comment:30 dcf]:
 > So one option is to continue building tor with `-mwindows`, add
 {{{CREATE_NO_WINDOW}}} to the flags when tor starts transports, and
 continue building transports as console applications.

 Yes, Tor should still be built with the {{{-mwindows}}} switch or
 {{{ld}}}'s {{{--subsystem windows}}} switch respectively. And so should
 the pluggable transport executables be built or linked too.

 This is actually a specification problem. Tor's current PTE specification
 makes invalid or naive assumptions about IPC and the available mechanisms
 thereof on Windows. The pluggable transport executables on Windows should
 be linked as UI applications too, not as console applications. If the PTEs
 need to talk to the user on the console, they should do so by detecting
 whether they were launched from a console, get a handle to it and in that
 case write to this console. However, they can still write to {{{stdout}}}
 or {{{stderr}}} whenever they want to, no matter whether they have been
 launched from console or by any UI app, but thier {{{stdout}}} or
 {{{stderr}}} output will not be visible unless they "grab" a console.
 Aside from that, because PTEs must talk to their parent Tor process and
 vice versa, this communication should be done via one or a combination of
 the [[http://msdn.microsoft.com/en-
 us/library/aa365574%28v=vs.85%29.aspx#base.using_data_copy_for_ipc|IPC
 mechanisms provided by Windows]], not
 {{{stdin}}}/{{{stdout}}}/{{{stderr}}}. So this is why Tor's PTE
 specification for Windows //must// get revised.

 IPC on Windows should be done via clipboard, COM, data copy
 ({{{WM_COPYDATA}}} event), DDE, file mapping, mailslots, pipes, RPC, or
 Windows Sockets, not via console output or
 {{{stdin}}}/{{{stdout}}}/{{{stderr}}}. Please do not assume {{{stdin}}},
 {{{stdout}}}, and {{{stderr}}} to be equivalent to POSIX pipes, simply
 because they are not (real) pipes on Windows. The same applies to Windows
 pipes. They are similar to POSIX pipes but not equivalent, meaning they do
 not implement POSIX pipes' semantics.

 For the purpose of Tor to PTE communication, a combination of events and
 file mapping should probably be the best fit on Windows (for obvious
 reasons).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9444#comment:32>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs