[Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations
Jan van de Sandt
jvdsandt at gmail.com
Thu May 12 11:07:54 EDT 2011
I can help test the client part of a HTTPS implementation. Currently I use
Zinc-HTTP together with stunnel.
Note that VA Smalltalk uses OpenSSL on Linux and Windows. So it is possible
to use OpenSSL on windows as well .
On Tue, May 10, 2011 at 7:42 PM, Sven Van Caekenberghe <sven at beta9.be>wrote:
> 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
> 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
> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev