On Mon, Oct 26, 2020 at 09:02:40PM -0400, David T. Lewis wrote:
Hi Levente,
On Tue, Oct 27, 2020 at 12:59:55AM +0100, Levente Uzonyi wrote:
Hi David
On Mon, 26 Oct 2020, David T. Lewis wrote:
I do not know if it is related to the CI issues, but here is one clue:
I am maintaining a V3 "trunk" image that attempts to keep in sync with trunk except for changes that pertain to Spur object format (immediate characters, etc). As of Monticello-ul.728 I get failures in SSL connection to e.g. source.squeak.org. The failures happen with both Cog and the interpreter VM (although the specific error symptoms are different).
I can bypass the errors by reverting MCHttpRepository>>httpGet:arguments: to its prior version (stamped ul 9/20/2019).
That version adds some rewrite rules, so some http urls are converted to https. If that doesn't work, then there is a problem with the SqueakSSL plugin in your VM. Does the following print true?
| response | response := WebClient httpGet: 'https://source.squeak.org'. response code = 200
With an interpreter VM, I get a failure from primitiveSSLCreate.
With Cog (squeak.cog.v3_linux32x86_202010010729.tar.gz) I also get a failure on the same primitive call.
So yes it is probably an issue with the SqueakSSL plugin.
Sorry I don't have time to follow up on this properly, I just wanted to mention that I saw an issue in case it relates to the CI problems.
I'm sorry, I reported this incorrectly.
With Cog (squeak.cog.v3_linux32x86_202010010729.tar.gz) I get the failure on primitiveSSLCreate. Basically "SqueakSSL new" is failing.
With an interpreter VM, SqueakSSL class>>new succeeds, and the failure happens later with a "Host name mismatch" on the certificate. The SecureSocketStream thinks that the host name is source.squeak.org, and the SqueakSSL thinks that its peerName is squeak.org. Very likely this is a plugin problem also, since the interpreter VM would be using an outdated version of the plugin.
Dave