- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [NB]: Review & fixes & ideas

by Sean P. DeNigris

Thanks for all this work, Igor! But can we do a simple system call yet?! http://forum.world.st/NB-crash-boom-td4669980.html https://pharo.fogbugz.com/f/cases/7542/NB-system-examplerun: str Sean: run: str "self run: 'open http://www.google.com'." <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > ^ self nbCall: #( int system (String str) ) module: NativeBoost CLibrary fails Cami: "Yes I would put that even on high-priority for NB, as it is the most important use-case that makes sense to me :D" ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-NB-Review-fixes-ideas-tp4698514p4698563.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 13, 2013

Re: [Pharo-dev] about WidgetAbstractWrapper

by Erwan Douaille

I start to create it, what would you like to get in ? for the moment there is nothing because i focused on something different 2013/7/12 Andrei Vasile Chis <chisvasileandrei(a)gmail.com> > Hi Erwan, > > I've heard you are working on a WidgetAbstractWrapper for dealing with > dynamic widgets :) > Is it still a work in progress or there's already something concrete? > > Cheers, > Andrei > -- Best regards, Douaille Erwan <douaille.erwan(a)gmail.com>

July 12, 2013

about WidgetAbstractWrapper

by Andrei Vasile Chis

Hi Erwan, I've heard you are working on a WidgetAbstractWrapper for dealing with dynamic widgets :) Is it still a work in progress or there's already something concrete? Cheers, Andrei

July 12, 2013

Re: [Pharo-dev] Some Spec questions

by Andrei Vasile Chis

Hi ClÃ©ment, Hi Clara, What about integrating the new debugger by default now ? I mean the new >> debugger is now in Pharo 3.0 alpha but the old debugger is still triggered >> by default, for example when you do Cmd+Maj+d or when you set the setting >> 'Always open full debugger'. We (Marcus and I) would like to integrate it >> now by default in Pharo 3.0 alpha, so we have enough time to stabilize it >> (in case of problems) and we can then remove the old debugger and old >> inspectors from Pharo. >> >> Now I want your point of view: >> - What do you think about integrating the spec debugger by default next >> week ? >> > In two weeks (22 July) I would visit you in Lille. That would be a good time to integrate. > - Is it currently stable enough ? >> > All the features that are present at the moment are quite stable. > - Should I wait a little more so you can add extra features ? >> > > I've talked with Andrei and we've set a "milestone". By next week, we > would like to have done issues > 10956 > 10952 > 10954 > 10953 > 10955 > If at least the first three issues are done, then the new debugger will have most of the necessary features. I'd also help with these and I hope we'll be done by the end of this month. > By next week I will have more time, since the semester will be finished. > >> >> > Having Andrei's debugger by default requires that it has the full stack >> menu ready before the Pharo 3.0 release (next spring), because if not >> people will blame all the Pharo team. >> - Are you working on it ? >> > That's what I plan to do next week :) I'm working on it, but not full time. > > >> - Will it be ready before the next Pharo release ? >> > >> If you think you need to improve the debugger before we integrate it by >> default, for example with Clara's GSoC work, please tell me when it will be >> ready so we can add it into the Pharo 3.0 integration planning. Then I >> guess you can add a slice with your improvements in the Pharo bug tracker, >> and I will add an extra slice with smalltalk tools change so the new >> debugger will be triggered by default. It would be nice if we can integrate >> it before the end of september. >> > We'll surely be able to have all the missing features by the end of September. They do not require so much work. > > In any case I will be in case with both Andrei and you (if you don't mind) > to get this done... > > Please do :) Cheers, Andrei

July 12, 2013

Re: [Pharo-dev] Recommendation for password encryption?

by Mariano Martinez Peck

