March 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Pharo-users] Do you have a tool that works on Pharo ?

by Mariano Martinez Peck

On Mon, Mar 21, 2011 at 4:50 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Alexandre, > > I agree that symbolic versions should be used in load expressions (when > defined), but that should be #'stable', with some missing parens: > > ((Smalltalk at: #ConfigurationOfOCompletion) project version: #'stable') > load. > Another problem I found is that symbolic versions where integrated AFTER Pharo 1.0 and 1.1 were released. So, if you document that people should use #stable instead....then they will raise an error in Pharo 1.0 or 1.1. A possible solution is to change your conf so that it makes sure to update Metacello. BUt this is complicated because you cannot be sure that metacello will always work there. IF metacello 28 (where symbolics are) works perfect in 1.0 and 1.1, AND IF there is a magic way to tell metacello to update only to .28 then we can add such code in #stable or some place in the conf.. but I am not sure. I prefer to document clearly. cheers mariano > > Dale > > > On Mar 21, 2011, at 4:00 AM, Alexandre Bergel wrote: > > > Shouldn't it be: > (Smalltalk at: #ConfigurationOfOCompletion) project version: 'stable' load. > > Instead? > > Alexandre > > Le 21 mars 2011 Ã 03:13, laurent laffont <laurent.laffont(a)gmail.com > <mailto:laurent.laffont@gmail.com>> a Ã©crit : > > Mariano, > > I've added Autotest. > > I've seen a lot of Configuration example which won't work because of > missing parenthesis: > > (Smalltalk at: #ConfigurationOfOCompletion) project version: '1.1.2' load. > > should be > > ((Smalltalk at: #ConfigurationOfOCompletion) project version: '1.1.2') > load. > > > I cannot fix it now - must go to work. > > Laurent > > On Sun, Mar 20, 2011 at 11:40 PM, Mariano Martinez Peck <<mailto: > marianopeck(a)gmail.com>marianopeck(a)gmail.com<mailto:marianopeck@gmail.com>> > wrote: > I've added: > > - Gofer > - Monticello > - Metacello > - Fuel > > If you can check and improve it..please do. It only took me 30 mins. > > Cheers > > Mariano > > > On Sun, Mar 20, 2011 at 11:12 PM, Mariano Martinez Peck <<mailto: > marianopeck(a)gmail.com>marianopeck(a)gmail.com<mailto:marianopeck@gmail.com>> > wrote: > I forgot...If someone answer "but you can browse the MetecelloRepository" > or "XX" or "blah"....the answer is that we are not targeting the same > people. Someone that knows how that he has to browse MetacelloRepository, > probably knows how to install the software, what it is, etc. > With this page (after, moved to the pharo website) we want to targe > business and new comers. Imagine someone arriving to Pharo and asking > himseld "mmmmm does Pharo have XXX that I have in YYY language? ". So the > idea is to show all the available tools. > > Cheers > > Mariano > > > On Sun, Mar 20, 2011 at 10:42 PM, StÃ©phane Ducasse <<mailto: > stephane.ducasse(a)inria.fr>stephane.ducasse(a)inria.fr<mailto: > stephane.ducasse(a)inria.fr>> wrote: > thanks mariano this is a good initiative. > > Stef > > On Mar 20, 2011, at 10:22 PM, Mariano Martinez Peck wrote: > > > ifTrue: [ self writeOnPharoBook: aTool] > > > > We need to improve our documentation. Right now, we have a collaborative > book where everyone can join and write: <http://book.pharo-project.org/> > http://book.pharo-project.org/ > > > > Here we have a list of tools that run on Pharo: < > http://book.pharo-project.org/book/PharoTools> > http://book.pharo-project.org/book/PharoTools > > and it is REALLY important to have such list updated and maintained. > > > > So, if you have a tool that works in pharo and it is not there, please > add it. If you don't have a user, I can create one for you. If you are TOO > lazy, you can send by email the text to me and I write it. > > > > Thanks > > > > Mariano > > > > > > > >

March 21, 2011

Re: [Pharo-project] Issue 3115 in pharo: better SharedQueue>>makeRoomAtEnd

by pharo＠googlecode.com

