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

Rob Withers reefedjib at gmail.com
Thu May 12 16:31:49 CEST 2011


The Cryptography project, which has Cryptography, CryptographyPlugins, 
LayeredProtocol and SSL packages are all tagged with pharo.   When I look at 
the pharo tag, none of these show up.  Do they need to be releases?

How can I use the pharo tag from inside of Pharo, with the Monticello 


-----Original Message----- 
From: Stéphane Ducasse
Sent: Thursday, May 12, 2011 10:10 AM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] SSL/HTTPS - 
SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk 

Or you keep
Cryptology and publish a pharo tag.


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

More information about the Pharo-project mailing list