On Fri, Jul 12, 2013 at 2:41 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > >> I want to prevent others from being able to read them. >> >> >>> Basically a password that is decryptable would be useless because in >>> order to make it secure you would need to store some other information to >>> decrypt it somewhere thus shifting the same problem from the password to >>> the "something else". >>> >>> >> Yes, but it would make things A LITTLE bit more complicated. One thing is >> to browse a simple .txt editor with ssh and another one is find the Pharo >> .image, open the image, search the code that decrypts, decrypt the password >> etc... So at least it adds some effort to the hacker :) >> >> >> Ok. What I meant is that if you encrypt the password, there is some >> password2 you need to encrypt the first password. I was assuming you don't >> want to keep a secret inside the image. And then it would be hard because >> password2 would need to be stored secure as well. If you are able to keep a >> secret in the image then this is a good idea and provides a different type >> of safety than the filesystem stuff. Well, you could add the filesystem >> protection as well and then you're ok. >> >> > mmmm sorry I didn't get it. password2 would be a "salt" in this case? > you could explain a bit more? > > But imagine that at some point I DO need to decrypt in the image side. > Which algorithm should I use in Pharo? > > I guess I need something like this: http://stackoverflow.com/questions/1132567/encrypt-password-in-configuratio… A two-way encryption algorithm for Pharo. That, besides with the filesystem permissions thingy :) Anyone knows what we have? Thanks, > Assuming you have encrypted password files I can also assume that the >>> process reading it is to be considered trusted. Otherwise it won't work >>> because the password needs to be in its decrypted form somewhere in this >>> process and this only works if you can trust the process. >>> >>> >> yes >> >> >>> This problem is often solved using filesystem permissions. Often >>> programs are started as root and so they can read files where root is the >>> only one having read permisson. After doing priviledged stuff the program >>> drops its priviledge and acts as a normal user. In case of a pharo image >>> that wouldn't be to easy. You could have a small program started as root >>> reads the information from the file and starts pharo as normal user passing >>> the information in. Or you could start pharo and another priviledged >>> program that reads the password file and sets the information in the pharo >>> image via socket or something similar. Or you are able to start the pharo >>> process with a dedicated user and arrange the filesystem permission in a >>> way that only this user has read access. Basically they are all the same. >>> >>> >> mmm i understand. Doesn't look easy. The last one "Or you are able to >> start the pharo process with a dedicated user and arrange the filesystem >> permission in a way that only this user has read access" sounds one more >> thing to do that could help. The only thing this can fail is if the user >> the hacker use to get inside is the same that runs Pharo or one with root >> provilegies. >> >> >> Exactly. If someone is able to gain root priviledge there is not much >> left you can do. >> > > Indeed. So the only particular concern for this case is if it get access > to the user than runs Pharo and that has read access to such files. > > >> That is one of the reasons why programs should have no special >> priviledges or drop them after doing important stuff. Writing a C >> application that starts your image, read password file and drops priviledge >> is not as hard as it sounds. Probably the way you pass the information to >> the image is a bit more. >> > > I understand. > > >> You certainly can not pass it as an argument to the image without further >> measurement because it would be visible by programs like ps. But there are >> ways to hide it or you can you use a pipe. >> >> If those are no options than it will be hard. Of course you can encypt >>> the password file itself but that won't work without extra measurement. >>> That is always the trap in thinking about security. The encryption of the >>> password file would be possible only if you have something you can decrypt >>> it with. And that information would have exactly the same security >>> implications as the password itself. Thus it solves nothing but only shifts >>> the responsibility for security to another piece of information. >>> >>> >> yes, but as I wrote a bit, it will make it a bit more complicated! >> >> >> >> Thanks Norbert for the ideas. >> >> My pleasure! >> >> Norbert >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

July 12, 2013

Re: [Pharo-dev] Recommendation for password encryption?

by Mariano Martinez Peck

> > > >> This problem is often solved using filesystem permissions. Often programs >> are started as root and so they can read files where root is the only one >> having read permisson. After doing priviledged stuff the program drops its >> priviledge and acts as a normal user. In case of a pharo image that >> wouldn't be to easy. You could have a small program started as root reads >> the information from the file and starts pharo as normal user passing the >> information in. Or you could start pharo and another priviledged program >> that reads the password file and sets the information in the pharo image >> via socket or something similar. Or you are able to start the pharo process >> with a dedicated user and arrange the filesystem permission in a way that >> only this user has read access. Basically they are all the same. >> >> > mmm i understand. Doesn't look easy. The last one "Or you are able to > start the pharo process with a dedicated user and arrange the filesystem > permission in a way that only this user has read access" sounds one more > thing to do that could help. The only thing this can fail is if the user > the hacker use to get inside is the same that runs Pharo or one with root > provilegies. > > > Exactly. If someone is able to gain root priviledge there is not much left > you can do. That is one of the reasons why programs should have no special > priviledges or drop them after doing important stuff. Writing a C > application that starts your image, read password file and drops priviledge > is not as hard as it sounds. Probably the way you pass the information to > the image is a bit more. You certainly can not pass it as an argument to > the image without further measurement because it would be visible by > programs like ps. But there are ways to hide it or you can you use a pipe. > > Norbert...just curious...I guess it's a good idea if I have no ssh access for the user that runs the Pharo image and that will likely have read access to such file, right? So that way they only way to get inside the system is with another user and then jump to the one than runs Pharo. So there are at least 2 users there and not one. It makes sense right? > If those are no options than it will be hard. Of course you can encypt the >> password file itself but that won't work without extra measurement. That is >> always the trap in thinking about security. The encryption of the password >> file would be possible only if you have something you can decrypt it with. >> And that information would have exactly the same security implications as >> the password itself. Thus it solves nothing but only shifts the >> responsibility for security to another piece of information. >> >> > yes, but as I wrote a bit, it will make it a bit more complicated! > > > > Thanks Norbert for the ideas. > > My pleasure! > > Norbert > > > -- Mariano http://marianopeck.wordpress.com

