[Seaside] Re: Serving HTTPS
andreas.raab at gmx.de
Fri Nov 18 16:31:34 UTC 2011
On 11/17/2011 23:47, Sven Van Caekenberghe wrote:
> 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
Yes. On the Mac. Re-read what I wrote about missing bits on the Mac.
> SqueakSSLTest's tests:
> 11 run, 1 passes, 4 expected failures, 2 failures, 4 errors, 0 unexpected passes
These two fail due to missing certificate validation.
These fail due to the missing certificate specification since they rely
on being able to choose a certificate on the server end of the test.
I should probably make all of these expected failures, now that I think
about it. The nasty red status of the test runner isn't such a good
result when the state of the system is entirely expected. Yeah, I'll do
> WebClientServerTest's tests:
> 59 run, 58 passes, 0 expected failures, 0 failures, 1 errors, 0 unexpected passes
Oh, that's odd. No idea why that would be failing. This is really one of
the simpler tests. I'll try to find a Mac to see if I can replicate the
> As you know, the package WebClient-Pharo contains controversial methods.
You mean 1 (in words: one) method you consider controversial (I don't).
Not two, or three, or a dozen "controversial methods". In fact, after
dropping support for Pharo 1.0 the entire package consists of merely
three methods total.
> And BTW, I disagree about the Apache HTTPS Proxy option.
That's fine. I'm not trying to convince you. I just like having my
choices and I'm certain others do, too.
> 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';
>> 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.
>> - Andreas
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
More information about the seaside