TLS Version supported by Zinc/Pharo

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

TLS Version supported by Zinc/Pharo

Torsten Bergmann
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.

Reply | Threaded
Open this post in threaded view
|

Re: TLS Version supported by Zinc/Pharo

NorbertHartl
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.

Reply | Threaded
Open this post in threaded view
|

Re: TLS Version supported by Zinc/Pharo

EstebanLM
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.
>


Reply | Threaded
Open this post in threaded view
|

Re: TLS Version supported by Zinc/Pharo

Nicolas Cellier
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.
>



Reply | Threaded
Open this post in threaded view
|

Re: TLS Version supported by Zinc/Pharo

Sean P. DeNigris
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
Reply | Threaded
Open this post in threaded view
|

Re: TLS Version supported by Zinc/Pharo

Stephane Ducasse-3
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.
>> >
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: TLS Version supported by Zinc/Pharo

Nicolas Cellier


2017-12-22 21:07 GMT+01:00 Stephane Ducasse <[hidden email]>:
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
<[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.
>> >
>>
>>
>