July 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] My Del key not works anymore

by Stephan Eggermont

Igor wrote: >can i have it back, I haven't had a Del key on my Macs since 1990 or so. Fn Backspace to delete (US Intl) works for me. What keyboard layout do you use? Stephan

July 15, 2013

Re: [Pharo-dev] [DOC] Building and deploying your first web app with Pharo

by Igor Stasenko

since you gave listing at the end of page, i wonder, how much PHP (yes! :) code it would take to implement same app? :) of course , PHP is not really fair comparison, since it doesn't implements full HTTP stack, nor it deals with HTTP requests directly as Zinc does, and runs on top of web server which does that for it. On 15 July 2013 13:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > I wrote a new tutorial, "Building and deploying your first web app with Pharo - Understanding HTTP fundamentals through Zinc HTTP Components". > > By chronologically following the development process, you will see a small web app growing from something trivial to the final result. Finally, we will save our source code in a repository and deploy for real in the cloud. > > http://zn.stfx.eu/zn/build-and-deploy-1st-webapp > > Pharo 2.0/3.0 features such as Nautilus, SmalltalkHub, Metacello Configurations, Zeroconf Scripts and of course Zinc HTTP Components are used while highlighting traditional strengths such as incremental, live & interactive development in a rich environment. > > Enjoy, > > Sven > > PS: Feedback is welcome, the source document lives here https://github.com/svenvc/zinc/blob/master/build-and-deploy-1st-webapp/buil… - pull requests appreciated. > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > -- Best regards, Igor Stasenko.

July 15, 2013

My Del key not works anymore

by Igor Stasenko

i don't know who or what changed in mac vms, but now when i press Del key, it produces '?' instead of deleting characters.. which is highly annoying because i get used to it over all my life. can i have it back, please? -- Best regards, Igor Stasenko.

July 15, 2013

Re: [Pharo-dev] [Pharo-users] [DOC] Building and deploying your first web app with Pharo

by Sven Van Caekenberghe

On 15 Jul 2013, at 13:15, Camillo Bruni <camillobruni(a)gmail.com> wrote: > very nice! Thanks, someone already put it on http://www.reddit.com/r/programming/comments/1ic883/building_and_deploying_… but needs comments/votes ;-) > On 2013-07-15, at 13:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Hi, >> >> I wrote a new tutorial, "Building and deploying your first web app with Pharo - Understanding HTTP fundamentals through Zinc HTTP Components". >> >> By chronologically following the development process, you will see a small web app growing from something trivial to the final result. Finally, we will save our source code in a repository and deploy for real in the cloud. >> >> http://zn.stfx.eu/zn/build-and-deploy-1st-webapp >> >> Pharo 2.0/3.0 features such as Nautilus, SmalltalkHub, Metacello Configurations, Zeroconf Scripts and of course Zinc HTTP Components are used while highlighting traditional strengths such as incremental, live & interactive development in a rich environment. >> >> Enjoy, >> >> Sven >> >> PS: Feedback is welcome, the source document lives here https://github.com/svenvc/zinc/blob/master/build-and-deploy-1st-webapp/buil… - pull requests appreciated. >> >> -- >> Sven Van Caekenberghe >> Proudly supporting Pharo >> http://pharo.org >> http://association.pharo.org >> http://consortium.pharo.org >> >> > >

July 15, 2013

Re: [Pharo-dev] [DOC] Building and deploying your first web app with Pharo

by Sven Van Caekenberghe

On 15 Jul 2013, at 14:18, Stephan Eggermont <stephan(a)stack.nl> wrote: > Nice work, Sven! > > "You can optionally use an SSH key pair to log in, just skip this option if you are uncomfortable with this" > > Do you want to explain that logging in as root is not a good idea? Something like: > > It is not needed to get started, but highly recommended for production images or when using multiple servers. > Some more advice can be found on > https://www.digitalocean.com/community/articles/how-to-use-ssh-keys-with-di… > and > http://plusbryan.com/my-first-5-minutes-on-a-server-or-essential-security-f… > > Stephan Thanks, Stephan, I added an extra phrase and link to the first article in my local draft. Sven

July 15, 2013

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

by Sven Van Caekenberghe

On 15 Jul 2013, at 16:29, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 12.07.2013 um 20:11 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> >>> >>> 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? >> > Not to me :) It's like I tried to explain lately with the password encrypted with a password. If it comes to security you can always make things more complicated and building chains. In the end the security is defined by its weakest link. So you need to find out where are weaknesses. > > Assuming that if you can login via ssh it doesn't mean anyone else can. Basically there are two possibilities. Either ssh has a security hole or you loose your key with password. What else should happen? If ssh has a security hole it doesn't matter which user tries to log in. And using another user means that someone is on the machine. I think getting access to a machine is a _much_ more difficult than to get root access if you are loggend into a machine. > > So my advise would be: Smalltalk and security are the two ends of the productivity scale. While smalltalk can make you really productive, security can keep you from achieving anything. Btw. that is the reason why I decided to go for programming instead of security 15 years ago. > > So instead making it complicated for yourself without gaining anything you need to define exactly what is the scope that you want to protect and against which measuements you want to protect yourself. > > If you don't trust ssh order a KVM switch with remote capabilities at your provider. With that you can have access to the console of the computer and you can turn off ssh completely. But how do you copy files to the machine thenâ¦.??? Ah and btw. while we are at it. I hope you don't use linux. Why designing a tight security strategy if you put it on top of an immature operating system? Use OpenBSD instead! > I hope you can see what I'm trying to tell you. There is no such thing as security. There is only a probability that someone breaks into your machine. Lowering this probability means most of the time making the system a lot more cumbersome. So for every project there is a setting that leverages best for the needs. But before that you have to know what is really necessary so put a probability onto every measurement and not try to be too paranoid. I also don't understand the fuss, unless it is for a banking application that needs to adhere to some hard standard for certification (in which case you need help from people specialised in that area anyway). Having critical information in config files (/etc, ~/.ssh, the server's HTTPS private certificates and so on) is almost unavoidable and why should you not trust your machine ? The next question then is, can you trust keeping a password in RAM ? If security is managed well on the machine and you don't do stupid things, you should be OK. Some sysadmin friend could do an audit, for example. If someone gets (root) access to the machine that would be a catastrophic event anyway ;-) Sven > Norbert > >> >> >>> 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 15, 2013

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

