- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Security in the image

by Ben Coman

On Sun, Apr 23, 2017 at 8:33 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > But what makes Pharo nice is also that there are no such limitations. > > There are security things in Pharo, like disabling socket acces etc. > Maybe putting the VM in a true sandbox would be more adequate. > That can be done in a lot of ways at the OS level. Think containers. > > Phil But that doesn't help us take over the world with *everyone* working within the Giant-Single-Galactic-Image. mhahHaHaHAhaaaaa.... cheers -ben > > On Sun, Apr 23, 2017 at 1:33 PM, Guillermo Polito > <guillermopolito(a)gmail.com> wrote: >> >> Generally speaking, and from my understanding, you will not be able to do: >> >> SomeClass compile: 'initialize >> MyEvilHack dostuff. >> ^ super initialize ' >> >> In newspeak. >> >> And that's because you are not able to do: >> >> SomeClass compile: '...' >> >> Newspeak uses object capabilities, and following those principles, you >> will only be able to compile and install code in a class, if somebody gives >> you a capability to do so. >> >> Then, the problem is that right now Pharo's reflective API is convoluted >> with the base API, and thus from any piece of code you can do e.g.,: >> >> anyObject superclass superclass allSubclasses... >> >> A possible solution to this is to separate the reflective API from the >> base API. >> >> On Sun, Apr 23, 2017 at 9:16 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> On Thu, Apr 13, 2017 at 3:54 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>> > >>> > 2017-04-12 18:32 GMT+02:00 Ben Coman <btc(a)openinworld.com>: >>> >> >>> >> If you want hostile actors working directly within the Image with a >>> >> full >>> >> environment, then Pharo is probably not suitable. Its easy to get >>> >> hold of >>> >> global class from the Playground references and overwrite/compile any >>> >> method >>> >> in the system like this... >>> >> >>> >> SomeClass compile: 'initialize >>> >> MyEvilHack dostuff. >>> >> ^ super initialize ' >>> >> >>> >> You might want to consider Newspeak, which runs on the same VM as >>> >> Pharo >>> >> and has a focus on security. >>> > >>> > >>> > Interesting how they address your example? >>> >>> Not a direct response, but in Newspeak forum I see Gliad [1] respond >>> to LaeMing... "Newspeak (note the capitalization) fits with your >>> concerns around security and asynchrony, though the reality needs >>> work. The main implementation runs on Smalltalk and as such is >>> insecurable. There are less complete implementations based on >>> compiling to Javascript and to the Truffle VM, and Ryan's Psoup VM, >>> which is probably the most compliant version." >>> >>> [1] >>> https://groups.google.com/forum/#!searchin/newspeaklanguage/laeming%7Csort:… >>> >>> cheers -ben >>> >> >

April 23, 2017

Re: [Pharo-dev] Security in the image

by phil＠highoctane.be

But what makes Pharo nice is also that there are no such limitations. There are security things in Pharo, like disabling socket acces etc. Maybe putting the VM in a true sandbox would be more adequate. That can be done in a lot of ways at the OS level. Think containers. Phil On Sun, Apr 23, 2017 at 1:33 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Generally speaking, and from my understanding, you will not be able to do: > > SomeClass compile: 'initialize > MyEvilHack dostuff. > ^ super initialize ' > > In newspeak. > > And that's because you are not able to do: > > SomeClass compile: '...' > > Newspeak uses object capabilities, and following those principles, you > will only be able to compile and install code in a class, if somebody gives > you a capability to do so. > > Then, the problem is that right now Pharo's reflective API is convoluted > with the base API, and thus from any piece of code you can do e.g.,: > > anyObject superclass superclass allSubclasses... > > A possible solution to this is to separate the reflective API from the > base API. > > On Sun, Apr 23, 2017 at 9:16 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> On Thu, Apr 13, 2017 at 3:54 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> > >> > 2017-04-12 18:32 GMT+02:00 Ben Coman <btc(a)openinworld.com>: >> >> >> >> If you want hostile actors working directly within the Image with a >> full >> >> environment, then Pharo is probably not suitable. Its easy to get >> hold of >> >> global class from the Playground references and overwrite/compile any >> method >> >> in the system like this... >> >> >> >> SomeClass compile: 'initialize >> >> MyEvilHack dostuff. >> >> ^ super initialize ' >> >> >> >> You might want to consider Newspeak, which runs on the same VM as Pharo >> >> and has a focus on security. >> > >> > >> > Interesting how they address your example? >> >> Not a direct response, but in Newspeak forum I see Gliad [1] respond >> to LaeMing... "Newspeak (note the capitalization) fits with your >> concerns around security and asynchrony, though the reality needs >> work. The main implementation runs on Smalltalk and as such is >> insecurable. There are less complete implementations based on >> compiling to Javascript and to the Truffle VM, and Ryan's Psoup VM, >> which is probably the most compliant version." >> >> [1] https://groups.google.com/forum/#!searchin/newspeaklanguage/ >> laeming%7Csort:relevance/newspeaklanguage/0-20dj5m6wo/f5xpYnBFBgAJ >> >> cheers -ben >> >> >

