[Seaside] Serving HTTPS

Sven Van Caekenberghe sven at beta9.be
Thu Nov 17 22:47:21 UTC 2011


I did test your code before (as well as tried to understand and fix it). So I just tried again:

Pharo 1.3 #13315, Cog VM 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.47] Pharo Cog VM', previous SqueakSSL (it did not change on Mac) on Mac OS X 10.7.1

SqueakSSLTest's tests:

11 run, 1 passes, 4 expected failures, 2 failures, 4 errors, 0 unexpected passes



WebClientServerTest's tests:

59 run, 58 passes, 0 expected failures, 0 failures, 1 errors, 0 unexpected passes



As you know, the package WebClient-Pharo contains controversial methods.

And BTW, I disagree about the Apache HTTPS Proxy option.


On 17 Nov 2011, at 21:53, Andreas Raab wrote:

> On 11/16/2011 19:35, Sven Van Caekenberghe wrote:
>> Although SqueakSSL is usable today, it is not enough.
> Let's be specific about what isn't working instead of broadly dismissing SqueakSSL as "not enough". What's currently missing in the plugin is two pieces of Mac support: Certificate validation (i.e., given a connection how does one verify the validity of the incoming cert) and certificate specification (i.e., given the id of a certificate, how does one extract it from the user's key chain and installs it on the connection).
> However, while this may make SqueakSSL not be useful for some purposes on the Mac, it certainly doesn't render it useless in general. First of all, SqueakSSL works on Windows and Linux. Period.
> Secondly, even on the Mac, depending on what exactly you're doing it can still be good enough if you can live without certificate validation. While I wouldn't do that for a banking app, I would have no hesitations doing so for the purpose of calling the facebook graph api for retrieving basic user information. The only thing you can't do at all at this point is run an SSL server on the Mac.
>> The SecureSocketStream implementation (Smalltalk code) is difficult to port to Pharo.
> What exactly are you trying to port and why? The code works out of the box as it is. There is no need to port anything.
>> That is why there is Zodiac (http://zdc.stfx.eu). It reuses the current plugin, but uses much cleaner code. And it works well on Pharo.
> I don't mind you throwing a plug for your pet project, but claiming that WebClient and SqueakSSL don't work well on Pharo is simply disingenuous. Try for yourself:
> 	Gofer new
> 		squeaksource: 'SqueakSSL';
> 			package: 'SqueakSSL-Core;
> 			package: 'SqueakSSL-Tests;
> 		squeaksource: 'WebClient';
> 			package: 'WebClient-Core';
> 			package: 'WebClient-Tests';
> 			package: 'WebClient-Pharo';
> 		load.
> Then run the tests via:
> 	SqueakSSLTest buildSuite run.
> 	WebClientServerTest buildSuite run.
> Here are the results for various releases:
> Version           SqueakSSL       WebClient
> Pharo 1.1         11/11 PASS      56/58 PASS 2 Errors [*1]
> Pharo 1.2         11/11 PASS      59/59 PASS
> Pharo 1.3         11/11 PASS      59/59 PASS
> Squeak 4.1        11/11 PASS      58/58 PASS 1 Expected Failure
> Squeak 4.2        11/11 PASS      59/59 PASS
> Squeak 4.3        11/11 PASS      59/59 PASS
> [*1] Caused by an inconsequential bug in Pharo 1.1.
> So again, unless you have specific evidence showing that SqueakSSL doesn't work on Pharo, I think you shouldn't make general claims like that.
>> I think the server side is less important: an Apache HTTPS proxy is a better (stronger/safer/faster) solution.
> This should be a matter of choice, not of necessity. Having to administer Apache, stunnel and whatnot creates many more potential points of failure and pain.
> Cheers,
>  - Andreas
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

More information about the seaside mailing list