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

Re: [Pharo-dev] Athens + Amber progress

by Camille Teruel

Awesome!! On 12 juil. 2013, at 17:51, Igor Stasenko wrote: > Hi, i just wanna share news about progress on subject GSoC project. > > Matthew made quite decent progress on the subject. It is almost there, > just some glitches here and there, > but in overall, i am quite happy, and i think it is already in quite > useful state. > > To check it, just follow the link on your browser: > > http://matthias-springer.github.io/amber-athens/ > > (works best with chrome then firefox) > > For impatient: > > go to step 2, press doit, > then skip to step 32 and press doit again > > :) > > -- > Best regards, > Igor Stasenko. >

July 12, 2013

Athens + Amber progress

by Igor Stasenko

Hi, i just wanna share news about progress on subject GSoC project. Matthew made quite decent progress on the subject. It is almost there, just some glitches here and there, but in overall, i am quite happy, and i think it is already in quite useful state. To check it, just follow the link on your browser: http://matthias-springer.github.io/amber-athens/ (works best with chrome then firefox) For impatient: go to step 2, press doit, then skip to step 32 and press doit again :) -- Best regards, Igor Stasenko.

July 12, 2013

[NB]: Review & fixes & ideas

by Igor Stasenko

Hi, there , i've been working last two weeks on reviewing the code in NB, and update configuration & making tests green etc.. So, here the summary: 0. New stuff: external structures (NBExternalStructure) now is normal objects (not var-byte ones), and using 'data' ivar indirection like in NBExternalArray, so you can allocate external struct on both external heap and object memory, e.g.: struct := MyStructClass externalNew. or: struct := MyStructClass new. (so, it is similar to NBExternalArray). - a function with signature MyStruct * foo () which returns a pointer to struct, now will return an instance of MyStruct with the address, so you can use it directly , e.g.: struct := self callFoo. value := struct field1. struct field2: 10 etc.. Thanks to Ciprian for introducing the change. I just polished a bit and fixed some mistakes. 1. NBExternalTypeValue>>address should not exist. You simply cannot use freely an address to object's internal field because object can move in memory. (the tests in NBFFIExternalValueTests testOutIntArg testOutValueArg testOutVoidArg is changed accordingly) 2. In NBExternalEnumerationType: pushing a pointer to this type is not allowed, since it makes no sense. But the mistake there was to generate a code which fails primitive with an error message, instead of failing much much sooner - at code generation stage, since it is already known that user specified wrong type. 3. I reverting generic pushAsPointer: to accept varbyte objects instead of just ByteArray object. - removing #specialPush:asPointer:endLabel: because it will be not used (btw, in NBExternalStructureType>>specialPush:asPointer:endLabel: , there was same mistake that it generates code to checking a pointer arity at runtime, while it is already known during code generation time: asm decorateWith: 'arity checking' during: [ |pointerArityOk| pointerArityOk := asm uniqueLabelName: 'pointerArityOk'. asm mov: pointerArity asImm32 to: asm EAX; cmp: asm EAX with: 1 asImm32; je: pointerArityOk. gen failWithMessage: 'Arity ', pointerArity printString,' not allowed for ', objectClass name, 'objects'. asm label: pointerArityOk]. since pointerArity is known, the produced code will be something like: mov: 1 to: EAX; cmp: EAX with: 1; je: pointerArityOk and makes no sense, because again it can just throw the error at code generation time. 4. Added code to capture argument names (CompiledMethod>>nbArgumentNames) and 'NativeBoost prepareForProduction', to ensure NB can work without source code accessible. 5. But the general expression, like in (1): object address gave me an interesting idea: what if we introduce a special type, say NBObjectFieldAddress. Consider the following problem: imagine that you have a big array in object memory (byte array), and you want to pass a pointer to n-th element of that array to some function. Right now, there is no way how you can do it, and you can pass only a pointer to array itself (which means it will always point to its first element). So, the idea is to introduce a special type, and special object which represents the address-of-object's-field, so you can tell: array := ByteArray new: 1000. address := array nbAddressAt: 500. "create an address object which points to 500th element of given array" (and expression 'array nbAddress' is synonym to 'array nbAddressAt: 1'). self callSomeFunctionWith: address. The signature of C function which takes a pointer like: void foo (void * ptr) then should be changed to: void foo (NBObjectFieldAddress ptr) the only question, which remains , shall it use strict type checking (so you have to change the signature), or allow to use such objects with any signatures which takes a pointer to something, e.g. extend generic NBExternalType>>pushAsPointer: to additionally check if incoming argument is instance of NBObjectFieldAddress class. P.S. to try new config , load it: Gofer new smalltalkhubUser: 'Pharo' project: 'NativeBoost'; configuration; load. ConfigurationOfNativeBoost loadDevelopment. "which should load 2.2 version of it" -- Best regards, Igor Stasenko.

July 12, 2013

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

by Sven Van Caekenberghe

On 12 Jul 2013, at 16:44, Norbert Hartl <norbert(a)hartl.name> wrote: > Maybe you can specify your problem a bit more so. I think what he basically means: the app needs to access the db, for which it needs a db password. How should he store it ? It also depends if there is only one db password, or one for each user, and in the latter case, if it is the same as the one entered by the user. But maybe, I am guessing wrong.

July 12, 2013

[update 2.0] #20613

by Marcus Denker

20613 ----- 11132 Backport to 2.0: Convert MetacelloConfigurationBrowser to Spec https://pharo.fogbugz.com/f/cases/11132 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.1062.diff

July 12, 2013

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

by Norbert Hartl

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. 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? 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". 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. 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. 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. Maybe you can specify your problem a bit more so. Norbert

July 12, 2013

Re: [Pharo-dev] @lab at midday

by Norbert Hartl

Am 12.07.2013 um 14:00 schrieb Damien Cassou <damien.cassou(a)gmail.com>: > On Fri, Jul 12, 2013 at 12:52 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> Au repertoire, > > > ??? > Ok, that seems to only work for non-native french speakers :) Although it is stupid to explain jokes this should be a proof of my capabilities of speaking french. If I would know how to speak it I probably would have written "Au revoir" insteadâ¦ >> Norber' > t > :-) > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

July 12, 2013

Re: [Pharo-dev] Fwd: Build failed in Jenkins: Nand2Tetris Â» 30,bleedingEdge,vm #184

by Damien Cassou

On Fri, Jul 12, 2013 at 2:14 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > ClassBuilder problems most probably. > Should be resolved as of noon today :) works fine, thank you. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

July 12, 2013

Recommendation for password encryption?

by Mariano Martinez Peck

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? Thanks in advance, -- Mariano http://marianopeck.wordpress.com

July 12, 2013

[update 3.0] #30269

by Marcus Denker

30269 ----- 11154 Update Opal to latest version https://pharo.fogbugz.com/f/cases/11154 This update includes all these fixes: 11035 VMMaker compiling error 10942 OCASTClosureAnalyzer should be referenced just in OCASTSemanticAnalyzer 10964 Temp vars shown multiple times in debugger context inspector 11122 Temp mapping not working sometimes 11134 Undeclared class not shown in Transcript 11137 add IRBuilder buildMethod: 11133 AdditionalMethodState only when needed We recompile the whole image in the postscript, mostly for 11133. Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Tests-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke…

July 12, 2013