Am 30.01.2017 um 13:14 schrieb Norbert Hartl <norbert@hartl.name>:

Am 30.01.2017 um 11:49 schrieb Sven Van Caekenberghe <sven@stfx.eu>:

On 30 Jan 2017, at 11:43, Norbert Hartl <norbert@hartl.name> wrote:

Am 30.01.2017 um 11:36 schrieb Denis Kudriashov <dionisiydk@gmail.com>:

Hi Sean.

2017-01-28 19:06 GMT+01:00 Sean P. DeNigris <sean@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

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.