On May 12, 2011, at 4:31 PM, Rob Withers wrote: > Stef, > > 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?
By tag I do not know :) > How can I use the pharo tag from inside of Pharo, with the Monticello Browser? > > Rob > > -----Original Message----- From: Stéphane Ducasse > Sent: Thursday, May 12, 2011 10:10 AM > To: [email protected] > Subject: Re: [Pharo-project] SSL/HTTPS - > SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk > implementations > > Or you keep > Cryptology and publish a pharo tag. > > Stef > > 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 >> >> >> > > >