April 23, 2017

Re: [Pharo-dev] Security in the image

by Guillermo Polito

Generally speaking, and from my understanding, you will not be able to do: SomeClass compile: 'initialize MyEvilHack dostuff. ^ super initialize ' In newspeak. And that's because you are not able to do: SomeClass compile: '...' Newspeak uses object capabilities, and following those principles, you will only be able to compile and install code in a class, if somebody gives you a capability to do so. Then, the problem is that right now Pharo's reflective API is convoluted with the base API, and thus from any piece of code you can do e.g.,: anyObject superclass superclass allSubclasses... A possible solution to this is to separate the reflective API from the base API. On Sun, Apr 23, 2017 at 9:16 AM, Ben Coman <btc(a)openinworld.com> wrote: > On Thu, Apr 13, 2017 at 3:54 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > > > 2017-04-12 18:32 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > >> > >> If you want hostile actors working directly within the Image with a full > >> environment, then Pharo is probably not suitable. Its easy to get hold > of > >> global class from the Playground references and overwrite/compile any > method > >> in the system like this... > >> > >> SomeClass compile: 'initialize > >> MyEvilHack dostuff. > >> ^ super initialize ' > >> > >> You might want to consider Newspeak, which runs on the same VM as Pharo > >> and has a focus on security. > > > > > > Interesting how they address your example? > > Not a direct response, but in Newspeak forum I see Gliad [1] respond > to LaeMing... "Newspeak (note the capitalization) fits with your > concerns around security and asynchrony, though the reality needs > work. The main implementation runs on Smalltalk and as such is > insecurable. There are less complete implementations based on > compiling to Javascript and to the Truffle VM, and Ryan's Psoup VM, > which is probably the most compliant version." > > [1] https://groups.google.com/forum/#!searchin/newspeaklanguage/laeming% > 7Csort:relevance/newspeaklanguage/0-20dj5m6wo/f5xpYnBFBgAJ > > cheers -ben > >

April 23, 2017

Re: [Pharo-dev] #renameTo: and #moveTo:

by Stephane Ducasse

Yes we should improve the primitive information return back to the image. On Fri, Apr 21, 2017 at 10:08 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > On Thu, Apr 20, 2017 at 09:21:01PM +0200, Nicolas Cellier wrote: > > 2017-04-20 9:53 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > > > > > What? Google this: man stat The first field of stat structure is > > > a device ID, so deciding if two files are on same file system or > > > not is doable by checking this field for the source file and > > > destination file (if it exists) or directory - modulo the fact > > > that you'd have to care of symbolic links with lstat. > > > > I meant from within the image. Also, while this is fine for > > Linux, and probably for MacOS, what about Windows? > > > > Ah, so it's more a Squeak/Pharo VM problem than a unix problem ;) You > > are right, there is a call to stat() in unix file plugin > > > > https://github.com/OpenSmalltalk/opensmalltalk- > vm/blob/Cog/platforms/unix/plugins/FilePlugin/sqUnixFile.c > > > > but the device info is not passed back to the image... Too bad! > > But it should be a straightforward extension. I think I'll ask on > vm-dev if anyone objects to me adding this extension. > > Thanks for pointing this out! > > Cheers, > Alistair > > > > As for windows, it's not a problem, there is a rename function that > > would move files across devices (but not directories!) See rename() on > > msdn https://msdn.microsoft.com/en-us/library/zw5t957f.aspx > >

