February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Trusting Trust

by Ben Coman

You are right. The compiler binary described in the scenario corresponds to the whole of the Smalltalk binary image. Nicolas Cellier wrote: > Do you really think that the compiler is the real Achille heal in an > image where everything work by message send? > IMO, the compiler is much less central than in other languages. > > What I would do to fool users and tools would just be to hack a few > methods like #methodDict (just like Stephane proposed for example). > I would arrange to not answer the true methodDict but a fake for a few classes. > Create a class var in Behavior, like FakedBehaviors := Dictionary new. > Then modify Behavior>>methodDict > ^FakedBehaviors at: self ifAbsent: [methodDict] > > Then you can start populating FakedBehaviors. > Of course, you would begin by faking Behavior itself to not be caught. > > Then you could also arrange to falsify Smalltalk at: > #MethodDictionary, just to avoid a sneaker to try (MethodDictionary > allInstances), and let a class var hook in Behavior refer to the > TrueMethodDictionary etc... fake instVarAt: to never return the true > methodDict, fake the messages concerning Behavior classPool to hide > your piracy... Or better, don't use a class var at all, but just hack > a literal in the hacked method... Faking the whole IDE is a lot more > work (think of inspectors, debuggers, Object tracing etc..), but > really is possible, and removing clues is also possible, it's just a > bootstrap problem ;) > > There is no in-image parade, you'd have to use tracing from outside. > > Nicolas > > 2012/2/8 Ben Coman <btc(a)openinworld.com>: > >> Frank Shearar wrote: >> >>> On 8 February 2012 10:33, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> >>>> Am 08.02.2012 um 11:12 schrieb Philippe Marschall: >>>> >>>> >>>>> On 02/08/2012 10:43 AM, Marcus Denker wrote: >>>>> >>>>> >>>>>> On Feb 8, 2012, at 10:39 AM, Philippe Marschall wrote: >>>>>> >>>>>> >>>>>> >>>>>>>> well I do not think so since we can all read the code. >>>>>>>> >>>>>>>> >>>>>>> No, read the argument again. If the compiler is compromised and the >>>>>>> other tools in the image are compromised you can't read the code because the >>>>>>> tools don't display you the actual code. >>>>>>> >>>>>>> >>>>>>> >>>>>> But this stays the same with a boot-strap, as you will use a compomised >>>>>> compiler to bootstrap the bootstrap. >>>>>> >>>>>> There is nothing you can do against it. It's true for GCC or Java, too. >>>>>> >>>>>> >>>>> Yes, but read the links on how you can use a different, second compiler. >>>>> >>>>> >>>>> >>>> And what if the second compiler is compromised, too? An operating system >>>> is also a virtual environment. So what if that environment is rooted, lives >>>> in another shell? >>>> The "what if"-question in a security context can be played infinitely. >>>> The compromisable areas are only defined in opposite where you have put some >>>> trust. Or saying it in other words: There is no trust until you put it >>>> somewhere. >>>> >>>> Norbert >>>> >>>> >>> Indeed; that's precisely the point: both compilers need to be >>> subverted in the SAME way in order for you not to notice. The chances >>> of that happening are much lower than not anything at all! >>> Regarding "There is no trust until you put it somewhere", my favourite >>> webcomic (http://www.schlockmercenary.com/) puts it thusly: "A little >>> trust goes a long way. The less you use, the further you'll go." >>> >>> But of course it takes time and effort into removing the trust you've >>> placed in your compiler. It would not be unreasonable for Pharo to say >>> "yes, we know that we're trusting the compiler" simply because there >>> are other, more pressing matters. >>> >>> frank >>> >>> >> Security is not an absolute - it is a spectrum. My usual example is >> comparing at one extreme keeping all your savings in shoe boxes under you >> bed. Very simple to use but also easily subverted. At the other extreme >> you keep all your savings behind several bank vault doors under a mountain. >> 'Almost' absolutely secure but not very usable. In practice the line is >> drawn somewhere between by balancing risks, effort and usability. It is >> useful to consider each extreme to help balancing these conflicting >> priorities. >> >> I like the term "practical paranoia." Think paranoid to be aware of the >> issues, then decide based on practical matters what to do about them. The >> Pharo image is a single binary evolving over more than twenty years. At one >> extreme you implicitly trust _every_ unknown hand that ever had access to >> the trunk. At the other extreme "most" people _are_ good people. Pharo >> certainly has more pressing matters, but the aim should be to reduce the >> surface area of attack/trust where possible. A single bootstrap step >> without Diverse Double-Compiling goes a long way to achieving this. >> >> StÃ©phane Ducasse wrote: >> >>> On Feb 8, 2012, at 9:35 AM, Philippe Marschall wrote: >>> >>> >>> >>>> I think it's worse in Pharo because you're never bootstrapping from >>>> source. From all you know the tools could be subverted to show you a >>>> different code than is actually running in the system. >>>> >>>> >>> well I do not think so since we can all read the code. >>> If you have a bootstrap in C or assembly it does make me more confident. >>> >>> So the argument while nice at first sight does not hold a second. Now we >>> will get a bootstrapped version of pharo believe me :) >>> >>> >>> >> That is good to hear. My contemplation of this stemmed from seeing the stub >> for bootstrapping in the PharoVision document. This dredged up a memory of >> reading the articles long ago and was was interested in views of how it >> applied today. While there are a lot of other benefits from bootstrapping, >> security provides just one more reason to justify the effort. >> Thanks for your thought, >> Cheers, -ben >> >> >> >> > > >

