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

Re: [Pharo-project] [squeak-dev] Re: Security Vunerability in SqueakSource

by Matthew Fulmer

On Mon, Mar 21, 2011 at 09:15:03AM +0100, Marcus Denker wrote: > > On Mar 21, 2011, at 3:24 AM, Matthew Fulmer wrote: > > > As demonstrated by the VMMaker team, SqueakSource has a rather > > serious security vunerability: > > > > Serious security problems are normally send to the admins of > a website first (so they fix it) instead of sending it to a mailinglist... I have some idea who the squeaksource.com admins are, but not the source.squeak.org admins. Also don't know who else has their own squeaksource install -- Matthew Fulmer (a.k.a. Tapple)

March 21, 2011

Re: [Pharo-project] Getting a functionning unstable image

by StÃ©phane Ducasse

Hi nicolas this is strange because I always update all the updates from the latest unstable published by marcus (so yes it can be long) and I never get this error. May be you have a broken sources files or something like that. I update often multiple times especially when I integrate changes to make sure that I do not a strange changes around. and I never get such error. What is your OS? Stef On Mar 21, 2011, at 9:53 PM, Nicolas Cellier wrote: > Hi guys, > Updating Pharo from the update stream failed many times and keep on > failing for me... > But maybe it's just me... > > So I picked the unstable link from the web site > (http://www.pharo-project.org/pharo-download/unstable-core) > This drives me to a 13091 image. > The first thing I do is select the 'update system' menu... > Err, it fails... It seems related to broken sources... > Well the image points to which source file ? can't remember the > incantation, let just browse it... > Err, no source, I can't browse. > No matter, I set the browser to decompile mode... > Err, this does not work, I still can't browse code. > Hmm very bad starting experience, I know what unstable means, but I > was dreaming of other words like continuous development. > > So ket's open an older image (my own updated 1.2) to find the incantations. > (Scanner>>#scanTokens:) fileIndex -> 1, so it seems that the source > file is corrupted. > (SourceFiles at: 1) -> MultiByteFileStream: > '/Users/nicolas/Smalltalk/Squeak/pharo/PharoV10.sources' > > Well, for my previous Pharo images, this very file works ! > How damned can be the file be changed and the version not incremented ? > > Is it me who did something wrong ? > Or the update process somewhere did condense the sources ? > Or did someone elese messed with the sources ? > Is it a known problem ? > > Any help appreciated. > > Nicolas >

March 21, 2011

Re: [Pharo-project] Getting a functionning unstable image

by Marcus Denker

Hello, > Hi guys, > Updating Pharo from the update stream failed many times and keep on > failing for me... > But maybe it's just me... > Updating never failied for me... (Hudson not,either). (e.g. I can download the 13091 and it updates without error) > So I picked the unstable link from the web site > (http://www.pharo-project.org/pharo-download/unstable-core) > This drives me to a 13091 image. > The first thing I do is select the 'update system' menu... > Err, it fails... It seems related to broken sources... > Well the image points to which source file ? can't remember the > incantation, let just browse it... > Err, no source, I can't browse. > No matter, I set the browser to decompile mode... > Err, this does not work, I still can't browse code. > Hmm very bad starting experience, I know what unstable means, but I > was dreaming of other words like continuous development. > I have not seen that problem... I will investigate. > So ket's open an older image (my own updated 1.2) to find the incantations. > (Scanner>>#scanTokens:) fileIndex -> 1, so it seems that the source > file is corrupted. > (SourceFiles at: 1) -> MultiByteFileStream: > '/Users/nicolas/Smalltalk/Squeak/pharo/PharoV10.sources' > > Well, for my previous Pharo images, this very file works ! > How damned can be the file be changed and the version not incremented ? > It should not be changed. > Is it me who did something wrong ? > Or the update process somewhere did condense the sources ? I hope not! > Or did someone elese messed with the sources ? > Is it a known problem ? > With Igor we saw some problem when decompiling code. (remove sources). What we should do, too is to invest into the regression tester to acutally test things like if the changes and sources are in a good shape, if we can condense, write new sources, all these things... -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 21, 2011

[Pharo-project] Getting a functionning unstable image

by Nicolas Cellier

Hi guys, Updating Pharo from the update stream failed many times and keep on failing for me... But maybe it's just me... So I picked the unstable link from the web site (http://www.pharo-project.org/pharo-download/unstable-core) This drives me to a 13091 image. The first thing I do is select the 'update system' menu... Err, it fails... It seems related to broken sources... Well the image points to which source file ? can't remember the incantation, let just browse it... Err, no source, I can't browse. No matter, I set the browser to decompile mode... Err, this does not work, I still can't browse code. Hmm very bad starting experience, I know what unstable means, but I was dreaming of other words like continuous development. So ket's open an older image (my own updated 1.2) to find the incantations. (Scanner>>#scanTokens:) fileIndex -> 1, so it seems that the source file is corrupted. (SourceFiles at: 1) -> MultiByteFileStream: '/Users/nicolas/Smalltalk/Squeak/pharo/PharoV10.sources' Well, for my previous Pharo images, this very file works ! How damned can be the file be changed and the version not incremented ? Is it me who did something wrong ? Or the update process somewhere did condense the sources ? Or did someone elese messed with the sources ? Is it a known problem ? Any help appreciated. Nicolas

