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

Re: [Pharo-project] Fixed to interrupt behavior

by StÃ©phane Ducasse

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] Migrating to Gemstone

by Camillo Bruni

Feb. 8, 2012

Re: [Pharo-project] Trusting Trust

by drush66

Well, it's the turtles all the way down, and you always need a peace of trust to step on to keep the whole thing. So there is no absulute security, but I guess this is not a new concept. But IMHO, if someone would like to reduce (not eliminate) the risks, Smalltalk could make it less daunting. Smalltalk VM is small, and well documented in Blue book. one is free to implement its own, may it be slow, it is just important that it works, and that it is not known to public (secret VM, so that it is more difficult to mount attack against it specifically by hacking C compiler). load small (and private) snippet to dump all code (source and byte codes) from the image using both VM-s, run the MD5. Not that here our VM is reading image directly, (well up to the OS that is), hence all the byte codes, and it is relying on what the whole imaga and original VM are telling. To increase security, implement more than one VM in different languages, Smalltalk is simple enough so implementing it in C, assembler, Prolog, and ASIC-s for the purposes of verification is not out of reach for some paranoid and wealthy org. Also run on at least few operating systems. Davorin Rusevljan http://www.cloud208.com/ ----- http://www.cloud208.com/ -- View this message in context: http://forum.world.st/Trusting-Trust-tp4364753p4369147.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 8, 2012

Re: [Pharo-project] Trusting Trust

by Norbert Hartl

Am 08.02.2012 um 12:04 schrieb Philippe Marschall: > On 02/08/2012 11:33 AM, Norbert Hartl 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? > > Am I the only one who read the link? > Now I read it. But it doesn't change the game. There is an assumption of "a trusted compiler". So they put trust into a compiler and then derive a scenario that is far from being applyable to define an easier way of establishing trust. I can say it again in yet another way: Trust is a _human_ factor that you cannot establish with technology. That's the whole point in everything security. Norbert

Feb. 8, 2012

Re: [Pharo-project] Trusting Trust

by Philippe Marschall

On 02/08/2012 11:33 AM, Norbert Hartl 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? Am I the only one who read the link? Cheers Philippe

Feb. 8, 2012

Re: [Pharo-project] SmallHarbour questions

by GermÃ¡n Arduino

Hi Laurent! Thanks for the response, and don't worry, nothing urgent. Let me know if I can help, and yes, count me as a potential user. Cheers. 2012/2/8 laurent laffont <laurent.laffont(a)gmail.com> > Hi German, > > at least one potential user :) > > I'll have a look this week, still not have totally recovered from FOSDEM. > > Laurent > > > On Sun, Feb 5, 2012 at 10:29 PM, GermÃ¡n Arduino <garduino(a)gmail.com>wrote: > >> Hi: >> >> I'm trying to start using SmallHarbour and found several problems or >> is me that don't know how to do the things: >> >> 1. How to delete a folder? (If I create a folder and click on it and >> then press delete nothing happens). >> >> 2. How to delete images and changes files? (If I click in an image it >> says "file to big to download", but I don't have a place to select it >> to delete. >> >> 3. I uploaded a sample image and somethings start and somethings not >> and when starts can't reach it on the url (Not found log info still). >> Some advices about sort of images/apps, etc to upload? >> >> TIA. >> >> -- >> ============================================ >> GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino >> Arduino Software http://www.arduinosoftware.com >> PasswordsPro http://www.passwordspro.com >> greensecure.blogspot.com germanarduino.blogpost.com >> ============================================ >> >> > -- ============================================ GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com greensecure.blogspot.com germanarduino.blogpost.com ============================================

Feb. 8, 2012

Re: [Pharo-project] Fixed to interrupt behavior

by Sven Van Caekenberghe

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

Feb. 8, 2012

Re: [Pharo-project] Trusting Trust

by Frank Shearar

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. 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 > couldn't resist, > > Norbert > >

Feb. 8, 2012

Re: [Pharo-project] Fixed to interrupt behavior

by Schwab,Wilhelm K

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 Norbert Hartl

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. couldn't resist, Norbert

Feb. 8, 2012