Feb. 8, 2012

Re: [Pharo-project] Trusting Trust

by Nicolas Cellier

Do you really think that the compiler is the real Achille heal in an image where everything work by message send? IMO, the compiler is much less central than in other languages. What I would do to fool users and tools would just be to hack a few methods like #methodDict (just like Stephane proposed for example). I would arrange to not answer the true methodDict but a fake for a few classes. Create a class var in Behavior, like FakedBehaviors := Dictionary new. Then modify Behavior>>methodDict ^FakedBehaviors at: self ifAbsent: [methodDict] Then you can start populating FakedBehaviors. Of course, you would begin by faking Behavior itself to not be caught. Then you could also arrange to falsify Smalltalk at: #MethodDictionary, just to avoid a sneaker to try (MethodDictionary allInstances), and let a class var hook in Behavior refer to the TrueMethodDictionary etc... fake instVarAt: to never return the true methodDict, fake the messages concerning Behavior classPool to hide your piracy... Or better, don't use a class var at all, but just hack a literal in the hacked method... Faking the whole IDE is a lot more work (think of inspectors, debuggers, Object tracing etc..), but really is possible, and removing clues is also possible, it's just a bootstrap problem ;) There is no in-image parade, you'd have to use tracing from outside. Nicolas 2012/2/8 Ben Coman <btc(a)openinworld.com>: > Frank Shearar wrote: >> >> On 8 February 2012 10:33, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> >>> Am 08.02.2012 um 11:12 schrieb Philippe Marschall: >>> >>>> >>>> On 02/08/2012 10:43 AM, Marcus Denker wrote: >>>> >>>>> >>>>> On Feb 8, 2012, at 10:39 AM, Philippe Marschall wrote: >>>>> >>>>> >>>>>>> >>>>>>> well I do not think so since we can all read the code. >>>>>>> >>>>>> >>>>>> No, read the argument again. If the compiler is compromised and the >>>>>> other tools in the image are compromised you can't read the code because the >>>>>> tools don't display you the actual code. >>>>>> >>>>>> >>>>> >>>>> But this stays the same with a boot-strap, as you will use a compomised >>>>> compiler to bootstrap the bootstrap. >>>>> >>>>> There is nothing you can do against it. It's true for GCC or Java, too. >>>>> >>>> >>>> Yes, but read the links on how you can use a different, second compiler. >>>> >>>> >>> >>> And what if the second compiler is compromised, too? An operating system >>> is also a virtual environment. So what if that environment is rooted, lives >>> in another shell? >>> The "what if"-question in a security context can be played infinitely. >>> The compromisable areas are only defined in opposite where you have put some >>> trust. Or saying it in other words: There is no trust until you put it >>> somewhere. >>> >>> Norbert >>> >> >> >> Indeed; that's precisely the point: both compilers need to be >> subverted in the SAME way in order for you not to notice. The chances >> of that happening are much lower than not anything at all! >> Â Regarding "There is no trust until you put it somewhere", my favourite >> webcomic (http://www.schlockmercenary.com/) puts it thusly: "A little >> trust goes a long way. The less you use, the further you'll go." >> >> But of course it takes time and effort into removing the trust you've >> placed in your compiler. It would not be unreasonable for Pharo to say >> "yes, we know that we're trusting the compiler" simply because there >> are other, more pressing matters. >> >> frank >> > > Security is not an absolute - it is a spectrum. Â My usual example is > comparing at one extreme keeping all your savings in shoe boxes under you > bed. Â Very simple to use but also easily subverted. Â At the other extreme > you keep all your savings behind several bank vault doors under a mountain. > Â 'Almost' absolutely secure but not very usable. Â In practice the line is > drawn somewhere between by balancing risks, effort and usability. Â It is > useful to consider each extreme to help balancing these conflicting > priorities. > > I like the term "practical paranoia." Â Think paranoid to be aware of the > issues, then decide based on practical matters what to do about them. Â The > Pharo image is a single binary evolving over more than twenty years. Â At one > extreme you implicitly trust _every_ unknown hand that ever had access to > the trunk. Â At the other extreme "most" people _are_ good people. Â Pharo > certainly has more pressing matters, but the aim should be to reduce the > surface area of attack/trust where possible. Â A single bootstrap step > without Diverse Double-Compiling goes a long way to achieving this. > > StÃ©phane Ducasse wrote: >> >> On Feb 8, 2012, at 9:35 AM, Philippe Marschall wrote: >> >> >>> >>> I think it's worse in Pharo because you're never bootstrapping from >>> source. From all you know the tools could be subverted to show you a >>> different code than is actually running in the system. >>> >> >> >> well I do not think so since we can all read the code. >> If you have a bootstrap in C or assembly it does make me more confident. >> >> So the argument while nice at first sight does not hold a second. Now we >> will get a bootstrapped version of pharo believe me :) >> >> > > That is good to hear. Â My contemplation of this stemmed from seeing the stub > for bootstrapping in the PharoVision document. Â This dredged up a memory of > reading the articles long ago and was was interested in views of how it > applied today. Â While there are a lot of other benefits from bootstrapping, > security provides just one more reason to justify the effort. > Thanks for your thought, > Cheers, -ben > > >

