Fwd: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations

Si a alguien le interesa trabajar por algo de dinero (no se cuanto) en
un proyecto más que interesante, acá hay una oportunidad.....


---------- Forwarded message ----------
From: Sven Van Caekenberghe <[hidden email]>
Date: 2011/5/10
Subject: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSession for
Pharo/Squeak and other Smalltalk implementations
To: Pharo Project <[hidden email]>


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





--
=================================================
Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
Arduino Software & Web Hosting   http://www.arduinosoftware.com
PasswordsPro  http://www.passwordspro.com
=================================================