April 23, 2017

Re: [Pharo-dev] Security in the image

by Ben Coman

On Thu, Apr 13, 2017 at 3:54 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-04-12 18:32 GMT+02:00 Ben Coman <btc(a)openinworld.com>: >> >> If you want hostile actors working directly within the Image with a full >> environment, then Pharo is probably not suitable. Its easy to get hold of >> global class from the Playground references and overwrite/compile any method >> in the system like this... >> >> SomeClass compile: 'initialize >> MyEvilHack dostuff. >> ^ super initialize ' >> >> You might want to consider Newspeak, which runs on the same VM as Pharo >> and has a focus on security. > > > Interesting how they address your example? Not a direct response, but in Newspeak forum I see Gliad [1] respond to LaeMing... "Newspeak (note the capitalization) fits with your concerns around security and asynchrony, though the reality needs work. The main implementation runs on Smalltalk and as such is insecurable. There are less complete implementations based on compiling to Javascript and to the Truffle VM, and Ryan's Psoup VM, which is probably the most compliant version." [1] https://groups.google.com/forum/#!searchin/newspeaklanguage/laeming%7Csort:… cheers -ben

April 23, 2017

GSOC Mentors - We need you.

by Serge Stinckwich

Dear mentors, we are currently reviewing all the students proposals. Please join the #gsoc-planning on Discord for giving your insights about the students. The deadline for the final selection will be Monday 24th 6pm CEST. As a reminder, we have 5 slots given by Google this year. Regards, -- Serge Stinckwich UCN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

April 22, 2017

Re: [Pharo-dev] Help browser topic ordering

by Juraj Kubelka

> El 22-04-2017, a las 01:04, Ben Coman <btc(a)openinworld.com> escribiÃ³: > > What is it that defines the ordering of topics in the help browser? > > I see slice 19963 added a "Travis Integration" topic into build 60468 > http://forum.world.st/pharo-project-pharo-core-7bde98-60468-td4942945.html > This is an error that Alexandre likely forgot to submit, because I was with him, when we noticed it and fixed it. > and its ended up at the top of the list above "Welcome", > but I determine from the slice or other existing help topics > where the order is defined? It is ordered by topic name, but you can notice that Welcome Help has String withValue: 0 at the beginning in order to be the first. Juraj > > cheers -ben >

April 22, 2017

Re: [Pharo-dev] Traits methods flattened

by Hilaire

Hi Stef, I shared with Pavel my package because the fix for pharo5 did not work on my package. Since years because of my incurable disease I need to take rest during the day. When things get break in Pharo and I get stuck, I behave like an impatient and I fell I am running out of time. Take rest, cherish your health like your kids! Hilaire Le 22/04/2017 Ã 18:34, Stephane Ducasse a Ã©crit : > Thanks Pavel!!! > I'm so tired and exhausted I nearly slept all the afternoon :( > Not good. But I will recover. -- Dr. Geo http://drgeo.eu

April 22, 2017

Re: [Pharo-dev] DarkTheme - tool bar icon color inconsistent

by Stephane Ducasse

oversight :) On Sat, Apr 22, 2017 at 6:16 AM, Ben Coman <btc(a)openinworld.com> wrote: > n the previous white theme, toolbar icons matched the colour of their text. > This makes a lot sense and is pleasant. > > In the dark theme, there is no correlation. > Is this oversight or deliberate intent? It jars my senses. > > https://pharo.fogbugz.com/f/cases/19973/DarkTheme-tool-bar-icons > > cheers -ben >