Updates: Status: Invalid Comment #3 on issue 3115 by marcus.d...(a)gmail.com: better SharedQueue>>makeRoomAtEnd http://code.google.com/p/pharo/issues/detail?id=3115 Bit for Pharo as we use SharedQueue2...

March 21, 2011

[Pharo-project] IWST @ ESUG 2011 call for papers

by Alain Plantec

------------------------------------------------------------------------------------------------------------------------ IWST @ ESUG 2011 International Workshop on Smalltalk Technologies August 23th, 2011 Edinburgh, Scotland http://www.esug.org/Conferences/2011/International-Workshop-on-Smalltalk-Te… CALL FOR PAPERS SUBMISSION DEADLINE : June 17, 2011 Authors of the best accepted papers will be invited to submit extended versions of their papers for publication in a special issue of 'Software: Practice and Experience' ------------------------------------------------------------------------------------------------------------------------ ESUG 2011 Smalltalk joint event IMPORTANT DATES * Submission deadline: June 17, 2011 * Notification deadline: July 15, 2011 GOALS AND SCOPE We are proud to invite submisssions to the International Workshop on Smalltalk Technologies which is held as part of the ESUG 2011 joint event at Edinburgh. The goals of the workshop is to create a forum around advances or experience in Smalltalk and to trigger discussions and exchanges of ideas. Participants are invited to submit short and not-so short research articles. We will not enforce any length restriction. However we expect papers of two kinds: * Short position papers describing emerging ideas. * Long research papers with deeper description of experiments and of research results. TOPICS We welcome contributions on all aspects, theoretical as well as practical, of Smalltalk related topics such as: * Aspect-oriented programming, * Meta-programming and Meta-modeling, * Frameworks, * Interaction with other languages, * Implementation, new dialects or languages implemented in Smalltalk, * Tools, * Design patterns, * Experience reports PUBLICATION Pending ACM approval for Digital Library. Both submissions and final papers must be prepared using the ACM SIGPLAN 10 point format. Templates for Word and LaTeX are available at http://www.acm.org/sigs/sigplan/authorInformation.htm; this site also contains links to useful informations on how to write effective submissions. PROGRAM CHAIRS: * LoÃ¯c Lagadec (Labsticc, University of Brest, France) * Alain Plantec (Lisyc, University of Brest, France) PROGRAM COMMITTEE: * Gabriela Arevalo * Marcus Denker * Johan Fabry * Lukas Renggli * Hernan Wilkinson * Damien Cassou * Alexandre Bergel * Jordi Delgado * Johan Brichau

March 21, 2011

Re: [Pharo-project] [Pharo-users] Do you have a tool that works on Pharo ?

by Dale Henrichs

Alexandre, I agree that symbolic versions should be used in load expressions (when defined), but that should be #'stable', with some missing parens: ((Smalltalk at: #ConfigurationOfOCompletion) project version: #'stable') load. Dale On Mar 21, 2011, at 4:00 AM, Alexandre Bergel wrote: Shouldn't it be: (Smalltalk at: #ConfigurationOfOCompletion) project version: 'stable' load. Instead? Alexandre Le 21 mars 2011 Ã 03:13, laurent laffont <laurent.laffont(a)gmail.com<mailto:laurent.laffont@gmail.com>> a Ã©crit : Mariano, I've added Autotest. I've seen a lot of Configuration example which won't work because of missing parenthesis: (Smalltalk at: #ConfigurationOfOCompletion) project version: '1.1.2' load. should be ((Smalltalk at: #ConfigurationOfOCompletion) project version: '1.1.2') load. I cannot fix it now - must go to work. Laurent On Sun, Mar 20, 2011 at 11:40 PM, Mariano Martinez Peck <<mailto:marianopeck@gmail.com>marianopeck(a)gmail.com<mailto:marianopeck@gmail.com>> wrote: I've added: - Gofer - Monticello - Metacello - Fuel If you can check and improve it..please do. It only took me 30 mins. Cheers Mariano On Sun, Mar 20, 2011 at 11:12 PM, Mariano Martinez Peck <<mailto:marianopeck@gmail.com>marianopeck(a)gmail.com<mailto:marianopeck@gmail.com>> wrote: I forgot...If someone answer "but you can browse the MetecelloRepository" or "XX" or "blah"....the answer is that we are not targeting the same people. Someone that knows how that he has to browse MetacelloRepository, probably knows how to install the software, what it is, etc. With this page (after, moved to the pharo website) we want to targe business and new comers. Imagine someone arriving to Pharo and asking himseld "mmmmm does Pharo have XXX that I have in YYY language? ". So the idea is to show all the available tools. Cheers Mariano On Sun, Mar 20, 2011 at 10:42 PM, StÃ©phane Ducasse <<mailto:stephane.ducasse@inria.fr>stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: thanks mariano this is a good initiative. Stef On Mar 20, 2011, at 10:22 PM, Mariano Martinez Peck wrote: > ifTrue: [ self writeOnPharoBook: aTool] > > We need to improve our documentation. Right now, we have a collaborative book where everyone can join and write: <http://book.pharo-project.org/> http://book.pharo-project.org/ > > Here we have a list of tools that run on Pharo: <http://book.pharo-project.org/book/PharoTools> http://book.pharo-project.org/book/PharoTools > and it is REALLY important to have such list updated and maintained. > > So, if you have a tool that works in pharo and it is not there, please add it. If you don't have a user, I can create one for you. If you are TOO lazy, you can send by email the text to me and I write it. > > Thanks > > Mariano