March 21, 2011

Re: [Pharo-project] String>>#base64Encoded

by StÃ©phane Ducasse

On Mar 21, 2011, at 9:42 PM, Sven Van Caekenberghe wrote: > Hi, > > It took me quite some time today to figure this out and it might be relevant for others too: > > it turns out that String>>#base64Encoded introduces newlines which you definitively do not want when doing Basic HTTP Encoding for example. The tricky part is that it works when you stay below a certain length. when would it makes sense? > > This can easily be solved by invoking Base64MimeConvertor with the #mimeEncode: <string> multiLine: false > > Zinc HTTP Components now does this consistently through ZnUtils class>>#encodeBase64: > > Sven > >

March 21, 2011

[Pharo-project] String>>#base64Encoded

by Sven Van Caekenberghe

Hi, It took me quite some time today to figure this out and it might be relevant for others too: it turns out that String>>#base64Encoded introduces newlines which you definitively do not want when doing Basic HTTP Encoding for example. The tricky part is that it works when you stay below a certain length. This can easily be solved by invoking Base64MimeConvertor with the #mimeEncode: <string> multiLine: false Zinc HTTP Components now does this consistently through ZnUtils class>>#encodeBase64: Sven

March 21, 2011

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

by Eliot Miranda

On Mon, Mar 21, 2011 at 12:13 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Mon, Mar 21, 2011 at 7:23 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> This would be a nice little topic... this bytecode verifier. >> > > Probably on top of Opal > The bytecode verifier must be in the VM. If it is up in the image it can be side-stepped. The VM is the ultimate executor of code and so it must apply verification. It could be written in Smalltalk and verified in Smalltalk and then translated. But it must be part of the VM and used by the VM before running any previously unverified method. best, Eliot > > >> >> Stef >> >> On Mar 21, 2011, at 2:57 PM, Toon Verwaest wrote: >> >> > 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] Thank you ProfStef

by Mariano Martinez Peck

On Mon, Mar 21, 2011 at 8:38 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > On Mon, Mar 21, 2011 at 7:59 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> Thanks Laurent :) >> > > A nice documenting tool is great, good content far better :) So thanks Dale > & Mariano for their good documentation. We need more. > Yes. And what is more, is that from the same source we can have different outputs: class comments, pharo collaborative book, ProfStef, Help System, etc... > > Laurent. > > > >> >> >> On 21.03.2011, at 19:21, StÃ©phane Ducasse wrote: >> >> > Thanks Laurent! Since he did ProfStef. He just started with my examples >> :) >> > On Mar 21, 2011, at 1:50 PM, Max Leske wrote: >> > >> >> Just a short thank you Stef. When I thought about tackling Metacello >> configurations it felt like it was going to be tough. But then: ProfStef to >> the rescue! >> >> >> >> Really a great idea! How many other IDE's sport a tutorial mechanism >> that can be easily extended by anyone? Not many I guess... >> >> >> >> Cheers, >> >> Max >> > >> > >> >> >> >

March 21, 2011

Re: [Pharo-project] Thank you ProfStef

by laurent laffont

On Mon, Mar 21, 2011 at 7:59 PM, Max Leske <maxleske(a)gmail.com> wrote: > Thanks Laurent :) > A nice documenting tool is great, good content far better :) So thanks Dale & Mariano for their good documentation. We need more. Laurent. > > > On 21.03.2011, at 19:21, StÃ©phane Ducasse wrote: > > > Thanks Laurent! Since he did ProfStef. He just started with my examples > :) > > On Mar 21, 2011, at 1:50 PM, Max Leske wrote: > > > >> Just a short thank you Stef. When I thought about tackling Metacello > configurations it felt like it was going to be tough. But then: ProfStef to > the rescue! > >> > >> Really a great idea! How many other IDE's sport a tutorial mechanism > that can be easily extended by anyone? Not many I guess... > >> > >> Cheers, > >> Max > > > > > > >

March 21, 2011

Re: [Pharo-project] [COTDC] 34 - MCSystemCategoryParser

by laurent laffont

Could it be: I parse PackageInfo statement from Monticello packages file. Laurent. On Mon, Mar 21, 2011 at 8:02 AM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Today: MCSystemCategoryParser > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent >

March 21, 2011