- Pharo-dev - lists.pharo.org

Re: [Pharo-project] mixing open and closed source within Pharo

by Mariano Martinez Peck

> > (btw, I'm assuming CM bytecodes was a typo meant to be VM bytecodes? or > otherwise what is CM?) > > CompiledMethod ;) > > >> >>> 3. Running multiple images on a single VM such that the VM passing >>> message >>> calls efficiently between the two images like an "enterprise bus*" - one >>> open source and one closed source. Any common base objects between the >>> images might be shared on a copy-on-write basis. >>> >>> >>> What are your thoughts? >>> >>> >>> >> >> I think option 3 is most vital: >> you can communicate between two images like between two parties who >> don't trust each other (so images should handshake, use encryption >> key(s), and try to log-in one to other), then if succeed, one can be >> able to see source code use remote debugger etc >> Nothing new under the sun... >> >> >> >>> cheers -ben >>> >>> >>> >> >> >> >> >> > > > -- Mariano http://marianopeck.wordpress.com

June 3, 2012

Re: [Pharo-project] mixing open and closed source within Pharo

by Nicolas Cellier

2012/6/3 Ben Coman <btc(a)openinworld.com>: > Igor Stasenko wrote: >> >> On 30 May 2012 16:04, Ben Coman <btc(a)openinworld.com> wrote: >> >>> >>> What ideas are floating around about mixing open source and closed source >>> using Pharo? Â I am implementing an IEC Standard object model for >>> electrical >>> power systems to provide a platform for developing electrical >>> applications. >>> Â I am considering the case where a company may maintain the model of >>> their >>> electrical power distribution network in the open source platform, but >>> then >>> buy various commercial plug-ins perform different calculations upon the >>> shared model. Â Here are the options I can imagine... >>> >>> 1. Using fuel to load binary packages within the one image without the >>> source. Â Currently available technology but viewing and decompiling >>> bytecode >>> is still possible - but to what degree this enables reverse engineering I >>> am >>> not sure. >>> >> >> >> Decompiler is able to fully reproduce the source code of method. >> only variable names is lost, but you can see everything else quite clear. >> >> >>> >>> 2. Having VM support for restricting displaying/decompiling bytecode. Â To >>> avoid the ease of switching to another VM without this restriction, the >>> fuel >>> package could be encrypted with a key match one compiled inside the >>> required >>> VM. >>> >> >> >> this is not an option. >> A current Debugger implementation implies that you have access to CM >> bytecodes. >> > > > A required implication of (2.) would be that you could not debug "through" > that package. Â While this might be unfortunate from an open-source debugging > view point, in comparison to having the whole application delivered > closed-source with development tools stripped - I would still consider this > to be a step up. Â Ignoring the current implementation of Debugger, could > something like this be reasonably achievable? > To expand on this with a specific use case... The VM could internally > generate a public/private key pair. Â When requesting a plug-in from an App > Store, the public key is sent which the App Store uses to encrypt the > bytecode of the plug-in. Â Once downloaded into the image, upon execution the > VM receives the encrypted bytecode, decrypts it with its private key and > caches the decrypted bytecode internally, such that it is never visible to > the image. > Then what prevents an attacker to dump process memory and retrieve the bytecodes from well known image structure patterns, or a custom image tracer? Nicolas > > (btw, I'm assuming CM bytecodes was a typo meant to be VM bytecodes? or > otherwise what is CM?) > >> >>> >>> 3. Running multiple images on a single VM such that the VM passing >>> message >>> calls efficiently between the two images like an "enterprise bus*" - one >>> open source and one closed source. Â Any common base objects between the >>> images might be shared on a copy-on-write basis. >>> >>> >>> What are your thoughts? >>> >>> >> >> >> I think option 3 is most vital: >> you can communicate between two images like between two parties who >> don't trust each other (so images should handshake, use encryption >> key(s), and try to log-in one to other), then if succeed, one can be >> able to see source code Â use Â remote debugger etc >> Nothing new under the sun... >> >> >>> >>> cheers -ben >>> >>> >> >> >> >> >> > > >

June 3, 2012

Re: [Pharo-project] mixing open and closed source within Pharo

by Ben Coman

Igor Stasenko wrote: > On 30 May 2012 16:04, Ben Coman <btc(a)openinworld.com> wrote: > >> What ideas are floating around about mixing open source and closed source >> using Pharo? I am implementing an IEC Standard object model for electrical >> power systems to provide a platform for developing electrical applications. >> I am considering the case where a company may maintain the model of their >> electrical power distribution network in the open source platform, but then >> buy various commercial plug-ins perform different calculations upon the >> shared model. Here are the options I can imagine... >> >> 1. Using fuel to load binary packages within the one image without the >> source. Currently available technology but viewing and decompiling bytecode >> is still possible - but to what degree this enables reverse engineering I am >> not sure. >> > > Decompiler is able to fully reproduce the source code of method. > only variable names is lost, but you can see everything else quite clear. > > >> 2. Having VM support for restricting displaying/decompiling bytecode. To >> avoid the ease of switching to another VM without this restriction, the fuel >> package could be encrypted with a key match one compiled inside the required >> VM. >> > > this is not an option. > A current Debugger implementation implies that you have access to CM bytecodes. > A required implication of (2.) would be that you could not debug "through" that package. While this might be unfortunate from an open-source debugging view point, in comparison to having the whole application delivered closed-source with development tools stripped - I would still consider this to be a step up. Ignoring the current implementation of Debugger, could something like this be reasonably achievable? To expand on this with a specific use case... The VM could internally generate a public/private key pair. When requesting a plug-in from an App Store, the public key is sent which the App Store uses to encrypt the bytecode of the plug-in. Once downloaded into the image, upon execution the VM receives the encrypted bytecode, decrypts it with its private key and caches the decrypted bytecode internally, such that it is never visible to the image. (btw, I'm assuming CM bytecodes was a typo meant to be VM bytecodes? or otherwise what is CM?) > >> 3. Running multiple images on a single VM such that the VM passing message >> calls efficiently between the two images like an "enterprise bus*" - one >> open source and one closed source. Any common base objects between the >> images might be shared on a copy-on-write basis. >> >> >> What are your thoughts? >> >> > > I think option 3 is most vital: > you can communicate between two images like between two parties who > don't trust each other (so images should handshake, use encryption > key(s), and try to log-in one to other), then if succeed, one can be > able to see source code use remote debugger etc > Nothing new under the sun... > > >> cheers -ben >> >> > > > >

June 3, 2012

[Pharo-project] [update 2.0] #20107

by StÃ©phane Ducasse

20107 ----- Issue 6016: privateAnnouncer is not used and this is not good http://code.google.com/p/pharo/issues/detail?id=6016

June 3, 2012

Re: [Pharo-project] McHttpRepository and text/plain

by Sven Van Caekenberghe

Hi Stuart, On 03 Jun 2012, at 03:41, Stuart Herring wrote: > Hi all, > > I recently ran into the problem with a server returning text/plain > instead of application/octet stream again (see > http://lists.gforge.inria.fr/pipermail/pharo-project/2012-April/062388.html) > but the resulting error (a MNU for Character>>bitOr:) failed to job my > memory as to the actual cause. > Is there any chance the final line of > McHttpRepository>>readStreamForFileNamed:do: could be changed from: > > ^ aBlock value: contents readStream > to: > ^ aBlock value: contents asByteArray readStream -1 #asByteArray does an implicit text to bytes conversion (granted, a stupid one). This will (and had conflicted in the past) with the text conversion done automatically by the HTTP client. The response simply has to be binary because the data is binary. > I know that it would be best if Web Servers never served up binary > content as text/plain - but it's not always in the power of someone > who encounters this error to fix that. > Failing that, the condition should probably be explicitly checked for > and a more useful error message given, as the cause is far enough away > from the symptom that it takes a bit of digging to find out what went > wrong. +1 Yes, the error should be reported better. As it is today is not acceptable. Normally, the ZnClient>>#accept: option (in combination with #systemPolicy) would do the trick. However, while a ZnMimeType text wildcard (text/*) is useful to require textual responses, no such general wildcard exists for (all) binary responses. We could try with (application/*) and hope that enough MC servers comply (I think most will use application/octet-stream or application/x-monticello anyway). I could try to make a 2.0 patch and see what happens. > Regards, > Stuart Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

June 3, 2012

Re: [Pharo-project] Method protocol nitpick

by Ben Coman

In MS Excel, such functions are grouped under "Information". Alternatively standardize a category "UnitTests". StÃ©phane Ducasse wrote: > I would like to recategorise systematically methods. > Would be good to propose some rules and apply automatically. > > Stef > > On Jun 2, 2012, at 7:42 PM, Sean P. DeNigris wrote: > > >> There are many test methods categorized as "testing". "Testing" means e.g. >> #isEmpty. "tests" (which is also used for test methods) would be better... >> >> Sean >> >> -- >> View this message in context: http://forum.world.st/Method-protocol-nitpick-tp4632925.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > > >

June 3, 2012

[Pharo-project] McHttpRepository and text/plain

by Stuart Herring

Hi all, I recently ran into the problem with a server returning text/plain instead of application/octet stream again (see http://lists.gforge.inria.fr/pipermail/pharo-project/2012-April/062388.html) but the resulting error (a MNU for Character>>bitOr:) failed to job my memory as to the actual cause. Is there any chance the final line of McHttpRepository>>readStreamForFileNamed:do: could be changed from: ^ aBlock value: contents readStream to: ^ aBlock value: contents asByteArray readStream I know that it would be best if Web Servers never served up binary content as text/plain - but it's not always in the power of someone who encounters this error to fix that. Failing that, the condition should probably be explicitly checked for and a more useful error message given, as the cause is far enough away from the symptom that it takes a bit of digging to find out what went wrong. Regards, Stuart

June 3, 2012

Re: [Pharo-project] Tests jobs are non-functional

by Guillermo Polito

Found it! That test is sending twice the ClassRemoved event, the first succeeds, but on the second one fails because the class is not registered any more. I was trying this afternoon to replace the ugly ^nil by testing methods + exceptions, but I died in the trial. Tomorrow will be a new day :) On Sun, Jun 3, 2012 at 1:13 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Looks like the problem with Pharo-2.0-AfterRunningTests.st > > > > Notice: Errors in script loaded from > > /builds/jenkins/workspace/Pharo-2.0-Tests/Architecture/32/OS/linux/Pharo-2.0-AfterRunningTests/ > Pharo-2.0-AfterRunningTests.st > > =============================================================================== > [0m [0m [31m==== Startup Error: MessageNotUnderstood: receiver of > "removeClassDefinitionNamed:" is nil > [0mUndefinedObject(Object)>>doesNotUnderstand: > #removeClassDefinitionNamed: > RPackageOrganizer>>fullyRemoveClassNamed: > RPackageOrganizer>>systemClassRemovedActionFrom: > MessageSend>>value: > MessageSend>>cull: > MessageSend>>cull:cull: > AnnouncementSubscription>>deliver: in Block: [action cull: > anAnnouncement cull: announcer] > BlockClosure>>on:do: > BlockClosure>>on:fork: > AnnouncementSubscription>>deliver: > [0m [31mGot startup errors: > [0m [31m MessageNotUnderstood: receiver of > "removeClassDefinitionNamed:" is nil > [0mbuild.sh: error loading code > > (/builds/jenkins/workspace/Pharo-2.0-Tests/Architecture/32/OS/linux/vm/CogVM) > > > -- > Best regards, > Igor Stasenko. > >

June 3, 2012

Re: [Pharo-project] Log fwk

by Santiago Bragagnolo

I just refactor the hold logEntity for a announcer on the filter object (thanks Guille for the feedback :) ). But right now is based on TAnnouncer, an enhancement to announcements, that i recently commit. For a right-now functionaly log, checkout the 3rd commit! and not the last one, or, download the slice from PharoInbox previously. 2012/6/2 Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> > i'm forking the thread to open it for feedback. (Sorry for the spam > repeating my self, but gmail is working funny :S) > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Hi all! Sorry for making you wait, here is the promised post about logger. > > > http://concretetypeinference.blogspot.com.ar/2012/06/pharo-logger-aka-paul-…<http://concretetypeinference.blogspot.com.ar/2012/06/pharo-logger-aka-paul-…> > > Sorry for the awful text-format, blogger is really ugly. I'll be opening a > wordpress blog and migrating all the posts the sooner as i can. > > Try to use it if you need a logger and please, send feedback! > > The needed code to addit to any project is really few, for an easy > example, download the project and see at examples :). > > >

June 2, 2012

[Pharo-project] Tests jobs are non-functional

by Igor Stasenko

Looks like the problem with Pharo-2.0-AfterRunningTests.st Notice: Errors in script loaded from /builds/jenkins/workspace/Pharo-2.0-Tests/Architecture/32/OS/linux/Pharo-2.0-AfterRunningTests/Pharo-2.0-AfterRunningTests.st =============================================================================== [0m[0m[31m==== Startup Error: MessageNotUnderstood: receiver of "removeClassDefinitionNamed:" is nil [0mUndefinedObject(Object)>>doesNotUnderstand: #removeClassDefinitionNamed: RPackageOrganizer>>fullyRemoveClassNamed: RPackageOrganizer>>systemClassRemovedActionFrom: MessageSend>>value: MessageSend>>cull: MessageSend>>cull:cull: AnnouncementSubscription>>deliver: in Block: [action cull: anAnnouncement cull: announcer] BlockClosure>>on:do: BlockClosure>>on:fork: AnnouncementSubscription>>deliver: [0m[31mGot startup errors: [0m[31m MessageNotUnderstood: receiver of "removeClassDefinitionNamed:" is nil [0mbuild.sh: error loading code (/builds/jenkins/workspace/Pharo-2.0-Tests/Architecture/32/OS/linux/vm/CogVM) -- Best regards, Igor Stasenko.

June 2, 2012