March 21, 2011

Re: [Pharo-project] [squeak-dev] [UPD] NativeBoost runs on new Cog VMs

by Igor Stasenko

On 21 March 2011 15:34, Bert Freudenberg <bert(a)freudenbergs.de> wrote: > On 21.03.2011, at 14:09, Igor Stasenko wrote: > >> It sounds as contradiction to me. From one side you want to make VM >> being responsible for certain level of security, but from another >> side, you want it to be open for "insecure" stuff like NativeBoost. >> Apparently you can't have both at once. You should choose one. >> Unless you change VM to disable external module loading mechanism, >> there is no any security guarantees, only imaginable ones. >> I could download plugin from web, place it into 'secure' directory and >> then tell VM to load it as external plugin. > > If the VM sandbox is enabled, file access is restricted to a single directory. So you cannot write the plugin to the plugin directory. > i can hardly imagine a sandbox which allows to write files on file system. How much you allowed to write? What if it will just consume all disk space? But ok. I understand that there are certain security model exists in VM. One problem with SecurityPlugin that its not really a plugin but instead an integral part of VM, because it is hardwired with many other plugins who using it. I wonder why each of the involved plugins don't implement own, in-place security mechanisms instead. > (if there are problems with the current implementation, we should fix those, obviously) > Well, if you can crash VM using simple #become, or infinite recursion.. who cares about the rest? :) >> Â And where is your command-line option(s) now? > > This has nothing to do with command line options. The sandbox is enabled by a primitive. Etoys enables it before downloading code. There is no way to disable it once engaged. > How about this: - a single primitive which once activated, freezes the VM's plugin set. No new plugins can be loaded/initialized (even internal ones). Then at startup time, first thing you do is checking if you have all plugins you need for your application to work, and for the rest you don't care and simply disabling plugin loading mechanism. In this way, VM could carry anything, but you have a precise control what you want to use. >> For things like NativeBoost, it is responsibility of developer(s) , >> what level of security is desirable/enough for them. >> In this regard, VM is just a tool which developers using. > > Yes, but the virtual machine defines the boundary > For me, as a developer i prefer an OS to be the boundary, not VM. >> And may i ask, why you don't want to put a security measures at >> language side? You can disable or completely remove compiler. > > Not if you want to allow the user to write code. > You can control what you compiling. For instance in sandbox mode you can simply reject compiling code which having primitive invocations. >> You can >> disable a primitives which allow doing "nasty" stuff, >> and of course you can make it controllable from command line. And >> because it is at language side, it is much easier to maintain and fix >> and develop in general. So, why not? > > That is precisely what the SecurityPlugin is designed to do. It is very simple, but all VM extensions (like NativeBoost) would have to use it. > That approach won't scale. Patching SecurityPlugin every time someone implements new plugin... it won't work. IMO individual plugins should provide their own security control mechanisms, if necessary. >> I am really enjoying Â that smalltalk has a wide open architecture, but >> at the same time it missing one simple thing: a 'deployment' mode, >> where you have certain security guarantees out of the box. >> So that's an open question, why we never had that in Squeak.. VM >> cannot do such magic, it is too stupid and cannot really tell if given >> sequence of bytecodes/class format/external plugin are secure enough >> or not. >> This logic is best to be put at image side where you can reason about >> it much easier because you have reflection ( and smalltalk instead of >> C :) > > The VM is the interface between Smalltalk code and the outside world. Traditionally we have been keeping this interface as small as possible. It's an ideal place to ensure that bad things won't happen. VM extensions like FFI, OSProcess, NativeBoost allows code to circumvent the safe environment of the VM. > And "keeping as small as possible" to me sounds "do not put extra complexity to VM, if you can do it at language side". That what i was trying to say. >>> It would be a shame if e.g. Etoys would have to ship its own VM because you made it less secure in newer versions. After all, it was Etoys that convinced all the major Linux distros to even include a VM. >>> >> >> No no no.. Please stop looking at VM as a black-box with two inputs >> and one TV output. This approach is too naive and will never pass any >> real-world testing, moreover it hinders any progress towards improving >> state of art. >> If you approach with our "standard" VM to some serious guys, first >> thing they will do is to ask a security expert to evaluate it.. >> And then any your proposal which is based on such technology will be >> rejected instantly, and i fear that project budget will be spent on >> making same thing but in java. > > By widening the VM interface you make security analysis even harder. Or even unnecessary, by allowing FFI or arbitrary native code there is no security anyway. > Hmm.. where you draw conclusion that i am for widening VM interface? In contrary i am against it, i am for putting things at language side, and leave only essential ones at VM. >> So, it is a shame that we don't have a good answer to tough guys, and >> instead of really looking how to make system sound and secure, we're >> like sitting ducks with all these command-line options, which can be >> cracked by >> some clever guy in few minutes. > > I have no idea what your beef with command-line options is. It's a red herring anyway. It was proposed by Levente up in this thread to "control" security by command-line argument(s). > Etoys does not use security-related command-line options. > Yeah. Good. :) >> In my vision, VM should be made a dynamically loadable library with >> nice API to interact with host application. Currently we have a >> monolithic VM, which is host and library in one. But in future i'd >> like (and not just me btw) to have >> VM which can be easily embedded into a host application, and then host >> application can control security as well as many other aspects. > > So I need a C compiler to build my apps instead of doing it in Smalltalk? No thank you. I do not share that vision. > Heh.. neither do i. But world is imperfect and we have to make some compromises. >> For things like browser plugin, you simply can't use same things for >> everything. > > I'm sorry, but that's bullshit. The browser plugin executes the same VM binary as a standalone app. > You cannot use same thing in every possible scenario. Browser was just a first example came to my mind. >> And so, we should provide a way for making it easy to >> customize VM for own purpose(s), >> but at same time make it flexible enough to make forking pointless. > > Precisely. And what I want is run-time customization, not compile-time. > So, again, why a language-side runtime customization is not good enough for you? >> And that's exactly why we building an infrastructure for VMs: it will >> enable us to build own custom VMs in much easier, much less painful >> and much more controllable way. > > I very much like the build infrastructure you are setting up. It's very useful for development, for working together, for shorter turn-around times etc. > > But that is totally unrelated to the question how many different Linux packages there should be for the VM. Because those packages are not built by your Hudson installation. They are built by the Fedora maintainer, the Debian packager, etc. > > Do you know how many different Python interpreters there are in a typical Linux distro? > Never interested.. Just asked around , people counting 4 or 5 different interpreters. But i don't care about standalone interpreter/VM. Now take a look at Lua. >> And for Etoys this is a way to go: you can share the same code base, >> but in own corner you could have mods, which will disable or stub-out >> unwanted/insecure functionality. > > It is reasonably simple to just have a flag in the VM to disable the insecure parts. Why would I need a C compiler to do that? Why can't we share even more than just the code base? > No. I'm not taking about disabling it. I am talking about _not_ including it. You cannot use something which is not there, and therefore you don't have to put extra security measures around it. Just applying the Principle of least privilege. (http://en.wikipedia.org/wiki/Principle_of_least_privilege) >> In that way you can be confident that application you distributing is secure, >> and instead of arguing with me (or some other VM developer guy) what >> is best for you, you can do it yourself without much stress. :) > > So this is you telling me to just shut up? No. I just telling what i thinking would be best in terms of security. I meant that if you can control it by yourself without asking people to do(or not do) something, then you are in much better position. And of course i didn't meant to insult you. >When all I am asking for is to make things configurable at runtime (in true Smalltalk spirit) rather than having to compile my own VM? I'm not arguing against native boost or FFI or the like, but simply for an option to disable it at runtime. > Point taken. >> Just don't tell me that you don't want this, or you never considered >> it as a good perspective. ( I won't believe you anyways ;) > > Why wouldn't you believe it? I went to *considerable* effort to *not* bundle a VM with Etoys. That would have been much easier for me indeed, and in fact we used to bundle a Linux VM until about 3 years ago. I then built the original Etoys RPM so that it depends on a VM RPM. And thanks to that effort (and people doing the packaging work) today we have Etoys and VM packages in many Linux distros: > > Â Â Â Â http://pkgs.org/package/squeak-vm > > Call me a dreamer, but I find it important to being a good player in the wider open-source community. And that community has evolved considerably from "download the sources and configure it to taste and compile your own". A single binary package is standard nowadays. You don't really recompile Firefox to change a preferences, do you? > So, you are at another side of extreme. You want a universal binary which solves all of your problems. But it is illusion: it certainly can't solve all problems of all people. What works for you may not work for others and vise verse. I see nothing bad in allowing people to deviate from "standard" VM, as long as they stay in community and contribute userful pieces back. So, i want both ways to be possible: we could have universal (kind of) VM, but should also make sure its easy to customize VM in case of need. Thanks for discussion. (I am really interested in what you think about providing a feature to "freeze" plugin set, which i described above). -- Best regards, Igor Stasenko AKA sig.

