On Wed, Dec 16, 2015 at 1:36 AM, Robert Withers <robert.w.withers@gmail.com> wrote:
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.
Alright, please let me know. If someone shows me how to get this into configurations and the Catalog, we'll get it done.
Versionneer... http://forum.world.st/Versioneer-nice-mmMmmm-td4779483.html Catalog... http://catalog.pharo.org/catalog/note-for-developers?_k=1Ur7YrxY2p1TaD4k Repository for Configuration... http://smalltalkhub.com/#!/~Pharo/MetaRepoForPharo50 cheers -ben
robert
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@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