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

[update 3.0] #30272

by Marcus Denker

30272 ----- 11164 ASTInterpreterTest >> #testSignalHalt failing https://pharo.fogbugz.com/f/cases/11164 11086 Failing MCSnapshotBrowserTest >> #testClassSelected, #testMethodSelected and #testProtocolSelected https://pharo.fogbugz.com/f/cases/11086 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-MarcusDenker.588.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/MonticelloGUI-MarcusDenker.24… http://smalltalkhub.com/mc/Pharo/Pharo30/main/AST-Interpreter-Test-MarcusDe…

July 16, 2013

Re: [Pharo-dev] [update 3.0] #30272

by Tudor Girba

Wrong list :) Doru On Jul 16, 2013, at 8:57 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 30272 > ----- > > 11164 ASTInterpreterTest >> #testSignalHalt failing > https://pharo.fogbugz.com/f/cases/11164 > > 11086 Failing MCSnapshotBrowserTest >> #testClassSelected, #testMethodSelected and #testProtocolSelected > https://pharo.fogbugz.com/f/cases/11086 > > > Diff information: > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-MarcusDenker.588.diff > http://smalltalkhub.com/mc/Pharo/Pharo30/main/MonticelloGUI-MarcusDenker.24… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/AST-Interpreter-Test-MarcusDe… > -- www.tudorgirba.com "Speaking louder won't make the point worthier."

July 16, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=mac/… 1 regressions found. Tests.CodeImport.ChunkImportTestCase.testImportAClassCategory

July 16, 2013

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

by Norbert Hartl

Am 15.07.2013 um 22:42 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: > Ahh another question, sorry. With this cipher a "salt" would make almost no sense since I already need a key? > or it make sense to put a "salt" together with the string to ecnrypt? > That is up to you. That is what I was trying to explain to you. You always need a key/secret to encrypt. A salt is just a little more of information that diverses that outcoming value of a hash. A hash is a one way calculation from an input string to an output string in a uniform way. Meaning the same input with same algorithm is always the same output. One way to test a cryptographic string is using rainbow tables. These are big tables consisting of the outcome of hash calculations (fast compare vs. slow calculate). By adding a salt you make it harder to have these tables because you still need to calculate or need to expand the tables of results. But as a salt is an input to the hashing function it only works if the salt is included in the input _and_ the output. Meaning you need to add the salt to the output. In the unix passwd file for instance the first two character of the password hash is the salt. You take it from encrypted string and encrypt the password with the salt to get the output you can compare with the encrypted string (the string with salt stripped off). So in any algorithm you can add a salt and prefix the output with the same salt. The difference between algorithms is how expensive they are to calculate. The best algorithm takes an awful time to compute. In this case if you send the right password it takes an acceptable amount of time to verify (one calculation) but if someone tries to brute force your password it will take way too long to make it feasible to try. To encrypt something between two parties some information needs to be shared. If the algorithm use is shared you need to tranfer the password in cleartext to the second instance and the second instance can encrypt it the same way and compare. Sharing a secret between the parties you can transfer the encrypted string because the other part can decrypt the string and can compare the password (but you have to transfer the secret somehow). In an asymmetric environment where there is a key pair where everything one key encrypts the other key can decrypt you just can share the other key to the second instance and you are able to transfer an encrypted string. So whatever you do you need to decide what approach to use and what information is best to share. If you look on SSL you have everything in combination. First there is an asymmetric key exchange (expensive) that is used to exchange a shared secret. After the negotiation the network will be encrypted using the shared secret which is much less expensive saving CPU cycles. Norbert > > On Mon, Jul 15, 2013 at 5:39 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > Blowfish is a 8 byte block cipher so for shorter strings I'll need to pad > the byte array, and for longer strings I'll need to make it use cipher block > chaining: > (https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher-block_…) > > > Ok, I imagined something like that. Thanks for the explanation. > For my usecase, I think this is not the more critical thing since I would use a 8 character password for sure :) > > > > If you change #decryptString:with: to: > > Blowfish class>>decryptString: aString with: aKey > |decryptedData | > decryptedData := (self new ecbDecrypt: aString asByteArray with: aKey > asByteArray ). > ^String fromByteArray: decryptedData asByteArray . > > Then this workspace code should work: > > | enc encryptedString dkey decrString | > key:='mySecretKey'. > enc:=Blowfish encryptString:'12345678' with: key. > encryptedString := enc asByteArray asString. > Transcript show: ' encrypted: ', encryptedString; cr. > decrString:=Blowfish decryptString: encryptedString with: key. > Transcript show: ' decrypted: ', decrString; cr. > > > > Thanks!! That worked. Now...there is no problem with the encoding then? > Because I would need to store/retrieve the string from a file stream...so I didn't know if I should use a TextConverter or not. > > Thanks in advance, > > > But with the password 'test' it will always fail because I'm not yet padding > the byte array to a multiple of 8 bytes before encrypting it. > > > > Thanks for your patience > > > Paul > > > > -- > 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 > > > > -- > Mariano > http://marianopeck.wordpress.com