March 21, 2011

Re: [Pharo-project] Issue 3108 in pharo: Project >> updateLocaleDependents dependent on MenuIcons

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3108 by marcus.d...(a)gmail.com: Project >> updateLocaleDependents dependent on MenuIcons http://code.google.com/p/pharo/issues/detail?id=3108 This has been fixed

March 21, 2011

Re: [Pharo-project] Issue 3840 in pharo: ivar errorHandler in Process seems to be unused

by pharo＠googlecode.com

Updates: Status: FixProposed Labels: Milestone-1.3 Comment #1 on issue 3840 by marcus.d...(a)gmail.com: ivar errorHandler in Process seems to be unused http://code.google.com/p/pharo/issues/detail?id=3840 Attached changeset deprecate the accessors Attachments: ProcessErrorHandlerDeprecation.1.cs 1.4 KB

March 21, 2011

Re: [Pharo-project] test crashing the cog vm

by Alexandre Bergel

Thanks for this fruitful discussion. Thanks Doru for fixing my test. It was hard to predict this problem, since it went green on my machine. Good job Guys! Alexandre Le 21 mars 2011 Ã 09:57, Toon Verwaest <toon.verwaest(a)gmail.com> a Ã©crit : > Yes you are right! Bytecode validation would be very important here. If you ask me, the VM should only allow verified bytecode to be executed. Here it could have a dual model, where bytecodes are "internalized" whenever you give them to the VM first. At that point they are validated. Once it's internalized, it can't be modified anymore from the outside, since the Smalltalk world doesn't have direct access to the internalized version. All changes to the bytecode "source", needs to be propagated to the VM by re-internalizing it. > > This is exactly the model I'm using in Pinocchio... and that allows us to not use bytecodes in the first place :) You just need a way to map the internal version back onto the highlevel version for debugging. (We don't verify the bytecode yet though). > > Bytecode verification btw shouldn't be too hard. You just need to make sure that all the codes are safe for the instance at hand, and for the method contexts you create. Anything else is just a runtime semantical error which you can't guarantee, since you don't know what the programmer is trying to do. We don't verify it yet since I'm still designing my register-based bytecodes; and since I atm have too much work at hand :) > > cheers, > Toon > > On 03/21/2011 02:22 PM, Igor Stasenko wrote: >> On 21 March 2011 13:14, Toon Verwaest<toon.verwaest(a)gmail.com> wrote: >>> I couldn't agree more! >>> >>> However, here the problem is not that the format isn't a correct format. The >>> problem is that a bytecode is activated that is incompatible with the >>> instance format. So basically on every bytecode accessing an instance you >>> would have to check if this is a valid access. And as we all know, Smalltalk >>> avoids this; it makes things faster :) >>> >> In other words, a responsibility of having correct bytecode lies on >> image side, not on VM side. >> >> Adding a bytecode verifier to VM will be a lot of work.. And of course >> it could verify it only when you installing a method, >> not when you activating it. >> >>> Toon >>> >>> On 03/21/2011 12:49 PM, Igor Stasenko wrote: >>>> On 21 March 2011 11:29, Tudor Girba<tudor.girba(a)gmail.com> wrote: >>>>> Thanks, Toon! >>>>> >>>>> I changed the code to explicitly set the format, and it seems to fix the >>>>> problem: >>>>> >>>>> cls := Class new superclass: MooseElement; >>>>> setFormat: MooseElement format; >>>>> yourself. >>>>> cls compileSilently: 'mooseName ^ 1/0'. >>>>> element := cls new. >>>>> >>>>> Is this correct? >>>>> >>>> Yes, you should pay attention to have correct format. >>>> But of course VM could also be more cautios and verify if your class >>>> are well formed before creating an instance of it.. >>>> >>>> >>>> >>>>> Cheers, >>>>> Doru >>>>> >>>> >>> >>> >> >> > >

