August 2019 - Pharo-users - lists.pharo.org

Re: [Pharo-users] SHA512 HMAC support in Pharo

by Ben Coman

On Wed, 14 Aug 2019 at 20:25, Jonathan van Alteren < jvalteren(a)objectguild.com> wrote: > Hi all, > > For a client project we need support for SHA512 and SHA384 hashing and > digital signatures with HMAC). Can anyone tell me if there is work (being) > done on SHA512? We're on Pharo 7.0.3. > > At first, it didn't look too hard to refactor the SHA256 class in the > System-Hashing package. That is... until I saw the use of > ThirtyTwoBitRegister and the SHA256NonPrimitive and SHA256WithPrimitive > classes in the Cryptography-SHA256 package. > > It seems to me that SHA512 will need a SixtyFourBitRegister class. > > Also, when I try to generate the constants on the fly with 64 bit values, > the last 3 hexadecimal digits are zero (0). To me, this suggests that > Pharo/Smalltalk might have issues working with 64 bit (float?) values. > > "(Integer primesUpTo: 312) collect: [:x | (((x raisedTo: 1/3) > fractionPart) * (2.0 raisedTo: 64)) truncated hex]" > > You can use LibSodium via FFI to do SHA512-HMAC... https://github.com/Traadh/bittrex/blob/master/src/Bittrex.package/BittrexLi… Example... https://github.com/Traadh/bittrex/blob/master/src/Bittrex.package/BittrexLi… https://github.com/Traadh/bittrex And you may find some other options here... http://forum.world.st/HMAC-SHA512-td5060307.html cheers -ben

Aug. 14, 2019

github.com/pharo-vcs/libgit2-pharo-bindings

by James Foster

This package defines LGitCallback and provides an implementation of #âinitializeNullâ. It also provides an extension that has an implementation of #âbeNullâ. Where is the variable âthunkâ defined? Why is this in an extension? https://github.com/pharo-vcs/libgit2-pharo-bindings/blob/master/LibGit-Core… instance initialization initializeNull self beNull https://github.com/pharo-vcs/libgit2-pharo-bindings/blob/master/LibGit-Comp… *LibGit-Compatibility-Pharo7 beNull thunk := ExternalAddress null

Aug. 14, 2019

SHA512 HMAC support in Pharo

by Jonathan van Alteren

Hi all, For a client project we need support for SHA512 and SHA384 hashing and digital signatures with HMAC). Can anyone tell me if there is work (being) done on SHA512? We're on Pharo 7.0.3. At first, it didn't look too hard to refactor the SHA256 class in the System-Hashing package. That is... until I saw the use of ThirtyTwoBitRegister and the SHA256NonPrimitive and SHA256WithPrimitive classes in the Cryptography-SHA256 package. It seems to me that SHA512 will need a SixtyFourBitRegister class. Also, when I try to generate the constants on the fly with 64 bit values, the last 3 hexadecimal digits are zero (0). To me, this suggests that Pharo/Smalltalk might have issues working with 64 bit (float?) values. "(Integer primesUpTo: 312) collect: [:x | (((x raisedTo: 1/3) fractionPart) * (2.0 raisedTo: 64)) truncated hex]" Kind regards, Jonathan van Alteren Founding Member jvalteren(a)objectguild.com +31622500930

Aug. 14, 2019

Re: [Pharo-users] [ANN] Pharo Pomodoro now on GitHub

by Steve Quezadas

Wonderful, thank you. I am starting to write my own tools in pharo because it's soooo much easier. I'm glad to be rid of html On Tue, Aug 13, 2019 at 1:26 PM Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > Le 13/08/2019 Ã 22:23, Steve Quezadas a Ã©crit : > > How did you put that in the menubar? > > > > > > Hi, > > We have a documentation about this in pharo-wiki: > > https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/… > > -- > Cyril Ferlicot > https://ferlicot.fr > >

Aug. 13, 2019

Re: [Pharo-users] [ANN] Pharo Pomodoro now on GitHub

by Cyril Ferlicot D.

Le 13/08/2019 Ã 22:23, Steve Quezadas a Ã©critÂ : > How did you put that in the menubar? > > Hi, We have a documentation about this in pharo-wiki: https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/… -- Cyril Ferlicot https://ferlicot.fr

Aug. 13, 2019

