TLS Version supported by Zinc/Pharo
Hi, I used ZnClient to call an HTTPS URL and while it worked well in the past I now receive an "SSL Exception: connect failed [code:-5]". I guess the reason is an update of the URLs site to a server with newer TLS protocol (TLS 1.2 instead of TLS 1.0). Do we support that already in Pharo? Thx T.
I had that problem when openssl 1.1x library was present and SqueakSSL uses 1.0.2 library. The patch is done by Holger and ready to be integrated. But as always it is close to impossible to having something integrated in the vm. Norbert
Am 22.12.2017 um 16:12 schrieb Torsten Bergmann <astares@gmx.de>:
Hi,
I used ZnClient to call an HTTPS URL and while it worked well in the past I now receive an "SSL Exception: connect failed [code:-5]".
I guess the reason is an update of the URLs site to a server with newer TLS protocol (TLS 1.2 instead of TLS 1.0).
Do we support that already in Pharo?
Thx T.
the week I return from holidays Iâm planing to get all that done (vm stuff). Esteban
On 22 Dec 2017, at 16:17, Norbert Hartl <norbert@hartl.name> wrote:
I had that problem when openssl 1.1x library was present and SqueakSSL uses 1.0.2 library. The patch is done by Holger and ready to be integrated. But as always it is close to impossible to having something integrated in the vm.
Norbert
Am 22.12.2017 um 16:12 schrieb Torsten Bergmann <astares@gmx.de>:
Hi,
I used ZnClient to call an HTTPS URL and while it worked well in the past I now receive an "SSL Exception: connect failed [code:-5]".
I guess the reason is an update of the URLs site to a server with newer TLS protocol (TLS 1.2 instead of TLS 1.0).
Do we support that already in Pharo?
Thx T.
Hi Norbert, having something integrated into the VM is not necessarily hard. The pull request of Holger has been accepted fast enough. So your point is maybe more about delivery of the binary artefacts. The pharo builds have been broken for some time but are now fixed, thanks to Fabio/Christophe/Clement/Esteban! I wish we can preserve the green status longer this time. The question is then about the release cycle which is well too loooonnng... Continuous integration require GREEN builds, I wish we start using feature branchs and reject half-ready PR Then stability of head revision (cog) also matters. Automated tests don't catch all problems. Changing the garbage collector for example may trigger rare bugs... Maybe some essential (and limited) patch could be back-ported to well known stable point. But this can't happen with current ressources... IOW help is welcome! Nicolas 2017-12-22 16:31 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
the week I return from holidays Iâm planing to get all that done (vm stuff).
Esteban
On 22 Dec 2017, at 16:17, Norbert Hartl <norbert@hartl.name> wrote:
I had that problem when openssl 1.1x library was present and SqueakSSL uses 1.0.2 library. The patch is done by Holger and ready to be integrated. But as always it is close to impossible to having something integrated in the vm.
Norbert
Am 22.12.2017 um 16:12 schrieb Torsten Bergmann <astares@gmx.de>:
Hi,
I used ZnClient to call an HTTPS URL and while it worked well in the past I now receive an "SSL Exception: connect failed [code:-5]".
I guess the reason is an update of the URLs site to a server with newer TLS protocol (TLS 1.2 instead of TLS 1.0).
Do we support that already in Pharo?
Thx T.
Nicolas Cellier wrote
The pharo builds have been broken for some time but are now fixed, thanks to Fabio/Christophe/Clement/Esteban!
THANK YOU ALL!!!!! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Hi nicolas May be I'm naive and dull but indeed using branches is the way to go. We used that for Pillar. I can integrate fixes for the current stable in master and we are coding in a dedicated branch. I imagine that you know it, else you would not wish to use it. Git supports branches and usually good processes are - dev in local branches until it is ready and stable to merge in master - master is always the stable version and different builds can trigger and test different branches. So do I guess correctly that the VM code is not managed that way? This is surprising because all complex projects are managed that way with git. In fact good branching is one of the best features of git. Stef On Fri, Dec 22, 2017 at 5:35 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Hi Norbert, having something integrated into the VM is not necessarily hard. The pull request of Holger has been accepted fast enough. So your point is maybe more about delivery of the binary artefacts.
The pharo builds have been broken for some time but are now fixed, thanks to Fabio/Christophe/Clement/Esteban! I wish we can preserve the green status longer this time.
The question is then about the release cycle which is well too loooonnng... Continuous integration require GREEN builds, I wish we start using feature branchs and reject half-ready PR Then stability of head revision (cog) also matters. Automated tests don't catch all problems. Changing the garbage collector for example may trigger rare bugs...
Maybe some essential (and limited) patch could be back-ported to well known stable point. But this can't happen with current ressources... IOW help is welcome!
Nicolas
2017-12-22 16:31 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
the week I return from holidays Iâm planing to get all that done (vm stuff).
Esteban
On 22 Dec 2017, at 16:17, Norbert Hartl <norbert@hartl.name> wrote:
I had that problem when openssl 1.1x library was present and SqueakSSL uses 1.0.2 library. The patch is done by Holger and ready to be integrated. But as always it is close to impossible to having something integrated in the vm.
Norbert
Am 22.12.2017 um 16:12 schrieb Torsten Bergmann <astares@gmx.de>:
Hi,
I used ZnClient to call an HTTPS URL and while it worked well in the past I now receive an "SSL Exception: connect failed [code:-5]".
I guess the reason is an update of the URLs site to a server with newer TLS protocol (TLS 1.2 instead of TLS 1.0).
Do we support that already in Pharo?
Thx T.
2017-12-22 21:07 GMT+01:00 Stephane Ducasse <stepharo.self@gmail.com>:
Hi nicolas
May be I'm naive and dull but indeed using branches is the way to go. We used that for Pillar. I can integrate fixes for the current stable in master and we are coding in a dedicated branch.
I imagine that you know it, else you would not wish to use it.
Hi steph, If I had the dictatorship, I would not only wish ;) Git supports branches and usually good processes are
- dev in local branches until it is ready and stable to merge in master - master is always the stable version and different builds can trigger and test different branches.
So do I guess correctly that the VM code is not managed that way? This is surprising because all complex projects are managed that way with git. In fact good branching is one of the best features of git.
The problem is partly cultural, but not exclusively. Main specificity to take into account is that most part of development does not happen in github. It happens in VMMaker and VM simulation, ask Clement or Eliot. That explains why the github part can be seen as secondary... and why adoption of better practices is slow. And don't forget that code generation is not yet reproducible. Type inference vary from one invocation to another (due to unordered methodDictionary probably). Until we fix that, we cannot really profit by full github features and increased automation. Branches should be as short as possible, or they get impracticle. We cannot reasonnably use separate branches for sista nor lowcode for example. I mean we could, but would have to merge frequently in trunk (cog). Look how difficult it is to merge classic VMMaker and oscog branches already. Branches are easy to use for modification of platform specific source code, but they are not so much for VMMaker generated code. Concurrent modification of generated code often create many conflicts that cannot reasonnably nor safely be merged. That means that github PR does not really work for VMMaker work (unless non-concurrent). Nevertheless we should use branches and PR for small changes... Before giving lessons, I have to discipline myself. I still commit in trunk too often just because I can. You know, do what I say, not what I do ;) Stef
On Fri, Dec 22, 2017 at 5:35 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Hi Norbert, having something integrated into the VM is not necessarily hard. The pull request of Holger has been accepted fast enough. So your point is maybe more about delivery of the binary artefacts.
The pharo builds have been broken for some time but are now fixed, thanks to Fabio/Christophe/Clement/Esteban! I wish we can preserve the green status longer this time.
The question is then about the release cycle which is well too loooonnng... Continuous integration require GREEN builds, I wish we start using feature branchs and reject half-ready PR Then stability of head revision (cog) also matters. Automated tests don't catch all problems. Changing the garbage collector for example may trigger rare bugs...
Maybe some essential (and limited) patch could be back-ported to well known stable point. But this can't happen with current ressources... IOW help is welcome!
Nicolas
2017-12-22 16:31 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
the week I return from holidays Iâm planing to get all that done (vm stuff).
Esteban
On 22 Dec 2017, at 16:17, Norbert Hartl <norbert@hartl.name> wrote:
I had that problem when openssl 1.1x library was present and SqueakSSL uses 1.0.2 library. The patch is done by Holger and ready to be
integrated.
But as always it is close to impossible to having something integrated in the vm.
Norbert
Am 22.12.2017 um 16:12 schrieb Torsten Bergmann <astares@gmx.de>:
Hi,
I used ZnClient to call an HTTPS URL and while it worked well in the past I now receive an "SSL Exception: connect failed [code:-5]".
I guess the reason is an update of the URLs site to a server with newer TLS protocol (TLS 1.2 instead of TLS 1.0).
Do we support that already in Pharo?
Thx T.
participants (6)
-
Esteban Lorenzano -
Nicolas Cellier -
Norbert Hartl -
Sean P. DeNigris -
Stephane Ducasse -
Torsten Bergmann