July 15, 2013

Re: [Pharo-dev] Job: from Exceptions to Announcements?

by Martin Dias

Ok, I'm interested since I'm working in an experimental extension. In 3.0, JobStartNotification is the only used exception. The other one, JobProgress, is only referenced from tests. I put a halt in #handleJobProgress: to check and it didn't stop. I would like to discuss about paralel jobs too. MartÃn On Mon, Jul 15, 2013 at 9:35 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > Hi, this actually emerged from a discussion with Sean, because he didn't like > exceptions based notifications :). But all in all there is no big change needed. > > I think the UI will work anyway passively, there should be a refresh loop that > checks 15-times per second the status of the active jobs and updates the UI progress > bar accordingly. > > So I think there shouldn't be many more changes? Maybe we can quickly have a look > at it together... > > On 2013-07-15, at 19:00, Martin Dias <tinchodias(a)gmail.com> wrote: >> Hi, >> >> I am looking into SystemProgressMorph and I found this flag in several methods: >> >> self flag: 'When we go from Exceptions to announcements, delete this >> and use show:from:to:during:'. >> >> I'd like to know more. I see that Jobs are implemented with both >> exceptions and announcements... what is the idea? to remove the >> exceptions and use only announcements? >> >> Thank you for your help, >> MartÃn >> > >

July 15, 2013

Re: [Pharo-dev] OpenDBX problem with simultaneus connections

by Facundo Vozzi

Mariano, It works fine now. Thanks On Fri, Jul 12, 2013 at 8:51 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > No, GlorpOpenDBXDriver-MarianoMartinezPeck.16 in ' > http://www.smalltalkhub.com/mc/DBXTalk/Glorp/main' > > > On Thu, Jul 11, 2013 at 11:55 PM, Facundo Vozzi <facundov79(a)gmail.com>wrote: > >> Mariano, >> is OpenDBXDriver-MarianoMartinezPeck.38 your last commit? >> >> Thanks >> >> >> On Thu, Jul 11, 2013 at 5:21 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> I recommend to update to the last commit I did... >>> Otherwise, if you were using different instances of Login for each >>> session you should have several SelmaConnectionPool alive :) (rather than 1) >>> >>> >>> On Sat, Jul 6, 2013 at 5:54 PM, Facundo Vozzi <facundov79(a)gmail.com>wrote: >>> >>>> Thanks Esteban. >>>> >>>> Now, I changed GlorpOpenDBXPoolingDriver for GlorpOpenDBXDriver and all >>>> is working properly. I'll try to fix the problem because I think that will >>>> be a problem the number of postgres.exe process running on the server this >>>> way. >>>> >>>> >>>> On Sat, Jul 6, 2013 at 5:36 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: >>>> >>>>> >>>>> On Jul 6, 2013, at 7:15 PM, Facundo Vozzi <facundov79(a)gmail.com> >>>>> wrote: >>>>> >>>>> Hi, >>>>> I migrated my small app from Pharo 1.3 to Pharo 2.0. I'm using DBXTalk >>>>> and GlorpDBX. >>>>> >>>>> It's working perfectly on my notebook (Windows 7 64 bits and >>>>> postgreSql 9.1) but on my server (Windows 2003 32 bits server and >>>>> postgreSql 9.0) I'm getting this error at OpenDBXWin32 level with 3 >>>>> simultaneus connections:* 'FATAL: lo siento, ya tenemos demasiados >>>>> clientes'*. >>>>> >>>>> It's strange (for me) because the version on Pharo 1.3 works properly >>>>> in both machines but the version on Pharo 2.0 works perfect on my notebook >>>>> and works properly for the first two connections on the server. >>>>> >>>>> I think that could be a problem with the OpenDBX library with the >>>>> server and the implementation of FFI on Pharo 2.0 but I can't figure out it. >>>>> >>>>> Any suggestions? >>>>> >>>>> Thanks in advance, >>>>> Facundo >>>>> >>>>> p.s.: where is hosted the DBXTalk project now? I can't find it on >>>>> http://dbxtalk.smallworks.com.ar/ anymore >>>>> >>>>> >>>>> sorry, I'm changing servers and the DNS is not well refreshed yet... >>>>> however, you can find it here: >>>>> >>>>> http://dbxtalk.smallworks.eu >>>>> >>>>> >>>>> <Error on the third connection attempt.txt> >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

