December 2017 - Pharo-users

Re: [Pharo-users] Pharo 6.1 / 7, 0 Glorp smalltalkhub to github migration

by Alistair Grant

On 11 December 2017 at 14:13, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > hi, > > this migration was already made to: > > https://github.com/pharo-rdbms > > donât you prefer to join that team and contribute to enhance there? Aaarrrgghh!!! I didn't know this existed! I had a look through my email archive and couldn't find any reference to it (pharo-user, pharo-dev and glorp-group). Was it announced somewhere? 1. pharo-rdbms loses all the commit history of Glorp, while my version keeps it all. Would you prefer to keep the history, or don't think it matters? If you want to keep the history I'm happy to put in the effort to move it across to pharo-rdbms. 2. I have write permissions for smalltalkhub/DBXtalk. Is it possible to get commit permission to pharo-rdbms? 3. Is there a reason why ConfigurationOfGlorp on smalltalkhub hasn't been updated to use pharo-rdbms (or raise an error pointing to pharo-rdbms)? Thanks! Alistair

Dec. 11, 2017

Re: [Pharo-users] P3 timeout

by Pierce Ng

On Tue, Dec 05, 2017 at 07:54:00AM +0100, Stephane Ducasse wrote: > If you need help for your booklet setup let me know. Thanks. I'm already set up with Pillar and all that. I'm working on extending Sven's Reddit.st. Next step is to make it run over TLS, which is why I'm writing a Let's Encrypt client, which is why I'm writing the OpenSSL wrapper. Pierce

Dec. 11, 2017

Re: [Pharo-users] HMAC-SHA512

by HernÃ¡n Morales Durand

2017-12-11 10:13 GMT-03:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > 2017-12-11 5:28 GMT-03:00 Ben Coman <btc(a)openinworld.com>: >> >> >> On 11 December 2017 at 13:09, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> 2017-12-10 6:01 GMT-03:00 Ben Coman <btc(a)openinworld.com>: >>> > Can anyone recommend libraries (native Smalltalk or via FFI) >>> > to do generate a HMAC-SHA512 ? >>> >>> On 11 December 2017 at 01:30, HernÃ¡n Morales Durand >>> <hernan.morales(a)gmail.com> wrote: >>>> >>>> Hi Ben, >>>> >>>> I would use NaCl: http://cr.yp.to/highspeed/coolnacl-20120725.pdf >>>> which you can install from the Pharo Project Catalog in Pharo 6.x >>> >>> >>> Thanks Henry. That looks like path of least resistance. >> >> >> Whoops, I meant thanks HernÃ¡n. >> >> >> >>> >>> I hit a stumbling block that took a short while to understand. >>> The library binary downloaded specified by >>> ConfigruationOfNacl>>platformLibraryUrl >>> is libsodium: ELF 32-bit LSB shared object >>> whereas I'm using 64bit Linux. >> >> >> btw, I discovered just now that FFILibrary>>unix64ModuleName >> was introduced this year. So presumably with the following >> you could include both bit'ness libraries in the libsodium.so.gz >> file specified in ConfigurationOfNacl >> platformLibraryUrl. >> >> FFILbrary subclass: #Nacl >> instanceVariableNames: '' >> classVariableNames: '' >> package: 'Crypto-Nacl' >> >> Nacl >> unixModuleName >> ^ 'libsodium.so' >> >> Nacl >> unix64ModuleName >> ^ 'libsodium64.so' >> >> Nacl class >> apiXXX >> ^ self ffiCall: #(void XXX()) >> module: Nacl >> >> > > Done. Thank you Ben. > > All tests passes in Windows, so I uploaded a new Configuration with > updated dev version. > Let me know any issues. > BTW you can install the dev version using: Metacello new smalltalkhubUser: 'tonyg' project: 'Crypto-Nacl'; configuration: 'Nacl'; version: #development; load. >> >> >>> >>> >>> I have the following system library preinstalled... >>> /usr/lib/x86_64-linux-gnu/libsodium.so.18.0.1: ELF 64-bit LSB shared >>> object >>> >>> However its api is slightly different. Pharo Nacl makes this call out... >>> crypto_hash_sha512_ref() >>> >>> but the system library provides... >>> 56: 0000000000014dc0 175 FUNC GLOBAL DEFAULT 11 >>> crypto_hash_sha512_final >>> 81: 0000000000014c40 384 FUNC GLOBAL DEFAULT 11 >>> crypto_hash_sha512_update >>> 154: 0000000000014bd0 106 FUNC GLOBAL DEFAULT 11 >>> crypto_hash_sha512_init >>> 233: 0000000000014e70 114 FUNC GLOBAL DEFAULT 11 >>> crypto_hash_sha512 >>> 342: 0000000000012330 6 FUNC GLOBAL DEFAULT 11 >>> crypto_hash_sha512_bytes >>> 351: 0000000000012340 6 FUNC GLOBAL DEFAULT 11 >>> crypto_hash_sha512_statebytes >>> >>> The canonical source doesn't seem to have the function >>> >>> https://github.com/jedisct1/libsodium/search?utf8=%E2%9C%93&q=+crypto_hash_… >>> so I'm curious where the "_ref" comes from. >>> >>> My options seem... >>> * Compile a 64-bit libsodium from source which includes "_ref" functions. >>> Where is such source? >>> > > The official sources seem to be here: > https://download.libsodium.org/libsodium/releases/ > I discovered that the version we use in the Pharo binding is old, so I > will update to the latest version as next step. > >>> * Use the system libsodium and define an FFI callout just for the one >>> function I need. >> >> >> btw, I'm doing the latter for now as the immediate path of least resistance. >> Thanks Hernan, for the tip on libsodium. >> >> cheers -ben > > Cheers > > HernÃ¡n