July 12, 2013

Re: [Pharo-dev] Some Spec questions

by Clara Allende

Hi ClÃ©ment, On 12 July 2013 13:09, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Andrei, Clara, > > What about integrating the new debugger by default now ? I mean the new > debugger is now in Pharo 3.0 alpha but the old debugger is still triggered > by default, for example when you do Cmd+Maj+d or when you set the setting > 'Always open full debugger'. We (Marcus and I) would like to integrate it > now by default in Pharo 3.0 alpha, so we have enough time to stabilize it > (in case of problems) and we can then remove the old debugger and old > inspectors from Pharo. > > Now I want your point of view: > - What do you think about integrating the spec debugger by default next > week ? > - Is it currently stable enough ? > - Should I wait a little more so you can add extra features ? > I've talked with Andrei and we've set a "milestone". By next week, we would like to have done issues 10956 10952 10954 10953 10955 By next week I will have more time, since the semester will be finished. > > Having Andrei's debugger by default requires that it has the full stack > menu ready before the Pharo 3.0 release (next spring), because if not > people will blame all the Pharo team. > - Are you working on it ? > That's what I plan to do next week :) I'm working on it, but not full time. > - Will it be ready before the next Pharo release ? > > If you think you need to improve the debugger before we integrate it by > default, for example with Clara's GSoC work, please tell me when it will be > ready so we can add it into the Pharo 3.0 integration planning. Then I > guess you can add a slice with your improvements in the Pharo bug tracker, > and I will add an extra slice with smalltalk tools change so the new > debugger will be triggered by default. It would be nice if we can integrate > it before the end of september. > In any case I will be in case with both Andrei and you (if you don't mind) to get this done... Cheers! Clari > > If you think it is ready, I will set the current version by default next > week. > > It is also possible that I integrate the current version by default next > week and then later you do a slice with improvements. > > :) > > > 2013/7/11 Clara Allende <clari.allende(a)gmail.com> > >> Great! Thank you guys :) >> >> >> On 11 July 2013 05:17, Andrei Vasile Chis <chisvasileandrei(a)gmail.com>wrote: >> >>> >>> Actually Erwan Douaille is doing WidgetAbstractWrapper to solve this >>>> problem (I've just learnt that a few minutes ago). You may discuss with him >>>> about that. >>>> >>> >>> Super. Thanks for all the help and the info >>> >>> Andrei >>> >> >> >

July 12, 2013

Re: [Pharo-dev] Recommendation for password encryption?

by Mariano Martinez Peck

> > > I want to prevent others from being able to read them. > > >> Basically a password that is decryptable would be useless because in >> order to make it secure you would need to store some other information to >> decrypt it somewhere thus shifting the same problem from the password to >> the "something else". >> >> > Yes, but it would make things A LITTLE bit more complicated. One thing is > to browse a simple .txt editor with ssh and another one is find the Pharo > .image, open the image, search the code that decrypts, decrypt the password > etc... So at least it adds some effort to the hacker :) > > > Ok. What I meant is that if you encrypt the password, there is some > password2 you need to encrypt the first password. I was assuming you don't > want to keep a secret inside the image. And then it would be hard because > password2 would need to be stored secure as well. If you are able to keep a > secret in the image then this is a good idea and provides a different type > of safety than the filesystem stuff. Well, you could add the filesystem > protection as well and then you're ok. > > mmmm sorry I didn't get it. password2 would be a "salt" in this case? you could explain a bit more? But imagine that at some point I DO need to decrypt in the image side. Which algorithm should I use in Pharo? > Assuming you have encrypted password files I can also assume that the >> process reading it is to be considered trusted. Otherwise it won't work >> because the password needs to be in its decrypted form somewhere in this >> process and this only works if you can trust the process. >> >> > yes > > >> This problem is often solved using filesystem permissions. Often programs >> are started as root and so they can read files where root is the only one >> having read permisson. After doing priviledged stuff the program drops its >> priviledge and acts as a normal user. In case of a pharo image that >> wouldn't be to easy. You could have a small program started as root reads >> the information from the file and starts pharo as normal user passing the >> information in. Or you could start pharo and another priviledged program >> that reads the password file and sets the information in the pharo image >> via socket or something similar. Or you are able to start the pharo process >> with a dedicated user and arrange the filesystem permission in a way that >> only this user has read access. Basically they are all the same. >> >> > mmm i understand. Doesn't look easy. The last one "Or you are able to > start the pharo process with a dedicated user and arrange the filesystem > permission in a way that only this user has read access" sounds one more > thing to do that could help. The only thing this can fail is if the user > the hacker use to get inside is the same that runs Pharo or one with root > provilegies. > > > Exactly. If someone is able to gain root priviledge there is not much left > you can do. > Indeed. So the only particular concern for this case is if it get access to the user than runs Pharo and that has read access to such files. > That is one of the reasons why programs should have no special priviledges > or drop them after doing important stuff. Writing a C application that > starts your image, read password file and drops priviledge is not as hard > as it sounds. Probably the way you pass the information to the image is a > bit more. > I understand. > You certainly can not pass it as an argument to the image without further > measurement because it would be visible by programs like ps. But there are > ways to hide it or you can you use a pipe. > > If those are no options than it will be hard. Of course you can encypt the >> password file itself but that won't work without extra measurement. That is >> always the trap in thinking about security. The encryption of the password >> file would be possible only if you have something you can decrypt it with. >> And that information would have exactly the same security implications as >> the password itself. Thus it solves nothing but only shifts the >> responsibility for security to another piece of information. >> >> > yes, but as I wrote a bit, it will make it a bit more complicated! > > > > Thanks Norbert for the ideas. > > My pleasure! > > Norbert > > > -- Mariano http://marianopeck.wordpress.com

July 12, 2013

Re: [Pharo-dev] Recommendation for password encryption?

by Norbert Hartl

Am 12.07.2013 um 19:05 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > > On Fri, Jul 12, 2013 at 11:44 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 12.07.2013 um 15:47 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> Hi guys. Some time ago I asked about the best way to encrypt a password. Some of the recommendations I got was: >> >> 1) Generally for passwords you do not write a decrypt method for security purposes (eg you do not want people to be able to reverse engineer the encrypted password easily) >> 2) put a little salt >> 3) There is http://www.squeaksource.com/Cryptography/PasswordHashingFFI >> 4) I should not decrypt password but instead I should compare both encrypted versions to see if they are equal. >> >> My scenario is the following. I need to store database passwords in text files. So I don't want to let them as plain text. And while I understand 4), I think it's a different scenario than mine. I know that some database driver may allow you to directly send the encrypted password. But still...I have another similar scenario in which I have to store a password and then send it (unencrypted)...so I kind of really need a bi-directional encryption. >> >> Now..I would try to avoid having an external library + FFI. Any ideas what is the best thing I can do? And how could I solve 1) if I want bidirectional like in my case? >> > > "I know that some database driver may allow you to directly send the encrypted password". > That would be the same as having no encryption at all. Everyone knowing the encrypted password could authenticate. > > > Indeed. > > I'm not sure I understand the complete requirements. Do you really don't want to store them as plain text files or do you want to prevent others from being able to read them? > > > I want to prevent others from being able to read them. > > Basically a password that is decryptable would be useless because in order to make it secure you would need to store some other information to decrypt it somewhere thus shifting the same problem from the password to the "something else". > > > Yes, but it would make things A LITTLE bit more complicated. One thing is to browse a simple .txt editor with ssh and another one is find the Pharo .image, open the image, search the code that decrypts, decrypt the password etc... So at least it adds some effort to the hacker :) > Ok. What I meant is that if you encrypt the password, there is some password2 you need to encrypt the first password. I was assuming you don't want to keep a secret inside the image. And then it would be hard because password2 would need to be stored secure as well. If you are able to keep a secret in the image then this is a good idea and provides a different type of safety than the filesystem stuff. Well, you could add the filesystem protection as well and then you're ok. > Assuming you have encrypted password files I can also assume that the process reading it is to be considered trusted. Otherwise it won't work because the password needs to be in its decrypted form somewhere in this process and this only works if you can trust the process. > > > yes > > This problem is often solved using filesystem permissions. Often programs are started as root and so they can read files where root is the only one having read permisson. After doing priviledged stuff the program drops its priviledge and acts as a normal user. In case of a pharo image that wouldn't be to easy. You could have a small program started as root reads the information from the file and starts pharo as normal user passing the information in. Or you could start pharo and another priviledged program that reads the password file and sets the information in the pharo image via socket or something similar. Or you are able to start the pharo process with a dedicated user and arrange the filesystem permission in a way that only this user has read access. Basically they are all the same. > > > mmm i understand. Doesn't look easy. The last one "Or you are able to start the pharo process with a dedicated user and arrange the filesystem permission in a way that only this user has read access" sounds one more thing to do that could help. The only thing this can fail is if the user the hacker use to get inside is the same that runs Pharo or one with root provilegies. > Exactly. If someone is able to gain root priviledge there is not much left you can do. That is one of the reasons why programs should have no special priviledges or drop them after doing important stuff. Writing a C application that starts your image, read password file and drops priviledge is not as hard as it sounds. Probably the way you pass the information to the image is a bit more. You certainly can not pass it as an argument to the image without further measurement because it would be visible by programs like ps. But there are ways to hide it or you can you use a pipe. > If those are no options than it will be hard. Of course you can encypt the password file itself but that won't work without extra measurement. That is always the trap in thinking about security. The encryption of the password file would be possible only if you have something you can decrypt it with. And that information would have exactly the same security implications as the password itself. Thus it solves nothing but only shifts the responsibility for security to another piece of information. > > > yes, but as I wrote a bit, it will make it a bit more complicated! > > Thanks Norbert for the ideas. > My pleasure! Norbert