Feb. 8, 2012

Re: [Pharo-project] Migrating to Gemstone

by StÃ©phane Ducasse

look into the gofer chapter on pbe2 Stef On Feb 7, 2012, at 8:29 PM, Benjamin wrote: > Would it be possible to write some kind of import / migrate script for ss3.gemstone.com? > > The following lines copy the complete version history to an *existing* project on gemstone: > > Gofer new > url: 'http:/squeaksource.com/FOO'; > package: 'FOO'; package: 'BAR'; ... > url: 'http://ss3.gemstone.com/ss/FOO'; > push > > but that still requires me to define all packages I want to import *and* to create a new > project on gemstone.... > > I would really love to see a one-click experience here? > > best > ben & cami

Feb. 8, 2012

Re: [Pharo-project] It would be me first

by StÃ©phane Ducasse

I passed the info to nicolas and he will probably reply. stef On Feb 8, 2012, at 1:11 AM, Igor Stasenko wrote: > On 7 February 2012 21:35, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >> >> On 07 Feb 2012, at 16:58, Frank Shearar wrote: >> >>> Looks like it's dead. The machine's alive, and the HTTP server's alive though. >> >> Where is SmalltalkHub ? > +1 > >> Last time it was publically available for testing it looked quite good. >> What is holding it back ? > > +2 > > while ss3 is better than sqs, SmalltalkHub is more appeal to me. :) > >> Sven > > > > -- > Best regards, > Igor Stasenko. >

Feb. 8, 2012

Re: [Pharo-project] better Behavior>>methodDict

by Nicolas Cellier