by Norbert Hartl

Am 12.07.2013 um 20:11 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> >> >> 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? > Not to me :) It's like I tried to explain lately with the password encrypted with a password. If it comes to security you can always make things more complicated and building chains. In the end the security is defined by its weakest link. So you need to find out where are weaknesses. Assuming that if you can login via ssh it doesn't mean anyone else can. Basically there are two possibilities. Either ssh has a security hole or you loose your key with password. What else should happen? If ssh has a security hole it doesn't matter which user tries to log in. And using another user means that someone is on the machine. I think getting access to a machine is a _much_ more difficult than to get root access if you are loggend into a machine. So my advise would be: Smalltalk and security are the two ends of the productivity scale. While smalltalk can make you really productive, security can keep you from achieving anything. Btw. that is the reason why I decided to go for programming instead of security 15 years ago. So instead making it complicated for yourself without gaining anything you need to define exactly what is the scope that you want to protect and against which measuements you want to protect yourself. If you don't trust ssh order a KVM switch with remote capabilities at your provider. With that you can have access to the console of the computer and you can turn off ssh completely. But how do you copy files to the machine thenâ¦.??? Ah and btw. while we are at it. I hope you don't use linux. Why designing a tight security strategy if you put it on top of an immature operating system? Use OpenBSD instead! I hope you can see what I'm trying to tell you. There is no such thing as security. There is only a probability that someone breaks into your machine. Lowering this probability means most of the time making the system a lot more cumbersome. So for every project there is a setting that leverages best for the needs. But before that you have to know what is really necessary so put a probability onto every measurement and not try to be too paranoid. Norbert > > >> 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 15, 2013

Re: [Pharo-dev] Ubuntu apt install

by Damien Cassou

On Mon, Jul 15, 2013 at 3:01 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > add-apt-repository is an unknown command in minimal Ubuntu installs (like on servers) and thanks for the report. I've updated http://www.pharo-project.org/pharo-download/ubuntu -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

July 15, 2013

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

by Mariano Martinez Peck

On Sun, Jul 14, 2013 at 9:46 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > > Hi Mariano, > > You shouldn't use it. Its broken. I didn't realize until just now. But I > also haven't been using it. > > ohh what a pity :( I was planning to use it! > > To encrypt the db password do > > enc:=Blowfish encryptString:'myDbPassword' with: 'mySecretKey' > > and to decrypt it later do > > Blowfish decryptToString: enc with: 'mySecretKey' > > I tried that. But..in my case, the "enc" I should store it in a file, so I need the string rather than the bytearray. So I did: | enc encryptedString decr decrString | enc:=Blowfish encryptString:'test' with: 'mySecretKey'. encryptedString := enc asByteArray asString. Transcript show: ' encrypted: ', encryptedString; cr. and encryptedString is that I would store in the file. And then to decrypt: decr := Blowfish decryptString: encryptedString with: 'mySecretKey'. decrString := decr asByteArray asString. Transcript show: ' decrypted: ', decrString; cr. but there are several problems: 1) I cannot encrypt passwords smaller than 8 characters neither bigger (as you noted). Not a big problem. But I may be using this same algorithm for something else in where I may have smaller paswords (but I am not sure). 2) I am not sure I am doing fine with the encoding and the strings... (conversion between bytearray and string) 3) the decryption doesn't work for me... :( If you fix, please let me know!! If I can help/test, also. Thanks, > > But if you decrypt it with the key '1234' you get > > 'Ã« "~Ã½Ã£Ã®fword' > > which shows its only encrypting the first 8 bytes. And if your db password > is 30 chars long like this one: > > '123456789012345678901234567890' then the leaked info is the last 22 > numbers. > > The tests aren't covering this error yet. I'll mess with it sometime soon > and get it sorted but for now its broken and shouldn't be used. Unless > your > DB password is 8 bytes or less. > > > > > > > > > -- > View this message in context: > http://forum.world.st/Pharo-dev-Recommendation-for-password-encryption-tp46… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

July 15, 2013

Re: [Pharo-dev] Ubuntu apt install

by Damien Cassou

On Mon, Jul 15, 2013 at 3:01 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > add-apt-repository is an unknown command in minimal Ubuntu installs (like on servers) in fact, you just have to add 1 line in /etc/apt/sources.list or add a new file in /etc/apt/sources.list.d -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

July 15, 2013