> On 30 Jan 2017, at 11:43, Norbert Hartl <norb...@hartl.name> wrote:
> 
>> 
>> Am 30.01.2017 um 11:36 schrieb Denis Kudriashov <dionisi...@gmail.com>:
>> 
>> Hi Sean.
>> 
>> 2017-01-28 19:06 GMT+01:00 Sean P. DeNigris <s...@clipperadams.com>:
>> Have you considered security at all yet? Leaving a port open which allows
>> arbitrary code to be executed reomotely seems very dangerous...
>> 
>> Norbert already answer you. I just put little summary. 
>> Currently there is two important issues which must be handled manually:
>> - security. You can manage it by VPN or SSH
>> - distributed garbage collection. You need perform "remotePharo disconnect" 
>> (or "PrmRemotePharo disconnectAll") at the end of your working session. It 
>> cleans server and client from distributed objects.
>> 
>> Last issue is at high priority in my todo. When I implement it unused 
>> distributed objects will be collected automatically like local ones.
>> Security option can be added too. Seamless design allows to it. Probably It 
>> can be simple switch to SecureSocketStream instead of SocketStream.
> 
> My advize for security is two-fold. The first reason not to apply security 
> features to seamless is that it complicates the code base with a feature that 
> is done better elsewhere. The second reason is that one big reason why this 
> can be unusable is latency. A high latency makes it very hard to use the 
> toolkit. So removing everything adding latency should be avoided. Security is 
> from the image perspective one of those things.

Explicit/manual SSH port forwarding is easy & safe. Doing it deliberately makes 
you more aware of what you are doing, which is very necessary in this case 
because of the huge danger involved (giving away full image control). But it 
will add its own latency (just like TLS would).

> thanks again for doing that. 
> 
> Norbert
> 
>> 
>> Important thing here that I am really satisfied with Seamless design which I 
>> made. It was driven by tests which means that it only addresses existing 
>> features but allow stable evolution to new functionality. And I thing it is 
>> most important property of any system: provide stable way how to evolve. 
>> System can be broken and very buggy at some point but if design and tests 
>> are stable then system will move. By stable I mean "do not require big 
>> changes for any new bug or feature", "always iterative process".
>> Just want to share these thoughts with you :).


Reply via email to