Dec. 11, 2017

Re: [Pharo-users] Pharo 6.1 / 7, 0 Glorp smalltalkhub to github migration

by Esteban Lorenzano

hi, this migration was already made to: https://github.com/pharo-rdbms <https://github.com/pharo-rdbms> donât you prefer to join that team and contribute to enhance there? cheers! Esteban > On 11 Dec 2017, at 13:52, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Everyone, > > I've migrated Glorp v130, including GlorpSQLite, from smalltalkhub to > github using Peter Uhnak's excellent git-migration tool, see: > https://github.com/akgrant43/Glorp > > To load Glorp: > > Metacello new > repository: 'github://akgrant43/Glorp/src'; > baseline: 'Glorp'; > load. > > > To load Glorp with the UDBC SQLite drivers: > > Metacello new > repository: 'github://akgrant43/Glorp/src'; > baseline: 'GlorpSQLite'; > load. > > > I'm not familiar with the other drivers, so I'm happy to help, but would > like some assistance before migrating the other drivers. > > If I don't hear any complaints in the next week I'll eventually get > around to modifying the ConfigurationOfGlorp on smalltalkhub to use the > github version for Pharo 6.1 and 7.0. Older versions of Pharo will > continue to load Glorp from smalltalkhub. > > If there's an official account that should own this project, I'm more > than happy to hand it over. > > Cheers, > Alistair >

Dec. 11, 2017

Re: [Pharo-users] HMAC-SHA512

by HernÃ¡n Morales Durand

2017-12-11 5:28 GMT-03:00 Ben Coman <btc(a)openinworld.com>: > > > On 11 December 2017 at 13:09, Ben Coman <btc(a)openinworld.com> wrote: >> >> 2017-12-10 6:01 GMT-03:00 Ben Coman <btc(a)openinworld.com>: >> > Can anyone recommend libraries (native Smalltalk or via FFI) >> > to do generate a HMAC-SHA512 ? >> >> On 11 December 2017 at 01:30, HernÃ¡n Morales Durand >> <hernan.morales(a)gmail.com> wrote: >>> >>> Hi Ben, >>> >>> I would use NaCl: http://cr.yp.to/highspeed/coolnacl-20120725.pdf >>> which you can install from the Pharo Project Catalog in Pharo 6.x >> >> >> Thanks Henry. That looks like path of least resistance. > > > Whoops, I meant thanks HernÃ¡n. > > > >> >> I hit a stumbling block that took a short while to understand. >> The library binary downloaded specified by >> ConfigruationOfNacl>>platformLibraryUrl >> is libsodium: ELF 32-bit LSB shared object >> whereas I'm using 64bit Linux. > > > btw, I discovered just now that FFILibrary>>unix64ModuleName > was introduced this year. So presumably with the following > you could include both bit'ness libraries in the libsodium.so.gz > file specified in ConfigurationOfNacl >> platformLibraryUrl. > > FFILbrary subclass: #Nacl > instanceVariableNames: '' > classVariableNames: '' > package: 'Crypto-Nacl' > > Nacl >> unixModuleName > ^ 'libsodium.so' > > Nacl >> unix64ModuleName > ^ 'libsodium64.so' > > Nacl class >> apiXXX > ^ self ffiCall: #(void XXX()) > module: Nacl > > Done. Thank you Ben. All tests passes in Windows, so I uploaded a new Configuration with updated dev version. Let me know any issues. > > >> >> >> I have the following system library preinstalled... >> /usr/lib/x86_64-linux-gnu/libsodium.so.18.0.1: ELF 64-bit LSB shared >> object >> >> However its api is slightly different. Pharo Nacl makes this call out... >> crypto_hash_sha512_ref() >> >> but the system library provides... >> 56: 0000000000014dc0 175 FUNC GLOBAL DEFAULT 11 >> crypto_hash_sha512_final >> 81: 0000000000014c40 384 FUNC GLOBAL DEFAULT 11 >> crypto_hash_sha512_update >> 154: 0000000000014bd0 106 FUNC GLOBAL DEFAULT 11 >> crypto_hash_sha512_init >> 233: 0000000000014e70 114 FUNC GLOBAL DEFAULT 11 >> crypto_hash_sha512 >> 342: 0000000000012330 6 FUNC GLOBAL DEFAULT 11 >> crypto_hash_sha512_bytes >> 351: 0000000000012340 6 FUNC GLOBAL DEFAULT 11 >> crypto_hash_sha512_statebytes >> >> The canonical source doesn't seem to have the function >> >> https://github.com/jedisct1/libsodium/search?utf8=%E2%9C%93&q=+crypto_hash_… >> so I'm curious where the "_ref" comes from. >> >> My options seem... >> * Compile a 64-bit libsodium from source which includes "_ref" functions. >> Where is such source? >> The official sources seem to be here: https://download.libsodium.org/libsodium/releases/ I discovered that the version we use in the Pharo binding is old, so I will update to the latest version as next step. >> * Use the system libsodium and define an FFI callout just for the one >> function I need. > > > btw, I'm doing the latter for now as the immediate path of least resistance. > Thanks Hernan, for the tip on libsodium. > > cheers -ben Cheers HernÃ¡n

