> Am 30.01.2017 um 13:14 schrieb Norbert Hartl <norb...@hartl.name>:
> 
>> 
>> Am 30.01.2017 um 11:49 schrieb Sven Van Caekenberghe <s...@stfx.eu 
>> <mailto:s...@stfx.eu>>:
>> 
>>> 
>>> On 30 Jan 2017, at 11:43, Norbert Hartl <norb...@hartl.name 
>>> <mailto:norb...@hartl.name>> wrote:
>>> 
>>>> 
>>>> Am 30.01.2017 um 11:36 schrieb Denis Kudriashov <dionisi...@gmail.com 
>>>> <mailto:dionisi...@gmail.com>>:
>>>> 
>>>> Hi Sean.
>>>> 
>>>> 2017-01-28 19:06 GMT+01:00 Sean P. DeNigris <s...@clipperadams.com 
>>>> <mailto: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).
>> 
> Right. To make it a bit more concrete. If we use the example of Denis on port 
> 40423 then a simple
> 
> $ ssh -L 40423:localhost:40423 pharmide-server.anydomain.com 
> <http://pharmide-server.anydomain.com/>
> 
> will open a forwarding tunnel so you can connect with the PharmIDE client 
> using 
> 
> PrmRemoteIDE connectTo: (TCPAddress ip: #[127 0 0 1] port: 40423)
> 
> and you'll end up connecting to your remote image.
> 
> Unfortunately I couldn't test it because I installed the PharmIDE on my linux 
> machine and it does not work. When starting the image a listening port is 
> opened but 5 seconds later the port closes automatically. Has anyone tested 
> it on a linux machine?
> 
As a followup I need to say that it works now and it works like a charm. I 
installed one PharmIDE image on my server and did the SSL tunneling. Latency 
was very good or to say it was only that high that you can notice working on a 
remote image. I did only small tests but everything was working as expected. I 
think in the future we need to work out how we can inspect a remote object 
while using GT features. A lot of stuff in GT inspector is pretty useful. But 
then I assume it is really chatty at the same time making the remote usage less 
useful.

Great job!!! A dream comes true. If there is a working UFFI for ARM then we 
have a pretty decent stack for IoT times.

Bravo!

Norbert

> Norbert
> 
>>> 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