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

[Pharo-project] Some steps towards headless on OS X

by Mark Smith

Hi all, The underlying problem with headless mode in OS X seem to be that we always create a window, even when we run in the background, as we do in headless mode*. Marking the process as background only will remove the icon, menu etc. but it will not stop us from creating that window. Maybe I don't know enough about how Squeak/Pharo works right now but it looks like quite a lot of work to change this. And the code isn't pretty ;). Anyway I'd like to keep working on this but I've hit a wall. I can handle the Cocoa side but don't know anything about the VM's setup process etc. Could someone clarify this? Or maybe there are some docs? Also â What do you guys think about building a headless VM without any of the UI stuff in it? It might be simpler/cleaner than what we have now. All the best, Mark * Creating the window is almost the first thing we do! We do it before we know if we're running headlessâ¦

June 3, 2012

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

by Phil (list)

On Jun 3, 2012, at 11:31 AM, Marcus Denker wrote: > > How do people do it with Java? Java .jar files are as easy to decompile as Smalltalk bytecode... > ProGuard (http://proguard.sourceforge.net/) is a popular method. In its obfuscation phase it will rename most class and method names (i.e. anything that doesn't need to be externally visible) to meaningless names so MyClass.MyMethod becomes something like a.a. It can also generate a mapping file so that when bug reports / crashes occur, the developer can map the gibberish names back to the original names. Before the obfuscation phase, it has optimization and shrinking phases to eliminate code that doesn't need to be included for release (debugging code etc.) > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > Thanks, Phil

June 3, 2012

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

by Marcus Denker

On Jun 3, 2012, at 5:26 PM, Ben Coman wrote: >> > > Ultimately at that level - there is no security. This only raises the level of difficulty by requiring a certain conjunction of skill, motivation and ethics. It is no worse than the same attack targetted at option (3.). However there is now some incentive for commercial companies to invest the the effort into releasing an App to execute on top of an otherwise open-source platform. The advantage is that it if ten plugins were required to do proprietary calculations on one dataset and integrate the results into a single screen, then running within the one image seems more elegant than ten images running on ten VMs. How do people do it with Java? Java .jar files are as easy to decompile as Smalltalk bytecode... Marcus -- Marcus Denker -- http://marcusdenker.de

June 3, 2012

Re: [Pharo-project] Trouble loading XML RPC

by garduino

Hi: Sorry the late answer.... If you take an 1.4 stock image, and evaluates (as is commented on http://code.google.com/p/pharo-xmlrpc/) Gofer it url: 'http://ss3.gemstone.com/ss/XMLRPC'; package: 'ConfigurationOfXMLRPC'; load. and then: (ConfigurationOfXMLRPC project version: '1.0-Beta4') load: 'All'. the whole stuff should load. I noticed an error: This package depends on the following classes: TranscriptStream You must resolve these dependencies before you will be able to load these definitions: isTranscriptStream (May be another thing changed in Pharo that I need to know and fix, press proceed to load anyway). But the bad new is that in 1.4 I've some errors on tests, mainly a serious one in server that freeze the image, caution. However, the XMLRPC Client seems to work. XMLRPC is always in my to-do list but a project in what I can invest only a portion of my limited free time. The latest new was that I adapted the Client to use with Zinc, but need still to make the same thing with the server, then all xmlrpc should install and run in a stock image, without need Komanche for example. With respect to Pharo 2.0 I can't help, not tried yet. HTH. GermÃ¡n. -- View this message in context: http://forum.world.st/Trouble-loading-XML-RPC-tp4632653p4633037.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 3, 2012

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

by Ben Coman

Nicolas Cellier wrote: > 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 > > Ultimately at that level - there is no security. This only raises the level of difficulty by requiring a certain conjunction of skill, motivation and ethics. It is no worse than the same attack targetted at option (3.). However there is now some incentive for commercial companies to invest the the effort into releasing an App to execute on top of an otherwise open-source platform. The advantage is that it if ten plugins were required to do proprietary calculations on one dataset and integrate the results into a single screen, then running within the one image seems more elegant than ten images running on ten VMs. >> (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 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