Or you keep
Cryptology and publish a pharo tag.
Stef
On May 12, 2011, at 3:52 PM, Rob Withers wrote:
> Try this, after loading the Crypto packages. I haven't tried it myself, yet,
> as I only got on this list and loaded Pharo a few days ago, but I will
> probably dig into it over the weekend. I did load Crypto, though.
>
> http://www.squeaksource.com/Cryptography/SSL-mtf.16.mcz
>
> Is there a Pharo repository I could drop ported code into?
>
> Regards,
> Rob
>
>
>
>
>
> -----Original Message----- From: Sven Van Caekenberghe
> Sent: Tuesday, May 10, 2011 1:42 PM
> To: Pharo Project
> Subject: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSession
> forPharo/Squeak and other Smalltalk implementations
>
> SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other
> Smalltalk implementations
>
>
> HTTP client and server functionality has become an essential part of any
> Smalltalk implementation. There exist various open source solutions
> delivering this functionality.
>
> Users quickly find out that HTTPS is not as readily available as HTTP.
> Although a solution exists in the form of SqueakSSL, it is not easily
> portable to Pharo and certainly not to other Smalltalk implementations.
> Furthermore, SqueakSSL is incomplete and more a working proof of concept than
> a high quality, high performance, maintainable piece of code, partially
> because of its dependence on the internals of SocketStream.
>
> Hence, some people wanting HTTPS on Pharo as well as one organisation have
> come foreword with a bounty to force a solution. Here are the requirements, a
> plan of action and a number of steps to build such a solution.
>
>
> First of all, it would be stupid not to start from the work already done for
> SqueakSSL. Any new solution should start from the existing plugin, from the
> existing set of primitives and from the current implementation of these
> primitives for the Windows, Mac OS X and Linux platforms.
>
> The Smalltalk part of the solution should be as platform independent as
> possible. We therefor need a new, clean implementation of SocketStream, with
> proper internal buffering and optimised versions of the bulk input and output
> primitives. The code should be time and space efficient. At first, only
> binary I/O is needed. Encoding/decoding is best done by wrapping the stream.
> Maybe a bivalent stream could be an option. The current ASCII support in
> quite limited.
>
> Next a SecureSocketStream can be implemented using this clean base combined
> with the SSLSession primitives. Here too, time and space efficiency are
> important although SSL will by definition be less efficient.
>
> Eventually, HTTP frameworks can then use this SecureSocketStream to actually
> implement HTTPS. Although the primary requirement is client functionality,
> server functionality should be provided as well.
>
> Next the existing issues with certificates need to be resolved, on all 3
> platforms.
>
> Finally, the C code of the plugin for each of the 3 platforms needs to be
> cleaned up and improved where necessary. This requires contributions from
> developers who know and understand a platform as well as how SSL is supposed
> to work. Furthermore they have to understand and be motivated to work on
> Smalltalk plugins. Up to 3 different developers might be needed.
>
> The current implementation on Mac OS X does not seem to (directly) use the
> standard OpenSSL library from Linux although this library exists on Mac OS X.
> This could be an opportunity to reduce the number of implementations of the
> plugin to 2 API's.
>
> Needless to say the whole implementation should be open source licensed
> (MIT), be documented and have a number of units tests to cover it's main
> functionality as well edge cases encountered in the field.
>
> Friendly cooperation with other open source projects in the Smalltalk world
> is a plus. This project should benefit the whole community.
>
>
> The bounty should be split in different parts.
>
> The first part is setting up the new project, delivering the new
> SocketStream, SSLSession and SecureSocketStream, including the HTTPS client
> proof of concept. Traction within the community has to be developed.
>
> Next the issues with the plugin have to be identified. Then the work on the
> plugin code for each platform has to be defined and 3 more bounties could be
> offered.
>
> The goal should be to include the plugin in VM's by default.
>
> With a proper solution to the plugin issues, SSL server functionality should
> be no problem.
>
>
> I offer to take on part one and help manage the coordination of this project.
>
> So is there anyone capable and willing to help out on the plugin on on one or
> more platforms for part of the bounty ?
>
> Are there others who wish to raise the bounty ?
>
> We will need a couple of good beta testers who understand this field as well.
>
>
> Sven
>
>
>
