December 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] potential to include cryptography in base image

by Robert Withers

Thank you, Sven, giving me the opportunity to scope the right mailing lists into the discussion. I love that Pharo is oriented towards business. My particular excitement is to see all the scientific computing. These recent threads on expanding capacity and targeting marketing are good. I think Cryptography in the base, including SecureSession, adds to that effort. The Cryptography package, both for squeak and the Cryptography-Pharo package, and in the Cryptography repository (http://www.squeaksource.com/Cryptography. Through the Monticello Browser this is a loadable item. The loading of SecureSession, which is loadable by both squeak and pharo, ois a separate load. I appreciate that pharo has established a different mechanism for loading. At this time, I am deep into fixing ReedSolomon FEC code, so I must be conservative (which I am) and defer learning and including Cryptography in that mechanism. I must be careful what promises I make and I cannot make a commitment here. If you are interested in seeing this in pharo's catalog, then the Cryptography team welcomes new members, especially from new environments. Welcome. We appreciate all the work that you do! Again, I appreciate the opportunity to engage the community in discussion around the definition and example of a minimal modular image that includes Cryptography & SecureSession in the base. NB: I think that business computing and scientific computing does not equal mobile devices, necessarily. I have long made the case, with varying degrees of effectiveness, that squeak belongs on the server. A SecureSession & Cryptography capability in the base, minimal, headless image is desired: the first question in the OP. Therefore, the correct target of growth is not mobile, it is BigData! On 12/15/2015 05:20 AM, Sven Van Caekenberghe wrote: > Robert, > > I think that the Pharo community, part of which is more business oriented, is absolutely interested in more and better Crypto code. In any case, I am. > > What we absolutely want, if it is not already the case (I did not check), is that the Crypto code can be loaded using 1 single action (through our validated Monticello configurations and Catalog mechanism) - I am sure you will find help to achieve and maintain (through a CI process) that goal. > > Whether it should be a base part of the image is another question. Modularity is a huge goal for Pharo. This is a much harder discussion (as the same can be said of or asked for for many packages that are generally useful: XML, CSV, JSON, SQL, ...). In any the case, the first step is the one described in the previous paragraph. Then you need traction, usage, and maybe demand for full inclusion. > > Regards, > > Sven > >> On 15 Dec 2015, at 11:00, Robert Withers <robert.w.withers(a)gmail.com> wrote: >> >> It was suggested to me that I write to the list and raise the question about cryptography being included in the base image. Really I have 3 questions I would ask you all: >> >> â¢ is it desirable to include cryptography? >> â¢ is it feasible to include cryptography? >> â¢ what is the time frame for including cryptography? >> Given the thread on password hashing (and salting and so on), there are good, solid implementations in the cryptography package. Looking in the Cryptography repository, there is a Pharo 5.0 compatible Cryptography package. >> >> In light of another recent thread discussing random number generation, discussion about the best approach to random algorithms in cryptography ought be engaged. For instance, the SecureRandom algorithm evidently provides some level of guarantee. >> >> To underline the solidity I am attaching a profile of all 102 cryptography tests passing green. This profile demonstrates that there are no areas of particular inefficiency - nothing stands out to be improved - means that the entire library is maximally efficient. >> >> And so I please ask that we have these discussions, for there is a lot of value in this package for general and basic use. >> >> >> -- >> . .. ... ^,^ best, robert >> <Cryptography Spy Results.text.gz> -- . .. .. ^,^ best, robert

Dec. 15, 2015

Re: [Pharo-dev] potential to include cryptography in base image

by Sven Van Caekenberghe

Robert, I think that the Pharo community, part of which is more business oriented, is absolutely interested in more and better Crypto code. In any case, I am. What we absolutely want, if it is not already the case (I did not check), is that the Crypto code can be loaded using 1 single action (through our validated Monticello configurations and Catalog mechanism) - I am sure you will find help to achieve and maintain (through a CI process) that goal. Whether it should be a base part of the image is another question. Modularity is a huge goal for Pharo. This is a much harder discussion (as the same can be said of or asked for for many packages that are generally useful: XML, CSV, JSON, SQL, ...). In any the case, the first step is the one described in the previous paragraph. Then you need traction, usage, and maybe demand for full inclusion. Regards, Sven > On 15 Dec 2015, at 11:00, Robert Withers <robert.w.withers(a)gmail.com> wrote: > > It was suggested to me that I write to the list and raise the question about cryptography being included in the base image. Really I have 3 questions I would ask you all: > > â¢ is it desirable to include cryptography? > â¢ is it feasible to include cryptography? > â¢ what is the time frame for including cryptography? > Given the thread on password hashing (and salting and so on), there are good, solid implementations in the cryptography package. Looking in the Cryptography repository, there is a Pharo 5.0 compatible Cryptography package. > > In light of another recent thread discussing random number generation, discussion about the best approach to random algorithms in cryptography ought be engaged. For instance, the SecureRandom algorithm evidently provides some level of guarantee. > > To underline the solidity I am attaching a profile of all 102 cryptography tests passing green. This profile demonstrates that there are no areas of particular inefficiency - nothing stands out to be improved - means that the entire library is maximally efficient. > > And so I please ask that we have these discussions, for there is a lot of value in this package for general and basic use. > > > -- > . .. ... ^,^ best, robert > <Cryptography Spy Results.text.gz>

Dec. 15, 2015

Re: [Pharo-dev] New web tutorial

by Sven Van Caekenberghe

> On 15 Dec 2015, at 10:34, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 15-12-15 10:23, Sven Van Caekenberghe wrote: >>> passwordHash >>> passwordHash ifNil: [ ^'' ]. >>> ^ passwordHash >> >> That last method is not needed, since 'any string' = nil is false, right ? > > Yep. Nu we toch Nederlands mogen praten, het lijkt me best om voorbeeld code zo minimaal mogelijk te houden. De paswoord hashing is wel een goed idee. ;-)

