[squeak-dev] SSL/Socket error code interpretation

Tobias Pape Das.Linux at gmx.de
Tue May 19 17:14:14 UTC 2020


> On 19.05.2020, at 19:05, tim Rowledge <tim at rowledge.org> wrote:
> 
> 
> 
>> On 2020-05-19, at 10:01 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
>> 
>> 
>>> On 19.05.2020, at 01:45, tim Rowledge <tim at rowledge.org> wrote:
>>> 
>>> As an aside, Squeak 5.3-19435 running on the 20200429xxxxx ARMv6linux VM still fails the SSL test, but I think we established that the certificate included in the image for testing is a bit out of date?
>>> 
>>> 
>> 
>> It is. But it already was when Andreas poured its contents into the imageā€¦
>> so it may be on purpose?
>> 
>> What's the remedy?
>> A long-term self-singed cert? This is only marginally better to test whether certificate checking works and no better to test whether TLS-encryption works :)
> 
> I'd imagine that we could do with several options; one that should work, one that should fail because of out of date, one with broken CN, etc. Might it be practical to set up a site from where we could download the example certificates when running the tests rather than cluttering up the normal image? Part of the test of course would be whether the examples could be downloaded :-)

In theory, yes, but this makes the test non-selfcontained and even more brittle on Travis (or whatever CI).
The problem is that it's not easy to have a properly signed Certificate[1], so we have to rely on a self-signed cert anyway.
Which means we already have to lower the certificate check criteria, so there is no point in having a non-expired one in the first place.
(For the default test)

We might probably need to test whether certain cert-checks work, but this actually only test Plugin-code no image code.
This is fine, but we have to be aware. 

so may layers.

Best regards
	-Tobias


[1]: Yes, there is Let's Encrypt and it is very good for actual use, but for tests not so much as we cannot really rely on their 3 month-expiry rule. It is really impractical to write meaningful tests in this setup, we would rather test whether Let's Encrypt works (which is pointless) than whether our stuff works.


More information about the Squeak-dev mailing list