Hello, 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 [1]. Jan. [1] http://www.openssl.org/related/binaries.html On Tue, May 10, 2011 at 7:42 PM, Sven Van Caekenberghe <[email protected]>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 > 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 > > >
