curl / Mailing Lists / curl-library / Single Mail
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

From: Patrick Monnerat via curl-library <>
Date: Wed, 19 Jul 2023 02:39:12 +0200

On 7/19/23 01:11, Daniel Stenberg wrote:
> On Wed, 19 Jul 2023, Patrick Monnerat wrote:
>> There's no CI for OS400 because 1) tests do no run on this platform;
>> 2) is there an OS400 CI environment available ?
> I don't know. I don't see why there couldn't be?
 From replies from others (many thanks to them!), it seems it is
feasible but is completely out of my skills, I'm afraid.
>> For 16 years, the OS400 port has been tested manually to all users'
>> satisfaction.
> I don't think that is true. Just about every release is shipped with
> broken os400/gskit builds because nobody tests curl+gskit in CI and
> not from git either. The fact we've had a bad situation for 16 years
> is not a very good motivation to keep it.
This has occurred for 7 years only. And these are primarily compilation
problems, not related to gskit.
> Back when we added gskit support we didn't test a single TLS backend
> in CI builds. Now we test all TLS backends except gskit. We would not
> dream of accepting a new TLS backend without it.
>> 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 "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".
> I don't see it "in shape" now. I have repeatedly said since, many
> times, that gskit is up for deletion and yet not a single soul has
> spoken up about it. I don't sense a strong desire to keep it around.
Well, the definition of "in shape" is missing! My feelings back to
January was mainly TLS 1.3 and its crypto algorithms. I do have now such
a version that compiles, but still untested regarding its functionalities.
>> You did not mention a CI.
> I do now. In 2023, not testing code regularly in CI is just lame.
This is probably true nowadays in our open-source word. I've never seen
such a practice or a standardized way of doing it on the OS400 world. I
have to admit that for 7 years, I'm not as involved in it as I was before!
>> IMO, I now have done enough developments that are not accepted, or
>> even ignored.
> You have done a lot, more than anyone I know, for OS400 and gskit in
> curl. This is not a dis against you or any other individual. It just
> happens that this area is *clearly* not valued very much by the
> community that uses it so it has always remained in this weird
> half-assed state. Struggling.
Yes, as already mentioned in the January thread, the OS400 world is
another planet where there are only users :-(
> I think we as a community has a responsibility to gradually enhance
> and improve curl and over time trim it and cut out code and parts of
> the project that can't keep up with this.
Sure, providing we can reasonably use an infrastructure that allows it.
In the OS400 context, the infrastructure is not reasonable for what we
need and making it up by ourselves (whoever it is) is a project by itself.
> I think it can be saved. I just don't think the OS400 peeps are up for
> it. I see no evidence of such attempts - other than from you Patrick.
> I value your efforts, but I think it is rather lame that you as an
> individual should save the port for a commercial operating system that
> virtually not a single private person uses and everyone pays a lot of
> money for, but the companies themselves don't care for curl on their
> platform.
But users do. And I know some other commercial company we do care about,
that very frequently makes mistakes around our project and the
communication around it! That's even worse :-(
> In my mind, what would save gskit in curl would the very least be
> someone setting up a CI for curl + gskit. Then refresh the code and
> support modern things like TLS 1.3.
As said before, TLS 1.3 is ready. And again, before a CI we must have
the test environment. But before August, this is just !
Received on 2023-07-19