Dec. 15, 2015

Re: [Pharo-dev] New web tutorial

by Stephan Eggermont

On 15-12-15 10:23, Sven Van Caekenberghe wrote: >> passwordHash >> passwordHash ifNil: [ ^'' ]. >> ^ passwordHash > > That last method is not needed, since 'any string' = nil is false, right ? Yep. Stephan

Dec. 15, 2015

Re: [Pharo-dev] New web tutorial

by Sven Van Caekenberghe

> On 15 Dec 2015, at 10:19, Stephan Eggermont <stephan(a)stack.nl> wrote: > > Instead of the really unsafe password: thing, perhaps use > > hashPassword: aString > ^GRPlatform current secureHashFor: aString > > password: anObject > passwordHash := self hashPassword: anObject > > verifyPassword: aString > ^(self hashPassword: aString) = self passwordHash. > > passwordHash > passwordHash ifNil: [ ^'' ]. > ^ passwordHash That last method is not needed, since 'any string' = nil is false, right ?

Dec. 15, 2015

Re: [Pharo-dev] New web tutorial

by Stephan Eggermont

Instead of the really unsafe password: thing, perhaps use hashPassword: aString ^GRPlatform current secureHashFor: aString password: anObject passwordHash := self hashPassword: anObject verifyPassword: aString ^(self hashPassword: aString) = self passwordHash. passwordHash passwordHash ifNil: [ ^'' ]. ^ passwordHash

Dec. 15, 2015

Re: [Pharo-dev] [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: [squeak-dev] Unicode Support))

by Ben Coman

On Thu, Dec 10, 2015 at 12:37 AM, Todd Blanchard <tblanchard(a)mac.com> wrote: > They are practically the same thing. > > ICU was developed by Taligent which was a joint venture between Apple and IBM. Makes sense that NSString and ICU's UnicodeString are pretty close in implementation. ICU was also ported to Java for Sun by IBM. The point is - this is a very elaborate chunk of code with far reach. If ICU is wrong on some point - it is universally wrong and thus likely to be taken as "right" as it is at least consistent. I think re-implementing it is folly TBH. Just use it. Apple seem to have moved on from NSString to support Unicode in a different way in Switft... > >> On Dec 8, 2015, at 15:52, EuanM <euanmee(a)gmail.com> wrote: >> >> Equally old are the NextStep Object C functions which are now embodied >> within MacOS X. >> > >

Dec. 15, 2015

Re: [Pharo-dev] [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: [squeak-dev] Unicode Support))

by Eliot Miranda

