Ah ok so you want to target the AST specifically, I see now.
Yeap I did not implement any security measure for Atlas because the goal
was local and not remote execution. Yes indeed the socket connects directly
to 127.0.0 port 4000.So Atlas is preconfigured to work locally. I think
safety is something that the developer must control to make it specific to
the nature of the code. Plus I am no web dev. Plus if OS security is
breached to gain access to Atlas, the user is already in a deep mess, Atlas
will be the least of his concerns.
If my assumption is correct and you execute python code by writing it to a
python file and then executing the module, note that this approach is
actually much slower to the socket approach. Which is why I did not go for
it in the first place. Sockets work similar to files but use memory and
thus do not write to hard disk and so they work faster. Which is why
sockets are so popular for local IPC as well. I am not sure if Pipes as
faster but I doubt it.
Memory mapped files are much safer and much faster, which is why shared
memory is the most popular IPC for local comunication , the hacker would
have to hack the memory low level style because memory mapped files are
controlled by the OS kernel and is basically what is used for shared
libraries, the very popular DLLs on windows , dylib on MacOS, and so on
Linux. If performance becomes a serious issue for you and you want the
safest way to do local IPC , I highly recommend this approach.
But if you are happy with your current solution, there is no need to modify
your code.
On Fri, Jan 5, 2018 at 9:09 PM Julien <julien.delplan...@inria.fr> wrote:
>
> Le 5 janv. 2018 à 17:15, Dimitris Chloupis <kilon.al...@gmail.com> a
> écrit :
>
>
>
>
>>
>> Python3Generator allows to generate a Python 3 AST programatically. So
>> basically you have objects that represent Python 3 AST nodes and some
>> messages in top of that to make the generation of the AST easier from Pharo.
>>
>> E.g.
>>
>> ast := 'print' asP3GIdentifier callWith: #('Hello world').
>>
>> ast inspect
>>
>
> yes buy why ? Why you want to generate objects , Python AST nodes are
> already python objects and you already generate AST nodes each time you
> execute python code.
>
> Using the Atlas syntax your above example would be simpler
>
> py = ATLPyParser new
>
> py print:'("Hello World")'
>
> Is there an advantage using your own syntax ? Is there any advantage of
> direct access to Python AST?
>
>
> In MatplotLibBridge I do some checking/optimisations on the AST generated
> by high-level API objects (e.g. for optimisation avoid importing a package
> twice).
> With an AST it is easy with basic Atlas I think this is not possible.
> Having an AST allow to do stuff on the code to execute before executing it
> and this easily
> and maintainable (i.e. not using regexes).
>
>
>> <Capture d’écran 2018-01-05 à 13.06.41.png>
>>
>> If you have a look at the readme on GitHub you will see more complexe
>> examples.
>>
>> Yes I did take a look but I still did not know why you bother generating
> identifiers for each python command manually when ATLPyParser does this
> automatically for you.
>
> For example you have this example
>
> "Use and initialize the FFI interpreter."
> P3GInterpreter useFFIInterpreter.
> P3GInterpreter current pathToPython: '/usr/bin/python3'.
>
> instr := P3GInstructionsList new.
>
> json := 'json' asP3GIdentifier.
> file := 'file' asP3GIdentifier.
> os := 'os' asP3GIdentifier.
>
> instr addAll: {
> json import.
> os import.
> file <- ('open' asP3GIdentifier callWith: #('/tmp/osp3g.json' 'w')).
> (file=>#write) callWith: { (json=>#dumps) callWith: {{
> 'os' -> (os=>#name).
> 'uname' -> (os=>#uname) call
> } asDictionary} }.
> ((file=>#close) call)
> }.
>
> instr execute.
>
>
> Using the ATLPyParser of Atlas would have been much simpler
>
> py = ATLPyParser
>
> Atlas sendMessage:'import json,os'
>
> py
> file:'= open("/tmp/osp3.json","w")';e;
> file write:'(json.dump({"os":os.name,"uname":os.uname}))';e;
> file close;e.
>
> Or the point is to fully parse pharo syntax to python ?
>
>
> What I would like to experiment for fun is translating Pharo Smalltalk to
> Python 3.
>
> And as said before with your technique you can not modify the AST easily
> before sending it to Python.
>
>
>
>
>> I wanted that to avoid the user having to set up a Python server
>> listening on a socket when it is not needed to get data from Python.
>>
>> Yep, but if I want to get value from Python into Pharo, I want to have
>> them as Pharo objects so as you said some conversion has to be made which
>> means more work.
>>
>
> Actually the server is setup at Pharo side, Python side is merely a
> client. All the heavy lifting is taking place via Pharo. The user does not
> need to do anything , its automatic. But yeah if you want to completely
> liberate yourself from sockets I can understand that, though I do not
> understand why, you use sockets every time you access the internet and they
> are really fast. So its not as if you can avoid socket generation.
>
>
> I agree that sockets are not costly but a problem I see with them is that
> it creates a *huge* security issue by letting anyone execute arbitrary
> Python code from the outside (except if you configured atlas to only accept
> connections from 127.0.0.1). Since I do not need socket to execute
> arbitrary code I prefer not using them.
>
>