Re: [Pharo-users] [ANN] Pharo Pomodoro now on GitHub

by Steve Quezadas

How did you put that in the menubar? On Tue, Aug 13, 2019 at 4:26 AM Torsten Bergmann <astares(a)gmx.de> wrote: > Guillermo wrote > > Is it pure morphic or youâve updated it to spec? > > still Morphic based - have not done much in Spec yet. There is a Pharo8.0 > branch > you can send PR to ;) > > Bye > T. > >

Aug. 13, 2019

Re: [Pharo-users] [Pharo-dev] Information on Spec development

by Cyril Ferlicot

On Tue, Aug 13, 2019 at 3:25 PM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > No, you are not :) > #asSpAdapter will be removed. > > You are looking for SpMorphPresenter (and/or the method SpPresenter>>newMorph) > In the Spec repository I deprecated #asSpAdapter with a mesage explaining SpMorphPresenter should be used. It will be integrated in next Spec integration. > Esteban > > -- Cyril Ferlicot https://ferlicot.fr

Aug. 13, 2019

Re: [Pharo-users] [Pharo-dev] Information on Spec development

by Esteban Lorenzano

> On 13 Aug 2019, at 15:19, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > On Tue, Aug 13, 2019 at 2:59 PM Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >> Ah yes, I just wrote on discord. I did a tool in spec2 which I cannot use in the newest pharo. The #asSpecAdapter uses still MorphicGenericAdapter instead of SpMorphicGenericAdapter. Iceberg needs the former, my tool the latter. What is the strategy for that. For now I did a #asSpec2Adapter in my image that return the SpMorphic.. class. >> > Hi, > > The extensions in Spec2 are renamed to not conflict with Spec 1. You > are looking for #asSpAdapter ;) No, you are not :) #asSpAdapter will be removed. You are looking for SpMorphPresenter (and/or the method SpPresenter>>newMorph) Esteban > >> Norbert >> >> > > > -- > Cyril Ferlicot > https://ferlicot.fr >

Aug. 13, 2019

Re: [Pharo-users] [Pharo-dev] Information on Spec development

by Cyril Ferlicot

On Tue, Aug 13, 2019 at 2:59 PM Norbert Hartl <norbert(a)hartl.name> wrote: > > > Ah yes, I just wrote on discord. I did a tool in spec2 which I cannot use in the newest pharo. The #asSpecAdapter uses still MorphicGenericAdapter instead of SpMorphicGenericAdapter. Iceberg needs the former, my tool the latter. What is the strategy for that. For now I did a #asSpec2Adapter in my image that return the SpMorphic.. class. > Hi, The extensions in Spec2 are renamed to not conflict with Spec 1. You are looking for #asSpAdapter ;) > Norbert > > -- Cyril Ferlicot https://ferlicot.fr

Aug. 13, 2019

Re: [Pharo-users] [Pharo-dev] Information on Spec development

by Torsten Bergmann

Cyril wrote > Until now, the T is before the prefix. (For example TIceXXX for > Iceberg). So I followed what was already done. But then IMHO Iceberg is wrong too and do not correctly and consistently use their own prefix in front of classes/traits. See other samples like traits in which are also there already: Epicea -> EpTEventVisitor Fuel -> FLTGlobalClassOrTraitSerializationTest Glamour -> GLMTBlockTags Moose Algos -> MalTEdgeNode ... and where "prefix" is first as it should be. There are several reasons why "prefix" should be first: 1. As the name says: it is a prefix - so it would be obvious to have it in front of the class or trait name. 2. Prefixes are a workaround because we do not have namespaces (yet). Following the "prefix" always first rule we could later have a separation into namespaces more easily later when migrating. 3. If someone uses a prefix starting with a "T" too, like "TPL" for Template library then people get easily confused with class/trait mix of "TTPL" and "TPLT" looking like a typo or thinking all are traits because "T" is the first. Therefore - Prefix should be two (as in Seaside), ideally three letters and ideally in uppercase IMHO we should define a rule to have three uppercase letters at least for the base image. - order should be "prefix" and then class or trait name (where trait names start with "T". Smalltalk provides lots of freedom. But without rules and discipline it easily ends up in inconsistencies, chaos, a mess... Looks like even Pharo engineers miss a code guide these days ... Bye T.

Aug. 13, 2019