Dec. 11, 2017

Pharo 6.1 / 7, 0 Glorp smalltalkhub to github migration

by Alistair Grant

Hi Everyone, I've migrated Glorp v130, including GlorpSQLite, from smalltalkhub to github using Peter Uhnak's excellent git-migration tool, see: https://github.com/akgrant43/Glorp To load Glorp: Metacello new repository: 'github://akgrant43/Glorp/src'; baseline: 'Glorp'; load. To load Glorp with the UDBC SQLite drivers: Metacello new repository: 'github://akgrant43/Glorp/src'; baseline: 'GlorpSQLite'; load. I'm not familiar with the other drivers, so I'm happy to help, but would like some assistance before migrating the other drivers. If I don't hear any complaints in the next week I'll eventually get around to modifying the ConfigurationOfGlorp on smalltalkhub to use the github version for Pharo 6.1 and 7.0. Older versions of Pharo will continue to load Glorp from smalltalkhub. If there's an official account that should own this project, I'm more than happy to hand it over. Cheers, Alistair

Dec. 11, 2017

Re: [Pharo-users] HMAC-SHA512

by Pierce Ng

On Mon, Dec 11, 2017 at 12:46:59AM +0800, Ben Coman wrote: > where the "EVP function provide a high level interface to OpenSSL > cryptographic functions." Hi Ben, As it happened, over the weekend I implemented the Pharo wrappers for the EVP_DigestSign* and EVP_DigestVerify* APIs. It is straightforward to add the non-public key-using message digest functions, so I've just done it. Code snippets: | msg st c | msg := 'Grumpy wizards make toxic brew for the evil Queen and Jack.'. st := SHA256 hashMessage: msg asByteArray. c := LcEvpSHA256 new hashMessage: msg asByteArray. st = c => true Using Sven's example: | msg st c | key := ByteArray new: 32. msg := 'Grumpy wizards make toxic brew for the evil Queen and Jack.'. st := (HMAC on: SHA256) key: key; digestMessage: msg asByteArray. c := (HMAC on: LcEvpSHA256) key: key; digestMessage: msg asByteArray. st = c => true Code at http://smalltalkhub.com/#!/~PierceNg/OpenSSL-Pharo. I've also added tests for SHA256 similar to the snippets above. I will add SHA512 tests when I find the test vectors. In the next two weeks when I have some time off from work, I will attempt to move the repo to GH. Meanwhile, I've added you as a contributor to the STH repo if you'd like to hack on it. Pierce

Dec. 11, 2017

Re: [Pharo-users] HMAC-SHA512

by Ben Coman

On 11 December 2017 at 13:09, Ben Coman <btc(a)openinworld.com> wrote: > 2017-12-10 6:01 GMT-03:00 Ben Coman <btc(a)openinworld.com>: > > Can anyone recommend libraries (native Smalltalk or via FFI) > > to do generate a HMAC-SHA512 ? > > On 11 December 2017 at 01:30, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> Hi Ben, >> >> I would use NaCl: http://cr.yp.to/highspeed/coolnacl-20120725.pdf >> which you can install from the Pharo Project Catalog in Pharo 6.x > > > Thanks Henry. That looks like path of least resistance. > Whoops, I meant thanks HernÃ¡n. > I hit a stumbling block that took a short while to understand. > The library binary downloaded specified by ConfigruationOfNacl>> > platformLibraryUrl > is libsodium: ELF 32-bit LSB shared object > whereas I'm using 64bit Linux. > btw, I discovered just now that FFILibrary>>unix64ModuleName was introduced this year. So presumably with the following you could include both bit'ness libraries in the libsodium.so.gz file specified in ConfigurationOfNacl >> platformLibraryUrl. FFILbrary subclass: #Nacl instanceVariableNames: '' classVariableNames: '' package: 'Crypto-Nacl' Nacl >> unixModuleName ^ 'libsodium.so' Nacl >> unix64ModuleName ^ 'libsodium64.so' Nacl class >> apiXXX ^ self ffiCall: #(void XXX()) module: Nacl > > I have the following system library preinstalled... > /usr/lib/x86_64-linux-gnu/libsodium.so.18.0.1: ELF 64-bit LSB shared > object > > However its api is slightly different. Pharo Nacl makes this call out... > crypto_hash_sha512_ref() > > but the system library provides... > 56: 0000000000014dc0 175 FUNC GLOBAL DEFAULT 11 > crypto_hash_sha512_final > 81: 0000000000014c40 384 FUNC GLOBAL DEFAULT 11 > crypto_hash_sha512_update > 154: 0000000000014bd0 106 FUNC GLOBAL DEFAULT 11 > crypto_hash_sha512_init > 233: 0000000000014e70 114 FUNC GLOBAL DEFAULT 11 > crypto_hash_sha512 > 342: 0000000000012330 6 FUNC GLOBAL DEFAULT 11 > crypto_hash_sha512_bytes > 351: 0000000000012340 6 FUNC GLOBAL DEFAULT 11 > crypto_hash_sha512_statebytes > > The canonical source doesn't seem to have the function > https://github.com/jedisct1/libsodium/search?utf8=%E2%9C% > 93&q=+crypto_hash_sha512_ref > so I'm curious where the "_ref" comes from. > > My options seem... > * Compile a 64-bit libsodium from source which includes "_ref" functions. > Where is such source? > * Use the system libsodium and define an FFI callout just for the one > function I need. > btw, I'm doing the latter for now as the immediate path of least resistance. Thanks Hernan, for the tip on libsodium. cheers -ben

Dec. 11, 2017

Re: [Pharo-users] Why do downloads not use HTTPS by default?

by Marcus Denker

The link there is now fixed. > On 11 Dec 2017, at 09:14, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > It is on my TODO to change all the linksâ¦ sorry for not having done that yet. > > Sadly the day has just 24 hours and the end of the year time is always quite stressful. > > Marcus > >> On 11 Dec 2017, at 00:48, Silent Walls <silentwalls123(a)gmail.com <mailto:silentwalls123@gmail.com>> wrote: >> >> Today I visited https://pharo.org/gnu-linux-installation-64 <https://pharo.org/gnu-linux-installation-64> to download the zip file containing the executable. To my surprise, the download is not carried out over HTTPS. The download link is http://files.pharo.org/platform/Pharo6.1-64-linux.zip <http://files.pharo.org/platform/Pharo6.1-64-linux.zip>. I ended up downloading the zip file using https://files.pharo.org/platform/Pharo6.1-64-linux.zip <https://files.pharo.org/platform/Pharo6.1-64-linux.zip>. >> >> The point is: if HTTPS downloads are supported, why is it not the default on the download pages of the Pharo website? >

Dec. 11, 2017

Re: [Pharo-users] Why do downloads not use HTTPS by default?

by Marcus Denker

It is on my TODO to change all the linksâ¦ sorry for not having done that yet. Sadly the day has just 24 hours and the end of the year time is always quite stressful. Marcus > On 11 Dec 2017, at 00:48, Silent Walls <silentwalls123(a)gmail.com> wrote: > > Today I visited https://pharo.org/gnu-linux-installation-64 <https://pharo.org/gnu-linux-installation-64> to download the zip file containing the executable. To my surprise, the download is not carried out over HTTPS. The download link is http://files.pharo.org/platform/Pharo6.1-64-linux.zip <http://files.pharo.org/platform/Pharo6.1-64-linux.zip>. I ended up downloading the zip file using https://files.pharo.org/platform/Pharo6.1-64-linux.zip <https://files.pharo.org/platform/Pharo6.1-64-linux.zip>. > > The point is: if HTTPS downloads are supported, why is it not the default on the download pages of the Pharo website?

Dec. 11, 2017