TLS Version supported by Zinc/Pharo
Locked
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. |
Re: TLS Version supported by Zinc/Pharo
|
|
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 <[hidden email]>: > > 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 <[hidden email]> 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 <[hidden email]>: >> >> 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. > |
Re: TLS Version supported by Zinc/Pharo
|
|
Hi Norbert, having something integrated into the VM is not necessarily hard.So your point is maybe more about delivery of the binary artefacts. 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 <[hidden email]>: the week I return from holidays I’m planing to get all that done (vm stuff). |
Re: TLS Version supported by Zinc/Pharo
|
Administrator
|
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
Cheers,
Sean |
Re: TLS Version supported by Zinc/Pharo
|
|
In reply to this post by Nicolas Cellier
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 <[hidden email]> 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 <[hidden email]>: >> >> 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 <[hidden email]> 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 <[hidden email]>: >> >> >> >> 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. >> > >> >> > |
Re: TLS Version supported by Zinc/Pharo
|
|
2017-12-22 21:07 GMT+01:00 Stephane Ducasse <[hidden email]>: Hi nicolas Hi steph, If I had the dictatorship, I would not only wish ;) Git supports branches and usually good processes are 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 |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |