[Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSession forPharo/Squeak and other Smalltalk implementations

Rob Withers reefedjib at gmail.com
Thu May 12 15:52:38 CEST 2011

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.


Is there a Pharo repository I could drop ported code into?


-----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 

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 


More information about the Pharo-project mailing list