July 15, 2013

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

by Mariano Martinez Peck

Ahh another question, sorry. With this cipher a "salt" would make almost no sense since I already need a key? or it make sense to put a "salt" together with the string to ecnrypt? Thanks On Mon, Jul 15, 2013 at 5:39 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > >> Blowfish is a 8 byte block cipher so for shorter strings I'll need to pad >> the byte array, and for longer strings I'll need to make it use cipher >> block >> chaining: >> ( >> https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher-block_… >> ) >> >> > Ok, I imagined something like that. Thanks for the explanation. > For my usecase, I think this is not the more critical thing since I would > use a 8 character password for sure :) > > >> >> >> If you change #decryptString:with: to: >> >> Blowfish class>>decryptString: aString with: aKey >> |decryptedData | >> decryptedData := (self new ecbDecrypt: aString asByteArray with: aKey >> asByteArray ). >> ^String fromByteArray: decryptedData asByteArray . >> >> Then this workspace code should work: >> >> | enc encryptedString dkey decrString | >> key:='mySecretKey'. >> enc:=Blowfish encryptString:'12345678' with: key. >> encryptedString := enc asByteArray asString. >> Transcript show: ' encrypted: ', encryptedString; cr. >> decrString:=Blowfish decryptString: encryptedString with: key. >> Transcript show: ' decrypted: ', decrString; cr. >> >> >> > Thanks!! That worked. Now...there is no problem with the encoding then? > Because I would need to store/retrieve the string from a file stream...so > I didn't know if I should use a TextConverter or not. > > Thanks in advance, > > > >> But with the password 'test' it will always fail because I'm not yet >> padding >> the byte array to a multiple of 8 bytes before encrypting it. >> >> >> >> Thanks for your patience >> >> >> Paul >> >> >> >> -- >> 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 > -- Mariano http://marianopeck.wordpress.com

July 15, 2013

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

by Mariano Martinez Peck

> Blowfish is a 8 byte block cipher so for shorter strings I'll need to pad > the byte array, and for longer strings I'll need to make it use cipher > block > chaining: > ( > https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher-block_… > ) > > Ok, I imagined something like that. Thanks for the explanation. For my usecase, I think this is not the more critical thing since I would use a 8 character password for sure :) > > > If you change #decryptString:with: to: > > Blowfish class>>decryptString: aString with: aKey > |decryptedData | > decryptedData := (self new ecbDecrypt: aString asByteArray with: aKey > asByteArray ). > ^String fromByteArray: decryptedData asByteArray . > > Then this workspace code should work: > > | enc encryptedString dkey decrString | > key:='mySecretKey'. > enc:=Blowfish encryptString:'12345678' with: key. > encryptedString := enc asByteArray asString. > Transcript show: ' encrypted: ', encryptedString; cr. > decrString:=Blowfish decryptString: encryptedString with: key. > Transcript show: ' decrypted: ', decrString; cr. > > > Thanks!! That worked. Now...there is no problem with the encoding then? Because I would need to store/retrieve the string from a file stream...so I didn't know if I should use a TextConverter or not. Thanks in advance, > But with the password 'test' it will always fail because I'm not yet > padding > the byte array to a multiple of 8 bytes before encrypting it. > > > > Thanks for your patience > > > Paul > > > > -- > 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] Job: from Exceptions to Announcements?

by Camillo Bruni

Hi, this actually emerged from a discussion with Sean, because he didn't like exceptions based notifications :). But all in all there is no big change needed. I think the UI will work anyway passively, there should be a refresh loop that checks 15-times per second the status of the active jobs and updates the UI progress bar accordingly. So I think there shouldn't be many more changes? Maybe we can quickly have a look at it together... On 2013-07-15, at 19:00, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi, > > I am looking into SystemProgressMorph and I found this flag in several methods: > > self flag: 'When we go from Exceptions to announcements, delete this > and use show:from:to:during:'. > > I'd like to know more. I see that Jobs are implemented with both > exceptions and announcements... what is the idea? to remove the > exceptions and use only announcements? > > Thank you for your help, > MartÃn >

July 15, 2013

[DOC] Building and deploying

by Paul Davidowitz

Very nice, but perhaps in a future tutorial the mode of presentation can be TDD...

July 15, 2013