I think that my first proposition was more a negative speculation than a really useful comment. It was more to emphasize the hackish nature of this change than to help future readers ;) If you really want to include this change, I think you shall mention the true purpose of this hack, and I guess this would be something like: "In order to prevent the complaints of tools and IDE unaware of this feature, we try to fool them by providing an empty MethodDictionary." Eventually, you could mention your expected outcomes: "This will hopefully work in most cases, but the tools will loose the ability to modify the behaviour of such class." Of course, I don't know the context into which you want to use cannotInterpret: so it is hard to tell if the system deserve such hack. I guess you might also add a message stating whether the class is subject to such cannotInterpret: hook or not, maybe something like Behavior>canInterpret "If methodDict instance variable is nil, this Behavior cannot interpret any message. In this case, every message sent to my instances will be redirected to a cannotInterpret: send, starting look-up at etc..." ^methodDict notNil Nicolas 2012/2/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > mariano can you add a bug entry and we integrate it. > > Stef > > On Feb 7, 2012, at 1:00 AM, Nicolas Cellier wrote: > >> How many senders of #methodDict would miss-behave? >> No risk to throw away a freshly basicAddedSelector:withMethod: ? >> Or should the IDE be aware of the cannotInterpret: experiments ? >> >> Maybe the comment should be (seriously): >> >> "When methodDict instance variable of a class is nil, the VM will >> redirect any message send to an instance by sending the message >> cannotInterpret: to the receiver but starting the look up in the >> superclass. >> NDLR: Or is it to the next superclass having a non nil methodDict? >> Since most senders of #methodDict message are unaware of this feature, >> we try to fool them by providing a new empty MethodDictionary in this >> case, which shall hopefully make them apparently work. Whether >> undesirable side effect might occur or not, silently or not, is >> unspecified. Cross your fingers..." >> >> Nicolas >> >> 2012/2/6 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>> >>> >>> On Mon, Feb 6, 2012 at 10:17 PM, StÃ©phane Ducasse >>> <Stephane.Ducasse(a)inria.fr> wrote: >>>> >>>> Hi mariano >>>> >>>> I have the impression that methodDict should be redefined as you propose >>>> it because else it does not work well with the cannotInterpret hook. I >>>> suggest to redefine methodDict as follow. notice the cool comment!!! >>>> If this is ok -> open a bug entry. >>>> >>>> >>>> Behavior >> methodDict >>>> Â Â Â Â "The method dictionary of a class can be nil when we want to use >>>> the cannotInterpret: hook. Indeed when a class dictionary is nil, the VM >>>> sends the message cannotInterpret: to the receiver but starting the look up >>>> in the superclass. Now the system relies that when the message methodDict is >>>> sent to a class a method dictionary is returned. The implementation below >>>> makes sure that a method dictionary can be nilled but does not confuse the >>>> system." >>>> >>>> Â Â Â Â methodDict == nil ifTrue: [^ MethodDictionary new ]. >>>> Â Â Â Â ^ methodDict >>>> >>> >>> For me that's perfect and avoids an override in my code :) >>> >>> Maybe we can do: >>> >>> >>> Behavior >> methodDict >>> Â Â Â Â "The method dictionary of a class can be nil when we want to use the >>> cannotInterpret: hook. Indeed when a class dictionary is nil, the VM sends >>> the message cannotInterpret: to the receiver but starting the look up in the >>> superclass. Now the system relies that when the message methodDict is sent >>> to a class a method dictionary is returned. The implementation below makes >>> sure that a method dictionary can be nilled but does not confuse the >>> system." >>> >>> Â Â Â Â methodDict == nil ifTrue: [^ self manageMDFault ]. >>> Â Â Â Â ^ methodDict >>> >>> >>> Behavior >> manageMDFault >>> >>> ^ MethodDictionary new >>> >>> >>> That way subclasses can change it without needing an override. >>> >>> but both solutions are fine with me. Other opinions? >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> > >

Feb. 8, 2012

Re: [Pharo-project] better Behavior>>methodDict

by StÃ©phane Ducasse