> On Dec 14, 2015, at 7:23 AM, Richard Sargent <richard.sargent(a)gemtalksystems.com> wrote: > > EuanM wrote >> Hi Todd, it's taken me til now to put my thoughts into words on this >> issue. >> >> I think we should make it work first. This will allow us to gain more >> insight into the issues, and create documentation about the process >> that we, as a community, understand. >> >> If ICU is the right way to go, we can *then* "make it right". > > One way to cross the Grand Canyon is to climb down the wall, assemble the > materials to build a bridge, build the bridge, cross it, then clamber up the > wall. One would learn a lot about climbing and bridge building, worthwhile > if the goal is to learn about those subjects. > > Alternatively, you could use the highway bridge that was built long ago and > just cross to the other side. This is definitely my inclination. and given that translating c++ to Smalltalk is doable since Smalltalk is a more powerful language, whereas going the other way is decidedly non-trivial, the right way to use the highway bridge is to point moose at it, extract the plans for the bridge, and reconstruct it out of quality materials. > > >> On 8 December 2015 at 22:36, Todd Blanchard < > >> tblanchard@ > >> > wrote: >>> I just want to second Dale's endorsement of the ICU library. It has been >>> around a long time (originally developed by Taligent) and it provides the >>> base unicode capabilities for an awful lot of software. >>> >>> I think it would make more sense to bring icu into Smalltalk as a >>> NativeBoost library than to spend resources reimplementing and >>> maintaining >>> it. >>> >>> -Todd Blanchard >>> >>> On Dec 8, 2015, at 11:20, Dale Henrichs < > >> dale.henrichs@ > >> > >>> wrote: >>> >>> On 12/07/2015 11:31 PM, H. Hirzel wrote: >>> >>> Dale >>> >>> Thank you for your answer with links to the ICU library and the notes >>> about classes in Gemstone. Noteworthy that you have a class Utf8 as a >>> subclass of ByteArray. >>> >>> I understand that Gemstone uses the ICU library and thus does not >>> implement the algorithms in Smalltalk. >>> >>> I am currently looking into what the ICU library provides. > > > > > > -- > View this message in context: http://forum.world.st/Sorting-Unicode-strings-Re-Unicode-collation-sequence… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Dec. 15, 2015

Re: [Pharo-dev] [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: [squeak-dev] Unicode Support))

by Eliot Miranda

Hi All, > On Dec 14, 2015, at 7:23 AM, Richard Sargent <richard.sargent(a)gemtalksystems.com> wrote: > > EuanM wrote >> Hi Todd, it's taken me til now to put my thoughts into words on this >> issue. >> >> I think we should make it work first. This will allow us to gain more >> insight into the issues, and create documentation about the process >> that we, as a community, understand. >> >> If ICU is the right way to go, we can *then* "make it right". > > One way to cross the Grand Canyon is to climb down the wall, assemble the > materials to build a bridge, build the bridge, cross it, then clamber up the > wall. One would learn a lot about climbing and bridge building, worthwhile > if the goal is to learn about those subjects. > > Alternatively, you could use the highway bridge that was built long ago and > just cross to the other side. This is definitely my inclination. > Using ICU is a disaster at least for the VM. It means we cannot simulate an important part of the system without being able to call ICU from within the simulator. It means bugs in Unicode can potentially cause hard crashes in c++ code, destroying the perfectly safe VM simulation environment /and/ the perfectly safe Smalltalk string library. Goodbye debugger hello gdb. It means having a dependency on a large c++ library for a core part of the system, with all that entails about more complex builds, portability, etc. It means opacity in a core part of the system. This move will be a terrible mistake. >> On 8 December 2015 at 22:36, Todd Blanchard < > >> tblanchard@ > >> > wrote: >>> I just want to second Dale's endorsement of the ICU library. It has been >>> around a long time (originally developed by Taligent) and it provides the >>> base unicode capabilities for an awful lot of software. >>> >>> I think it would make more sense to bring icu into Smalltalk as a >>> NativeBoost library than to spend resources reimplementing and >>> maintaining >>> it. >>> >>> -Todd Blanchard >>> >>> On Dec 8, 2015, at 11:20, Dale Henrichs < > >> dale.henrichs@ > >> > >>> wrote: >>> >>> On 12/07/2015 11:31 PM, H. Hirzel wrote: >>> >>> Dale >>> >>> Thank you for your answer with links to the ICU library and the notes >>> about classes in Gemstone. Noteworthy that you have a class Utf8 as a >>> subclass of ByteArray. >>> >>> I understand that Gemstone uses the ICU library and thus does not >>> implement the algorithms in Smalltalk. >>> >>> I am currently looking into what the ICU library provides. > > > > > > -- > View this message in context: http://forum.world.st/Sorting-Unicode-strings-Re-Unicode-collation-sequence… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Dec. 15, 2015

Re: [Pharo-dev] Windows compilation performance issues

by Marcus Denker

We really should think about getting rid of the .changes and .sources file mechanism... (ceterum censeoâ¦ ;-) > On 14 Dec 2015, at 19:29, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > Check this long thread: [Pharo-users] Slow compilation on one of my Windows PCs > > As I said it there, besides the final conclusions, I have found many times that it could be a problem of an anti-virus program scanning the .changes file which is changing all the time while loading and so the performance slowdown. > > > On Mon, Dec 14, 2015 at 3:24 PM, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > Hi all, > > I just did a teaching lab session today in Brest, and I noticed that Pharo on Microsoft Windows compiles very slowly (loading Roassal2 stable on Pharo4). > > What Windows tools shows is a very low cpu load, and a high disk load with very low bandwidth (0.1Mbit/s instead of 16Mbit/s). > > Does anybody knows why? > > Thierry > > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Dec. 15, 2015