[Pharo-project] KeyChain/UsersManager
Hi, what is the reason for integration of KeyChain/UsersManager to the image? It created the next kernel dependency. Should it replace Author? Should it be in the Pharo Kernel? And why there was no mention about it in this mailing list before? ;-) Cheers, -- Pavel
it was in the list of things to integrate :) but we should check to clean the dependence, because is not good. Esteban On Dec 15, 2012, at 2:16 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi,
what is the reason for integration of KeyChain/UsersManager to the image? It created the next kernel dependency. Should it replace Author? Should it be in the Pharo Kernel? And why there was no mention about it in this mailing list before? ;-)
Cheers, -- Pavel
It broke following Pharo Kernel jobs because the image crashes when a directory is changed. So how to fix that. We have several options: - make simple ugly fix that will check presence of this class, it will generate unimplemented calls - remove it and add it back fixed in 3.0 - rewrite the Author change mechanism to Announcements (in 3.0?) What do you propose? -- Pavel On Sat, Dec 15, 2012 at 3:01 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
it was in the list of things to integrate :) but we should check to clean the dependence, because is not good.
Esteban
On Dec 15, 2012, at 2:16 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi,
what is the reason for integration of KeyChain/UsersManager to the image? It created the next kernel dependency. Should it replace Author? Should it be in the Pharo Kernel? And why there was no mention about it in this mailing list before? ;-)
Cheers, -- Pavel
I think that we should remove the keyChain and it would be good that the system offers the right hooks so that keychain can be nicely added. Apparently ben add to provide a cs because some changes could not be applied via a slice. I planned to have a look but so far I did not find the time. On Dec 20, 2012, at 2:07 PM, Pavel Krivanek wrote:
It broke following Pharo Kernel jobs because the image crashes when a directory is changed. So how to fix that. We have several options: - make simple ugly fix that will check presence of this class, it will generate unimplemented calls - remove it and add it back fixed in 3.0 - rewrite the Author change mechanism to Announcements (in 3.0?) What do you propose?
-- Pavel
On Sat, Dec 15, 2012 at 3:01 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
it was in the list of things to integrate :) but we should check to clean the dependence, because is not good.
Esteban
On Dec 15, 2012, at 2:16 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi,
what is the reason for integration of KeyChain/UsersManager to the image? It created the next kernel dependency. Should it replace Author? Should it be in the Pharo Kernel? And why there was no mention about it in this mailing list before? ;-)
Cheers, -- Pavel
There is a lot of reasons why I think that the whole concept of UsersManager is poor: - direct dependency on cryptography packages - there is only one current user. What about if more users is connected to one image? - users avatar as an ImageMorph! - permissions do not reflect modular architecture. Why to have permissions like canBrowse canDebug canEditCode canEvaluateCode canInspect canShowMorphHalo for image that has now browser, no debugger, no editor, no inspector, no compiler, no Morphic? - in Smalltalk this permissions bring no real security - UsersManager is not an abstract class - everything is in one package Thanks to this addition in current state the Pharo Kernel is not able to load Monticello packages and in most cases even start. We really need to reject it for Pharo 2.0. Cheers, -- Pavel On Thu, Dec 20, 2012 at 5:23 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I think that we should remove the keyChain and it would be good that the system offers the right hooks so that keychain can be nicely added. Apparently ben add to provide a cs because some changes could not be applied via a slice. I planned to have a look but so far I did not find the time.
On Dec 20, 2012, at 2:07 PM, Pavel Krivanek wrote:
It broke following Pharo Kernel jobs because the image crashes when a directory is changed. So how to fix that. We have several options: - make simple ugly fix that will check presence of this class, it will generate unimplemented calls - remove it and add it back fixed in 3.0 - rewrite the Author change mechanism to Announcements (in 3.0?) What do you propose?
-- Pavel
On Sat, Dec 15, 2012 at 3:01 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
it was in the list of things to integrate :) but we should check to clean the dependence, because is not good.
Esteban
On Dec 15, 2012, at 2:16 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi,
what is the reason for integration of KeyChain/UsersManager to the image? It created the next kernel dependency. Should it replace Author? Should it be in the Pharo Kernel? And why there was no mention about it in this mailing list before? ;-)
Cheers, -- Pavel
Yes we should unload it. Now I would like to know what are the hooks that we need in the kernel to support its smooth loading. Stef On Dec 23, 2012, at 1:48 PM, Pavel Krivanek wrote:
There is a lot of reasons why I think that the whole concept of UsersManager is poor: - direct dependency on cryptography packages - there is only one current user. What about if more users is connected to one image? - users avatar as an ImageMorph! - permissions do not reflect modular architecture. Why to have permissions like canBrowse canDebug canEditCode canEvaluateCode canInspect canShowMorphHalo for image that has now browser, no debugger, no editor, no inspector, no compiler, no Morphic? - in Smalltalk this permissions bring no real security - UsersManager is not an abstract class - everything is in one package
Thanks to this addition in current state the Pharo Kernel is not able to load Monticello packages and in most cases even start. We really need to reject it for Pharo 2.0.
Cheers, -- Pavel
On Thu, Dec 20, 2012 at 5:23 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I think that we should remove the keyChain and it would be good that the system offers the right hooks so that keychain can be nicely added. Apparently ben add to provide a cs because some changes could not be applied via a slice. I planned to have a look but so far I did not find the time.
On Dec 20, 2012, at 2:07 PM, Pavel Krivanek wrote:
It broke following Pharo Kernel jobs because the image crashes when a directory is changed. So how to fix that. We have several options: - make simple ugly fix that will check presence of this class, it will generate unimplemented calls - remove it and add it back fixed in 3.0 - rewrite the Author change mechanism to Announcements (in 3.0?) What do you propose?
-- Pavel
On Sat, Dec 15, 2012 at 3:01 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
it was in the list of things to integrate :) but we should check to clean the dependence, because is not good.
Esteban
On Dec 15, 2012, at 2:16 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi,
what is the reason for integration of KeyChain/UsersManager to the image? It created the next kernel dependency. Should it replace Author? Should it be in the Pharo Kernel? And why there was no mention about it in this mailing list before? ;-)
Cheers, -- Pavel
Firstly we need to aswer on question how deep this mechanism should be integrated with the kernel. If kernel should be able to work without UsersManger, if Monticello and Metacello should be able to work without UsersManager, if we should provide some basic minimal UsersManager implementation etc. currently the have problems with this methods: Author>>fullNamePerSe Author>>fullName: MCHttpRepository>>password MCHttpRepository>>user -- Pavel On Sun, Dec 23, 2012 at 2:13 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Yes we should unload it. Now I would like to know what are the hooks that we need in the kernel to support its smooth loading.
Stef
On Dec 23, 2012, at 1:48 PM, Pavel Krivanek wrote:
There is a lot of reasons why I think that the whole concept of UsersManager is poor: - direct dependency on cryptography packages - there is only one current user. What about if more users is connected to one image? - users avatar as an ImageMorph! - permissions do not reflect modular architecture. Why to have permissions like canBrowse canDebug canEditCode canEvaluateCode canInspect canShowMorphHalo for image that has now browser, no debugger, no editor, no inspector, no compiler, no Morphic? - in Smalltalk this permissions bring no real security - UsersManager is not an abstract class - everything is in one package
Thanks to this addition in current state the Pharo Kernel is not able to load Monticello packages and in most cases even start. We really need to reject it for Pharo 2.0.
Cheers, -- Pavel
On Thu, Dec 20, 2012 at 5:23 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I think that we should remove the keyChain and it would be good that the system offers the right hooks so that keychain can be nicely added. Apparently ben add to provide a cs because some changes could not be applied via a slice. I planned to have a look but so far I did not find the time.
On Dec 20, 2012, at 2:07 PM, Pavel Krivanek wrote:
It broke following Pharo Kernel jobs because the image crashes when a directory is changed. So how to fix that. We have several options: - make simple ugly fix that will check presence of this class, it will generate unimplemented calls - remove it and add it back fixed in 3.0 - rewrite the Author change mechanism to Announcements (in 3.0?) What do you propose?
-- Pavel
On Sat, Dec 15, 2012 at 3:01 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
it was in the list of things to integrate :) but we should check to clean the dependence, because is not good.
Esteban
On Dec 15, 2012, at 2:16 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi,
what is the reason for integration of KeyChain/UsersManager to the image? It created the next kernel dependency. Should it replace Author? Should it be in the Pharo Kernel? And why there was no mention about it in this mailing list before? ;-)
Cheers, -- Pavel
Yes In fact usman got interested by the package because we should deploy application to clients with restriction. Now we should rethink it if this is to be integrated in the image. Now one of the problem is that benjmain cannot manage it completely with a configuration because some code can only be applied using CS and this is this point that we should look at. Stef
Firstly we need to aswer on question how deep this mechanism should be integrated with the kernel. If kernel should be able to work without UsersManger, if Monticello and Metacello should be able to work without UsersManager, if we should provide some basic minimal UsersManager implementation etc.
currently the have problems with this methods: Author>>fullNamePerSe Author>>fullName: MCHttpRepository>>password MCHttpRepository>>user
-- Pavel
On Sun, Dec 23, 2012 at 2:13 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Yes we should unload it. Now I would like to know what are the hooks that we need in the kernel to support its smooth loading.
Stef
On Dec 23, 2012, at 1:48 PM, Pavel Krivanek wrote:
There is a lot of reasons why I think that the whole concept of UsersManager is poor: - direct dependency on cryptography packages - there is only one current user. What about if more users is connected to one image? - users avatar as an ImageMorph! - permissions do not reflect modular architecture. Why to have permissions like canBrowse canDebug canEditCode canEvaluateCode canInspect canShowMorphHalo for image that has now browser, no debugger, no editor, no inspector, no compiler, no Morphic? - in Smalltalk this permissions bring no real security - UsersManager is not an abstract class - everything is in one package
Thanks to this addition in current state the Pharo Kernel is not able to load Monticello packages and in most cases even start. We really need to reject it for Pharo 2.0.
Cheers, -- Pavel
On Thu, Dec 20, 2012 at 5:23 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I think that we should remove the keyChain and it would be good that the system offers the right hooks so that keychain can be nicely added. Apparently ben add to provide a cs because some changes could not be applied via a slice. I planned to have a look but so far I did not find the time.
On Dec 20, 2012, at 2:07 PM, Pavel Krivanek wrote:
It broke following Pharo Kernel jobs because the image crashes when a directory is changed. So how to fix that. We have several options: - make simple ugly fix that will check presence of this class, it will generate unimplemented calls - remove it and add it back fixed in 3.0 - rewrite the Author change mechanism to Announcements (in 3.0?) What do you propose?
-- Pavel
On Sat, Dec 15, 2012 at 3:01 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
it was in the list of things to integrate :) but we should check to clean the dependence, because is not good.
Esteban
On Dec 15, 2012, at 2:16 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi,
what is the reason for integration of KeyChain/UsersManager to the image? It created the next kernel dependency. Should it replace Author? Should it be in the Pharo Kernel? And why there was no mention about it in this mailing list before? ;-)
Cheers, -- Pavel
On 15 December 2012 14:16, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi,
what is the reason for integration of KeyChain/UsersManager to the image? It created the next kernel dependency. Should it replace Author? Should it be in the Pharo Kernel? And why there was no mention about it in this mailing list before? ;-)
Yes, i also would like to hear arguments why we need it.
Cheers, -- Pavel
-- Best regards, Igor Stasenko.
Probably we should have a nice configurationOf, fix the dependencies, and do not integrate it 2.0 Stef
what is the reason for integration of KeyChain/UsersManager to the image? It created the next kernel dependency. Should it replace Author? Should it be in the Pharo Kernel? And why there was no mention about it in this mailing list before? ;-)
Yes, i also would like to hear arguments why we need it.
Cheers, -- Pavel
-- Best regards, Igor Stasenko.
http://code.google.com/p/pharo/issues/detail?id=7130
Hi,
what is the reason for integration of KeyChain/UsersManager to the image? It created the next kernel dependency. Should it replace Author? Should it be in the Pharo Kernel? And why there was no mention about it in this mailing list before? ;-)
Yes, i also would like to hear arguments why we need it.
Cheers, --
On Sat, Dec 15, 2012 at 2:16 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
what is the reason for integration of KeyChain/UsersManager to the image? It created the next kernel dependency. Should it replace Author? Should it be in the Pharo Kernel? And why there was no mention about it in this mailing list before? ;-)
I'm not sure what is KeyChain, but the name sounds familiar and makes the package very important as it might solve a critical problem: - how do you store Monticello/webservices/any application's passwords safely? To me KeyChain should provide an API to store and access any kind of credentials. This API could then delegate to the O.S. one. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
On 2012-12-17, at 05:34, Damien Cassou <damien.cassou@gmail.com> wrote:
On Sat, Dec 15, 2012 at 2:16 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
what is the reason for integration of KeyChain/UsersManager to the image? It created the next kernel dependency. Should it replace Author? Should it be in the Pharo Kernel? And why there was no mention about it in this mailing list before? ;-)
I'm not sure what is KeyChain, but the name sounds familiar and makes the package very important as it might solve a critical problem:
- how do you store Monticello/webservices/any application's passwords safely?
To me KeyChain should provide an API to store and access any kind of credentials. This API could then delegate to the O.S. one.
AFIK this is what Ben intended to do. A general API to store and retreive Passwords with various backends (plaintext, secure, native...)
participants (6)
-
Camillo Bruni -
Damien Cassou -
Esteban Lorenzano -
Igor Stasenko -
Pavel Krivanek -
Stéphane Ducasse