mariano can you add a bug entry and we integrate it. Stef On Feb 7, 2012, at 1:00 AM, Nicolas Cellier wrote: > How many senders of #methodDict would miss-behave? > No risk to throw away a freshly basicAddedSelector:withMethod: ? > Or should the IDE be aware of the cannotInterpret: experiments ? > > Maybe the comment should be (seriously): > > "When methodDict instance variable of a class is nil, the VM will > redirect any message send to an instance by sending the message > cannotInterpret: to the receiver but starting the look up in the > superclass. > NDLR: Or is it to the next superclass having a non nil methodDict? > Since most senders of #methodDict message are unaware of this feature, > we try to fool them by providing a new empty MethodDictionary in this > case, which shall hopefully make them apparently work. Whether > undesirable side effect might occur or not, silently or not, is > unspecified. Cross your fingers..." > > Nicolas > > 2012/2/6 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >> >> On Mon, Feb 6, 2012 at 10:17 PM, StÃ©phane Ducasse >> <Stephane.Ducasse(a)inria.fr> wrote: >>> >>> Hi mariano >>> >>> I have the impression that methodDict should be redefined as you propose >>> it because else it does not work well with the cannotInterpret hook. I >>> suggest to redefine methodDict as follow. notice the cool comment!!! >>> If this is ok -> open a bug entry. >>> >>> >>> Behavior >> methodDict >>> "The method dictionary of a class can be nil when we want to use >>> the cannotInterpret: hook. Indeed when a class dictionary is nil, the VM >>> sends the message cannotInterpret: to the receiver but starting the look up >>> in the superclass. Now the system relies that when the message methodDict is >>> sent to a class a method dictionary is returned. The implementation below >>> makes sure that a method dictionary can be nilled but does not confuse the >>> system." >>> >>> methodDict == nil ifTrue: [^ MethodDictionary new ]. >>> ^ methodDict >>> >> >> For me that's perfect and avoids an override in my code :) >> >> Maybe we can do: >> >> >> Behavior >> methodDict >> "The method dictionary of a class can be nil when we want to use the >> cannotInterpret: hook. Indeed when a class dictionary is nil, the VM sends >> the message cannotInterpret: to the receiver but starting the look up in the >> superclass. Now the system relies that when the message methodDict is sent >> to a class a method dictionary is returned. The implementation below makes >> sure that a method dictionary can be nilled but does not confuse the >> system." >> >> methodDict == nil ifTrue: [^ self manageMDFault ]. >> ^ methodDict >> >> >> Behavior >> manageMDFault >> >> ^ MethodDictionary new >> >> >> That way subclasses can change it without needing an override. >> >> but both solutions are fine with me. Other opinions? >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >

Feb. 8, 2012

Re: [Pharo-project] Fixed to interrupt behavior

by Ben Coman

Sven Van Caekenberghe wrote: > On 08 Feb 2012, at 11:42, Schwab,Wilhelm K wrote: > > >> Ok, but what about 1.3? Is 1.4 "ready" - last word was to use 1.3, which has some troubles too. >> > > Active Pharo development is happing on the unstable branch, 1.4. > Pharo 1.3 was released a long time ago, as a freeze of the development branch, and after a period of RC testing. > Sometimes critical patches are backported from 1.4 to 1.3, but often that is not possible, it is also a lot of work for the integrators. > > Sven > This is probably a naive view, but I was wondering it the effort of backporting critical patches could be reduced if the development process went... Rather than as I understand it, current 1.3 is frozen and the live trunk continues as unstable 1.4 mixing both planned refactoring and unplanned bug fixes discovered in 1.3. It then takes additional effort to implement those fixes in 1.3 where they were discovered. Not withstanding the ideal of release candidate testing finding these bugs, the reality is that people properly migrate between versions at different rates. Using the stable version for day-in-day-out for weeks on end does exercise code differently than artificial testing during RC phase. Alternatively, 1.3 could be kept the main live version on the continuation integration server. A core developer's local 1.4 refactoring is uploaded to the CI server as a changeset against the live 1.3 version. When this changeset tests okay, it is available to be pulled down by other core developers to update their image. Thus bugs discovered in 1.3 can be fixed in 1.3 and also flow through to 1.4 with the 1.4 refactoring isolated from the 1.3 bug fixes. It is a bit presumptuous of me to be suggesting such changes to the core development process, but my ideas fight me to get out. Perhaps I'll learn something when I get shot down :) On the downside, the added complexity of such a process may introduced additional incremental effort which exceeds the effort backporting selected bug fixes. regards, -ben

Feb. 8, 2012

Re: [Pharo-project] Fixed to interrupt behavior

by Schwab,Wilhelm K