April 22, 2017

Re: [Pharo-dev] [Vm-dev] Order of evaluation bug with in lined to:do: in both Opal and Squeak compilers.

by Stephane Ducasse

I'm happy that we can remove bugs. We should redo a pass on Opal and enhance it because we need a better architecture for our future. Stef On Fri, Apr 21, 2017 at 9:20 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > John Brant discovered this bug recenlty: > > (see bottom of his post) > http://forum.world.st/collection-flatCollect-something-VS-collection- > collect-something-flattened-tp4929422p4929479.html > > > > 2017-04-21 1:56 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> >> >> On Thu, Apr 20, 2017 at 4:41 PM, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >> >>> Hi All, >>> >>> just stumbled across a bytecode compiler bug that's in both the >>> Squeak compiler and the Opal compiler. I'm told by ClÃ©ment that Opal >>> mimics the bug to avoid crashing legacy code. So there may be places that >>> depend on this bug. It would be good to eliminate the dependencies and the >>> bug. >>> >>> For illustration look at the to:do: loop in the ifNil: arm in >>> Context>>privRefresh: >>> >>> Context>>privRefresh >>> "Reinitialize the receiver so that it is in the state it was at its >>> creation." >>> closureOrNil >>> ifNotNil: >>> [pc := closureOrNil startpc. >>> self stackp: closureOrNil numArgs + closureOrNil numCopiedValues. >>> 1 to: closureOrNil numCopiedValues do: >>> [:i | self tempAt: closureOrNil numArgs + i put: (closureOrNil at: i)]] >>> ifNil: >>> [pc := method initialPC. >>> self stackp: method numTemps. >>> method numArgs+1 to: method numTemps do: >>> [:i | self tempAt: i put: nil]] >>> >>> >>> This should evaluate method numArgs + 1 then method numTemps. If it >>> were written as a non-in-lined (method numArgs+1 to: method numTemps) do: >>> [:i| self tempAt: i put: nil] then the [self tempAt: i put: nil] block >>> would be created next. But the bytecode for the inlined version is >>> >>> self stackp: method numTemps. >>> 63 <70> self >>> 64 <84 40 03> pushRcvr: 3 >>> 67 <D6> send: numTemps >>> 68 <E1> send: stackp: >>> 69 <87> pop >>> >>> iLimit := method numTemps >>> 70 <84 40 03> pushRcvr: 3 >>> 73 <D6> send: numTemps >>> 74 <69> popIntoTemp: 1 >>> >>> i := method numArgs + 1 >>> 75 <84 40 03> pushRcvr: 3 >>> 78 <D2> send: numArgs >>> 79 <76> pushConstant: 1 >>> 80 <B0> send: + >>> 81 <81 40> storeIntoTemp: 0 (squeak) <69> popIntoTemp: 1 (pharo) >>> 83 <10> pushTemp: 0 >>> 84 <11> pushTemp: 1 >>> 85 <B4> send: <= >>> 86 <AC 0B> jumpFalse: 99 >>> >>> There is a second bug in the Squeak bytecode; storeIntoTemp: is used to >>> load i whereas it should be popIntoTemp:. It was this second bug that >>> alerted me to the order-of-evaluation bug. >>> >> >> The second bug (Squeak's use of storeIntoTemp:) is actually only a poor >> implementation of the value/effect distinction through the inlined >> ifNil:ifNotNil:. Because ifNil:ifNotNil: has a value (albeit one that is >> discarded) the Squeak compiler generates a storeIntoTemp: to p[reserve the >> value of the to:do: lop, which is the initial index. So the bug is not >> within the generation of the to:do: (the only bug there being the >> order-of-evaluation one). The bug is actually outside; the loop should be >> being generated for effect but is being evaluated for value. >> >> On the order of evaluation bug, does anyone have any memory of which >> methods depended on this bug? >> >> _,,,^..^,,,_ >>> best, Eliot >>> >> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> >> >

April 22, 2017