On Fri, 26 May 2017 20:35:24 -0700 "Arthur D. Edelstein" arthuredelstein@gmail.com wrote:
The existing Linux sandbox does all of this already. Re-doing something that already exists (twice), seems somewhat silly to me.
Of course it would be! :) For Linux, I was envisioning adopting your work into the standard TBB distribution. Not writing it again from scratch.
It's not clear to me how a lot of that is possible without either doing a stupid amount of UI work (that will get thrown away), or rewriting a lot of the sandboxing code in JS/C++.
Am I missing something?
But we also need these steps on Windows and OS X. And my understanding is that on Linux there's more work to be done for step 4 and maybe some for the stopgap approach in step 3. Rather than waiting for a whole new tor-launcher UX in QT, maybe we can adopt your work from the earlier steps in standard TBB sooner.
Maybe I wasn't clear enough in my initial e-mail.
Even on Linux, there's a gigantic amount of work that's currently not being done at all, that would be required to improve the "not sandbox" components of the sandboxed launcher to get it up to parity with `tor-launcher`, and the amount of work will only increase as improvements and feature adds are made to `tor-launcher`[0].
*If* the plan is to eventually move to doing an external launcher, there is basically no point at all to doing the "gigantic amount of UI work", because it's for a codebase that is essentially dead, and scheduled for replacement (with the grand unified Qt launcher of awesome[1]).
Anyway, it's fairly clear to me that there is no clear plan for how to handle sandboxing's requirements vs `tor-launcher`, so I will continue with:
"the only guaranteed maintenance it gets is that it will get fixes when it breaks on Yawning's laptop, or when people submit detailed bug reports that Yawning can fix in spare time"
Regards,