you can in pharoTaskForces or you can create a PharoSSL Stef
> 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 > > >