March 21, 2011

Re: [Pharo-project] [squeak-dev] [UPD] NativeBoost runs on new Cog VMs

by Bert Freudenberg

On 21.03.2011, at 14:09, Igor Stasenko wrote: > It sounds as contradiction to me. From one side you want to make VM > being responsible for certain level of security, but from another > side, you want it to be open for "insecure" stuff like NativeBoost. > Apparently you can't have both at once. You should choose one. > Unless you change VM to disable external module loading mechanism, > there is no any security guarantees, only imaginable ones. > I could download plugin from web, place it into 'secure' directory and > then tell VM to load it as external plugin. If the VM sandbox is enabled, file access is restricted to a single directory. So you cannot write the plugin to the plugin directory. (if there are problems with the current implementation, we should fix those, obviously) > And where is your command-line option(s) now? This has nothing to do with command line options. The sandbox is enabled by a primitive. Etoys enables it before downloading code. There is no way to disable it once engaged. > For things like NativeBoost, it is responsibility of developer(s) , > what level of security is desirable/enough for them. > In this regard, VM is just a tool which developers using. Yes, but the virtual machine defines the boundary > And may i ask, why you don't want to put a security measures at > language side? You can disable or completely remove compiler. Not if you want to allow the user to write code. > You can > disable a primitives which allow doing "nasty" stuff, > and of course you can make it controllable from command line. And > because it is at language side, it is much easier to maintain and fix > and develop in general. So, why not? That is precisely what the SecurityPlugin is designed to do. It is very simple, but all VM extensions (like NativeBoost) would have to use it. > I am really enjoying that smalltalk has a wide open architecture, but > at the same time it missing one simple thing: a 'deployment' mode, > where you have certain security guarantees out of the box. > So that's an open question, why we never had that in Squeak.. VM > cannot do such magic, it is too stupid and cannot really tell if given > sequence of bytecodes/class format/external plugin are secure enough > or not. > This logic is best to be put at image side where you can reason about > it much easier because you have reflection ( and smalltalk instead of > C :) The VM is the interface between Smalltalk code and the outside world. Traditionally we have been keeping this interface as small as possible. It's an ideal place to ensure that bad things won't happen. VM extensions like FFI, OSProcess, NativeBoost allows code to circumvent the safe environment of the VM. >> It would be a shame if e.g. Etoys would have to ship its own VM because you made it less secure in newer versions. After all, it was Etoys that convinced all the major Linux distros to even include a VM. >> > > No no no.. Please stop looking at VM as a black-box with two inputs > and one TV output. This approach is too naive and will never pass any > real-world testing, moreover it hinders any progress towards improving > state of art. > If you approach with our "standard" VM to some serious guys, first > thing they will do is to ask a security expert to evaluate it.. > And then any your proposal which is based on such technology will be > rejected instantly, and i fear that project budget will be spent on > making same thing but in java. By widening the VM interface you make security analysis even harder. Or even unnecessary, by allowing FFI or arbitrary native code there is no security anyway. > So, it is a shame that we don't have a good answer to tough guys, and > instead of really looking how to make system sound and secure, we're > like sitting ducks with all these command-line options, which can be > cracked by > some clever guy in few minutes. I have no idea what your beef with command-line options is. It's a red herring anyway. Etoys does not use security-related command-line options. > In my vision, VM should be made a dynamically loadable library with > nice API to interact with host application. Currently we have a > monolithic VM, which is host and library in one. But in future i'd > like (and not just me btw) to have > VM which can be easily embedded into a host application, and then host > application can control security as well as many other aspects. So I need a C compiler to build my apps instead of doing it in Smalltalk? No thank you. I do not share that vision. > For things like browser plugin, you simply can't use same things for > everything. I'm sorry, but that's bullshit. The browser plugin executes the same VM binary as a standalone app. > And so, we should provide a way for making it easy to > customize VM for own purpose(s), > but at same time make it flexible enough to make forking pointless. Precisely. And what I want is run-time customization, not compile-time. > And that's exactly why we building an infrastructure for VMs: it will > enable us to build own custom VMs in much easier, much less painful > and much more controllable way. I very much like the build infrastructure you are setting up. It's very useful for development, for working together, for shorter turn-around times etc. But that is totally unrelated to the question how many different Linux packages there should be for the VM. Because those packages are not built by your Hudson installation. They are built by the Fedora maintainer, the Debian packager, etc. Do you know how many different Python interpreters there are in a typical Linux distro? > And for Etoys this is a way to go: you can share the same code base, > but in own corner you could have mods, which will disable or stub-out > unwanted/insecure functionality. It is reasonably simple to just have a flag in the VM to disable the insecure parts. Why would I need a C compiler to do that? Why can't we share even more than just the code base? > In that way you can be confident that application you distributing is secure, > and instead of arguing with me (or some other VM developer guy) what > is best for you, you can do it yourself without much stress. :) So this is you telling me to just shut up? When all I am asking for is to make things configurable at runtime (in true Smalltalk spirit) rather than having to compile my own VM? I'm not arguing against native boost or FFI or the like, but simply for an option to disable it at runtime. > Just don't tell me that you don't want this, or you never considered > it as a good perspective. ( I won't believe you anyways ;) Why wouldn't you believe it? I went to *considerable* effort to *not* bundle a VM with Etoys. That would have been much easier for me indeed, and in fact we used to bundle a Linux VM until about 3 years ago. I then built the original Etoys RPM so that it depends on a VM RPM. And thanks to that effort (and people doing the packaging work) today we have Etoys and VM packages in many Linux distros: http://pkgs.org/package/squeak-vm Call me a dreamer, but I find it important to being a good player in the wider open-source community. And that community has evolved considerably from "download the sources and configure it to taste and compile your own". A single binary package is standard nowadays. You don't really recompile Firefox to change a preferences, do you? - Bert -

March 21, 2011

Re: [Pharo-project] [Vm-dev] VM Maker: VMMaker-oscog.52.mcz

by Norbert Hartl

Just for the record. If anyone is having his own monticello repository like me using apache a rule RewriteEngine On RewriteCond %{REQUEST_METHOD} ^PUT RewriteCond %{REQUEST_FILENAME} -f RewriteRule . - [F,L] will prevent overwriting of packages. The full story is at http://norbert.hartl.name/blog/public-monticello-repository Norbert

March 21, 2011