[Pharo-project] Image Lockdown/Deployment mode
Does Pharo currently provide support for a deployment mode/image locking mode? I think of the following scenario: ================================== If one builds a rich (client) app for a customer based on Pharo (I mean a real app, no Smalltalk tool - for instance a game or a commercial app) he may want to: - lock the image so nobody is able to hit Cmd-. - exchange the Walkback to display a custom dialog instead of proving debugger access to the end user. Do we provide a hook already? - replace world menu with a custom menu. Do we provide a hook already? - wants to disable code evaluation in edit fields using * menus (no doIt, printIt, inspectIt just cut, copy, paste) * keyboard (Cmd-d, ...) - wants to disable Halos - prevent reading scripts/projects at startup so nobody is able to hijack the image and get access to the code - disable the dependency on source and changes file Maybe this locking facility can be reenabled after entering a password so a developer can still debug in the customers environment. (I remember Andreas said that they protect the Teleplace image and save the password hashed in image). Maybe Gary can share his experience to lock the "Pinesoft â MBagger" image or others how they lock down their image. Either we provide such a (switchable) mode in the default image or give a guide in the pharo book on how to restrict end user access to the Smalltalk environment in deployed applications. Yes - we provide a #cleanUpForProduction method - but this is more to reduce size. Maybe the old "Lockdown" package could be a start: http://wiki.squeak.org/squeak/518 I think of a loadable package "ImageLocker" with a class that can set/unset the appropriate preferences and provide alternative error handlers, menues, ... Any comments? Thx T. BTW: I remember having a hard time with the "deployment step" in most commercial environments due to "striping" the image. Now this is partly adressed by building images bottom to top using Metacello now. One could load his app based on a core without the extended dev-tools. But Pharo should really care to also easily disable developer facilities so developers may use it as the platform for their next project. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Good question we need that!!!! We were thinking about that with noury for 1.0 and got distracted. This is really important. Any step in that direction is really welcome
Does Pharo currently provide support for a deployment mode/image locking mode?
I think of the following scenario: ================================== If one builds a rich (client) app for a customer based on Pharo (I mean a real app, no Smalltalk tool - for instance a game or a commercial app) he may want to:
- lock the image so nobody is able to hit Cmd-. - exchange the Walkback to display a custom dialog instead of proving debugger access to the end user. Do we provide a hook already? - replace world menu with a custom menu. Do we provide a hook already? - wants to disable code evaluation in edit fields using * menus (no doIt, printIt, inspectIt just cut, copy, paste) * keyboard (Cmd-d, ...) - wants to disable Halos - prevent reading scripts/projects at startup so nobody is able to hijack the image and get access to the code - disable the dependency on source and changes file
Maybe this locking facility can be reenabled after entering a password so a developer can still debug in the customers environment. (I remember Andreas said that they protect the Teleplace image and save the password hashed in image).
Maybe Gary can share his experience to lock the "Pinesoft â MBagger" image or others how they lock down their image.
Either we provide such a (switchable) mode in the default image or give a guide in the pharo book on how to restrict end user access to the Smalltalk environment in deployed applications.
Yes - we provide a #cleanUpForProduction method - but this is more to reduce size.
Maybe the old "Lockdown" package could be a start: http://wiki.squeak.org/squeak/518
I think of a loadable package "ImageLocker" with a class that can set/unset the appropriate preferences and provide alternative error handlers, menues, ...
Any comments?
Thx T.
BTW: I remember having a hard time with the "deployment step" in most commercial environments due to "striping" the image. Now this is partly adressed by building images bottom to top using Metacello now. One could load his app based on a core without the extended dev-tools.
But Pharo should really care to also easily disable developer facilities so developers may use it as the platform for their next project.
-- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Mostly done via #disableProgrammerFacilities, though I note it is now deprecated in Pharo... Also, deactivating ProjectLauncher takes care of the startup script thing. Regards, Gary ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, May 26, 2010 3:02 PM Subject: Re: [Pharo-project] Image Lockdown/Deployment mode Good question we need that!!!! We were thinking about that with noury for 1.0 and got distracted. This is really important. Any step in that direction is really welcome
Does Pharo currently provide support for a deployment mode/image locking mode?
I think of the following scenario: ================================== If one builds a rich (client) app for a customer based on Pharo (I mean a real app, no Smalltalk tool - for instance a game or a commercial app) he may want to:
- lock the image so nobody is able to hit Cmd-. - exchange the Walkback to display a custom dialog instead of proving debugger access to the end user. Do we provide a hook already? - replace world menu with a custom menu. Do we provide a hook already? - wants to disable code evaluation in edit fields using * menus (no doIt, printIt, inspectIt just cut, copy, paste) * keyboard (Cmd-d, ...) - wants to disable Halos - prevent reading scripts/projects at startup so nobody is able to hijack the image and get access to the code - disable the dependency on source and changes file
Maybe this locking facility can be reenabled after entering a password so a developer can still debug in the customers environment. (I remember Andreas said that they protect the Teleplace image and save the password hashed in image).
Maybe Gary can share his experience to lock the "Pinesoft â MBagger" image or others how they lock down their image.
Either we provide such a (switchable) mode in the default image or give a guide in the pharo book on how to restrict end user access to the Smalltalk environment in deployed applications.
Yes - we provide a #cleanUpForProduction method - but this is more to reduce size.
Maybe the old "Lockdown" package could be a start: http://wiki.squeak.org/squeak/518
I think of a loadable package "ImageLocker" with a class that can set/unset the appropriate preferences and provide alternative error handlers, menues, ...
Any comments?
Thx T.
BTW: I remember having a hard time with the "deployment step" in most commercial environments due to "striping" the image. Now this is partly adressed by building images bottom to top using Metacello now. One could load his app based on a core without the extended dev-tools.
But Pharo should really care to also easily disable developer facilities so developers may use it as the platform for their next project.
-- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, May 26, 2010 at 5:23 PM, Gary Chambers <gazzaguru2@btinternet.com>wrote:
Mostly done via #disableProgrammerFacilities, though I note it is now deprecated in Pharo...
Also, deactivating ProjectLauncher takes care of the startup script thing.
Gary, it would be really cool to have a section in the collaborative book explaining this ;) I wasn't aware of it, it is pretty cool. Thanks Mariano
Regards, Gary
----- Original Message ----- From: "Stéphane Ducasse" < stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, May 26, 2010 3:02 PM Subject: Re: [Pharo-project] Image Lockdown/Deployment mode
Good question we need that!!!! We were thinking about that with noury for 1.0 and got distracted. This is really important. Any step in that direction is really welcome
Does Pharo currently provide support for a deployment mode/image
locking mode?
I think of the following scenario: ================================== If one builds a rich (client) app for a customer based on Pharo (I mean a real app, no Smalltalk tool - for instance a game or a commercial app) he may want to:
- lock the image so nobody is able to hit Cmd-. - exchange the Walkback to display a custom dialog instead of proving debugger access to the end user. Do we provide a hook already? - replace world menu with a custom menu. Do we provide a hook already? - wants to disable code evaluation in edit fields using * menus (no doIt, printIt, inspectIt just cut, copy, paste) * keyboard (Cmd-d, ...) - wants to disable Halos - prevent reading scripts/projects at startup so nobody is able to hijack the image and get access to the code - disable the dependency on source and changes file
Maybe this locking facility can be reenabled after entering a password so a developer can still debug in the customers environment. (I remember Andreas said that they protect the Teleplace image and save the password hashed in image).
Maybe Gary can share his experience to lock the "Pinesoft â MBagger" image or others how they lock down their image.
Either we provide such a (switchable) mode in the default image or give a guide in the pharo book on how to restrict end user access to the Smalltalk environment in deployed applications.
Yes - we provide a #cleanUpForProduction method - but this is more to reduce size.
Maybe the old "Lockdown" package could be a start: http://wiki.squeak.org/squeak/518
I think of a loadable package "ImageLocker" with a class that can set/unset the appropriate preferences and provide alternative error handlers, menues, ...
Any comments?
Thx T.
BTW: I remember having a hard time with the "deployment step" in most commercial environments due to "striping" the image. Now this is partly adressed by building images bottom to top using Metacello now. One could load his app based on a core without the extended dev-tools.
But Pharo should really care to also easily disable developer facilities so developers may use it as the platform for their next project.
-- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Maybe the old "Lockdown" package could be a start: http://wiki.squeak.org/squeak/518
....
I think of a loadable package "ImageLocker" with a class that can set/unset the appropriate preferences and provide alternative error handlers, menues, ...
Any comments?
I really like it. I would love to have such features. Maybe we can elaborate it and try to have it for 1.2 Just creating a wiki page or an issue with label 1.2 will persist this thread.
Thx T.
BTW: I remember having a hard time with the "deployment step" in most commercial environments due to "striping" the image.
Grrrrr me too. A lot of times, the "reduce" step didn't include me methods because they don't *seemed* to have senders. But those methods were really called, buy by reflection. Then I suffered some DNUs at production :(
Now this is partly adressed by building images bottom to top using Metacello now. One could load his app based on a core without the extended dev-tools.
But Pharo should really care to also easily disable developer facilities so developers may use it as the platform for their next project.
-- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Gary Chambers -
Mariano Martinez Peck -
Stéphane Ducasse -
Torsten Bergmann