Stef, There are things in 1.4 that I will eventually like, but for now, it is very difficult to use. I had a code holder get dragged and dropped from a browser to the desktop and couldn't get a halo to kill it. Context menus don't work well and lack the polish of earlier versions. My problem is that 1.3 does not appear to be able to break processes, and once Metacello gets running, I lose the ability to open debuggers and process browsers. It is (sorry) basically unusable. On the up side, I did some useful work on Migrate and my 1.1.1 image looks GREAT as a result. Preference changes broke some of my code, and it took me a while to see how to recover those abilities. I now have nice fonts and can much more easily read source :) I will be in a fairly good position as 1.4 stabilizes, but for now, I can't get 1.3 or 1.4 to cooperate. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Wednesday, February 08, 2012 7:39 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Fixed to interrupt behavior 1.4 is stable but we are working on it. STef On Feb 8, 2012, at 11:42 AM, Schwab,Wilhelm K wrote: > Ok, but what about 1.3? Is 1.4 "ready" - last word was to use 1.3, which has some troubles too. > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Marcus Denker [marcus.denker(a)inria.fr] > Sent: Wednesday, February 08, 2012 5:24 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Fixed to interrupt behavior > > On Feb 8, 2012, at 11:22 AM, Schwab,Wilhelm K wrote: > >> Stef, >> >> We are on the same topic then. I am having problems with cmd . on 1.3 - it won't break anything :( >> > it is fixed in 1.4. > > Marcus > > > > -- > Marcus Denker -- http://marcusdenker.de > > >

Feb. 8, 2012

Re: [Pharo-project] Trusting Trust

by Ben Coman

Frank Shearar wrote: > On 8 February 2012 10:33, Norbert Hartl <norbert(a)hartl.name> wrote: > >> Am 08.02.2012 um 11:12 schrieb Philippe Marschall: >> >>> On 02/08/2012 10:43 AM, Marcus Denker wrote: >>> >>>> On Feb 8, 2012, at 10:39 AM, Philippe Marschall wrote: >>>> >>>> >>>>>> well I do not think so since we can all read the code. >>>>>> >>>>> No, read the argument again. If the compiler is compromised and the other tools in the image are compromised you can't read the code because the tools don't display you the actual code. >>>>> >>>>> >>>> But this stays the same with a boot-strap, as you will use a compomised compiler to bootstrap the bootstrap. >>>> >>>> There is nothing you can do against it. It's true for GCC or Java, too. >>>> >>> Yes, but read the links on how you can use a different, second compiler. >>> >>> >> And what if the second compiler is compromised, too? An operating system is also a virtual environment. So what if that environment is rooted, lives in another shell? >> The "what if"-question in a security context can be played infinitely. The compromisable areas are only defined in opposite where you have put some trust. Or saying it in other words: There is no trust until you put it somewhere. >> >> Norbert >> > > Indeed; that's precisely the point: both compilers need to be > subverted in the SAME way in order for you not to notice. The chances > of that happening are much lower than not anything at all! > > Regarding "There is no trust until you put it somewhere", my favourite > webcomic (http://www.schlockmercenary.com/) puts it thusly: "A little > trust goes a long way. The less you use, the further you'll go." > > But of course it takes time and effort into removing the trust you've > placed in your compiler. It would not be unreasonable for Pharo to say > "yes, we know that we're trusting the compiler" simply because there > are other, more pressing matters. > > frank > Security is not an absolute - it is a spectrum. My usual example is comparing at one extreme keeping all your savings in shoe boxes under you bed. Very simple to use but also easily subverted. At the other extreme you keep all your savings behind several bank vault doors under a mountain. 'Almost' absolutely secure but not very usable. In practice the line is drawn somewhere between by balancing risks, effort and usability. It is useful to consider each extreme to help balancing these conflicting priorities. I like the term "practical paranoia." Think paranoid to be aware of the issues, then decide based on practical matters what to do about them. The Pharo image is a single binary evolving over more than twenty years. At one extreme you implicitly trust _every_ unknown hand that ever had access to the trunk. At the other extreme "most" people _are_ good people. Pharo certainly has more pressing matters, but the aim should be to reduce the surface area of attack/trust where possible. A single bootstrap step without Diverse Double-Compiling goes a long way to achieving this. StÃ©phane Ducasse wrote: > On Feb 8, 2012, at 9:35 AM, Philippe Marschall wrote: > > >> I think it's worse in Pharo because you're never bootstrapping from source. From all you know the tools could be subverted to show you a different code than is actually running in the system. >> > > well I do not think so since we can all read the code. > If you have a bootstrap in C or assembly it does make me more confident. > > So the argument while nice at first sight does not hold a second. Now we will get a bootstrapped version of pharo > believe me :) > > That is good to hear. My contemplation of this stemmed from seeing the stub for bootstrapping in the PharoVision document. This dredged up a memory of reading the articles long ago and was was interested in views of how it applied today. While there are a lot of other benefits from bootstrapping, security provides just one more reason to justify the effort. Thanks for your thought, Cheers, -ben

Feb. 8, 2012

[Pharo-project] Trait methods in Nautilus

by Damien Cassou

On Tue, Feb 7, 2012 at 11:52 PM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > For traits method, you have this nice icon ^^ > > What about hiding the methods coming from the traits? We don't show the methods coming from superclasses so I don't see any reason why methods coming from traits should be visible. And yes, I'm aware that trait methods are in the method dictionary of the class, but this is implementation detail :-) -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Feb. 8, 2012