July 12, 2013

Re: [Pharo-dev] Recommendation for password encryption?

by Mariano Martinez Peck

On Fri, Jul 12, 2013 at 11:44 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 12.07.2013 um 15:47 schrieb Mariano Martinez Peck < > marianopeck(a)gmail.com>: > > Hi guys. Some time ago I asked about the best way to encrypt a password. > Some of the recommendations I got was: > > 1) Generally for passwords you do not write a decrypt method for security > purposes (eg you do not want people to be able to reverse engineer the > encrypted password easily) > 2) put a little salt > 3) There is http://www.squeaksource.com/Cryptography/PasswordHashingFFI > 4) I should not decrypt password but instead I should compare both > encrypted versions to see if they are equal. > > My scenario is the following. I need to store database passwords in text > files. So I don't want to let them as plain text. And while I understand > 4), I think it's a different scenario than mine. I know that some database > driver may allow you to directly send the encrypted password. But still...I > have another similar scenario in which I have to store a password and then > send it (unencrypted)...so I kind of really need a bi-directional > encryption. > > Now..I would try to avoid having an external library + FFI. Any ideas what > is the best thing I can do? And how could I solve 1) if I want > bidirectional like in my case? > > > "I know that some database driver may allow you to directly send the > encrypted password". > That would be the same as having no encryption at all. Everyone knowing > the encrypted password could authenticate. > > Indeed. > I'm not sure I understand the complete requirements. Do you really don't > want to store them as plain text files or do you want to prevent others > from being able to read them? > > I want to prevent others from being able to read them. > Basically a password that is decryptable would be useless because in order > to make it secure you would need to store some other information to decrypt > it somewhere thus shifting the same problem from the password to the > "something else". > > Yes, but it would make things A LITTLE bit more complicated. One thing is to browse a simple .txt editor with ssh and another one is find the Pharo .image, open the image, search the code that decrypts, decrypt the password etc... So at least it adds some effort to the hacker :) > Assuming you have encrypted password files I can also assume that the > process reading it is to be considered trusted. Otherwise it won't work > because the password needs to be in its decrypted form somewhere in this > process and this only works if you can trust the process. > > yes > This problem is often solved using filesystem permissions. Often programs > are started as root and so they can read files where root is the only one > having read permisson. After doing priviledged stuff the program drops its > priviledge and acts as a normal user. In case of a pharo image that > wouldn't be to easy. You could have a small program started as root reads > the information from the file and starts pharo as normal user passing the > information in. Or you could start pharo and another priviledged program > that reads the password file and sets the information in the pharo image > via socket or something similar. Or you are able to start the pharo process > with a dedicated user and arrange the filesystem permission in a way that > only this user has read access. Basically they are all the same. > > mmm i understand. Doesn't look easy. The last one "Or you are able to start the pharo process with a dedicated user and arrange the filesystem permission in a way that only this user has read access" sounds one more thing to do that could help. The only thing this can fail is if the user the hacker use to get inside is the same that runs Pharo or one with root provilegies. > If those are no options than it will be hard. Of course you can encypt the > password file itself but that won't work without extra measurement. That is > always the trap in thinking about security. The encryption of the password > file would be possible only if you have something you can decrypt it with. > And that information would have exactly the same security implications as > the password itself. Thus it solves nothing but only shifts the > responsibility for security to another piece of information. > > yes, but as I wrote a bit, it will make it a bit more complicated! Thanks Norbert for the ideas. -- Mariano http://marianopeck.wordpress.com

July 12, 2013