Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: NSS and gskit are getting the axe
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Patrick Monnerat via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 19 Jul 2023 00:30:02 +0200
On 7/18/23 23:03, Daniel Stenberg wrote:
> On Tue, 18 Jul 2023, Patrick Monnerat via curl-library wrote:
>
>> I have made some local changes to gskit, in hope to save it form
>> deprecation (modernize, TLS 1.3, ALPN).
>>
>> It compiles fine, but unfortunately I can't test it as the
>> certificate store access is denied on pub400. This is why I did not
>> submit a PR for it yet.
>
> I'm a little tired of the fragile gskit situation. I'm willing to
> re-evaluate once we see a CI job that builds and tests curl with
> gskit. I want to (continuned to) raise the bar for what is an
> acceptable level for supported TLS libraries in curl.
>
> Because if nobody can make CI builds for gskit, then I don't think it
> is that important either.
Yes, it is important because there are no alternative under OS400.
This is not a gskit problem, rather an OS400 one.
There's no CI for OS400 because 1) tests do no run on this platform; 2)
is there an OS400 CI environment available ?
No tests on OS400: would need perl among other features. These are
available under PASE which is an AIX emulation, but certainly not native
OS400.
For 16 years, the OS400 port has been tested manually to all users'
satisfaction.
If you have decided gskit cannot be saved from deprecation, please write
it explicitly and avoid letting some "hope" on it: from your Jan 2 mail
https://curl.se/mail/lib-2023-01/0003.html "If we get the gskit support
in shape in time before August 2023, I think that is a working argument
to *not* deprecate it then". You did not mention a CI. IMO, I now have
done enough developments that are not accepted, or even ignored.
Patrick
Date: Wed, 19 Jul 2023 00:30:02 +0200
On 7/18/23 23:03, Daniel Stenberg wrote:
> On Tue, 18 Jul 2023, Patrick Monnerat via curl-library wrote:
>
>> I have made some local changes to gskit, in hope to save it form
>> deprecation (modernize, TLS 1.3, ALPN).
>>
>> It compiles fine, but unfortunately I can't test it as the
>> certificate store access is denied on pub400. This is why I did not
>> submit a PR for it yet.
>
> I'm a little tired of the fragile gskit situation. I'm willing to
> re-evaluate once we see a CI job that builds and tests curl with
> gskit. I want to (continuned to) raise the bar for what is an
> acceptable level for supported TLS libraries in curl.
>
> Because if nobody can make CI builds for gskit, then I don't think it
> is that important either.
Yes, it is important because there are no alternative under OS400.
This is not a gskit problem, rather an OS400 one.
There's no CI for OS400 because 1) tests do no run on this platform; 2)
is there an OS400 CI environment available ?
No tests on OS400: would need perl among other features. These are
available under PASE which is an AIX emulation, but certainly not native
OS400.
For 16 years, the OS400 port has been tested manually to all users'
satisfaction.
If you have decided gskit cannot be saved from deprecation, please write
it explicitly and avoid letting some "hope" on it: from your Jan 2 mail
https://curl.se/mail/lib-2023-01/0003.html "If we get the gskit support
in shape in time before August 2023, I think that is a working argument
to *not* deprecate it then". You did not mention a CI. IMO, I now have
done enough developments that are not accepted, or even ignored.
Patrick
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-07-19