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: Time to deprecate gskit

From: Patrick Monnerat via curl-library <>
Date: Fri, 6 Jan 2023 20:36:15 +0100

On 1/6/23 18:44, Calvin Buckley via curl-library wrote:
> On Tue, 2023-01-03 at 20:07 +0000, Sam James wrote:
> Apologies for the late reply. I forgot to subscribe to the list when I
> sent this, so my mail got eaten for the public list (sorry you'll be
> receiving this one again Daniel!), but I took the time to revise this
> based on things I've learned talking to someone at IBM.

Hi Calvin,

Many thanks for the info.

> Speaking as someone who has submitted patches to fix the curl build on
> IBM i, I suspect there are some "dark matter" ILE curl users that
> Patrick mentioned.
Yes, they are mainly ILE/RPG developers that do Cobol-like programming
and sometimes strongly need a data transfer. If libcurl was not
available to them, they would have to write awful command scripts (CL)
involving very heavy external IBM programs and a lot of real file
read/writes !
> (I note that there lots of users for PASE, but that's just basically
> AIX w/ limitations. IBM provides ttheir own builds there.)
Agreed: from the software point of view, PASE is not "OS/400" !
> The big annoyances and possible challenges are:
> - No CI; without this, everyone knows development is much harder if you
> can't catch the FTBFS when it starts.
> - I have capacity on a shared system intended for open source
> development. I should be able to set up some kind of CI runner here.
> The very annoying part is Go isn't supported (bar an experimental port
> of 1.16), so the stock GH Actions runner et al is likely to cause
> trouble. I know Jenkins' runner works fine.
When I started porting libcurl to OS/400, it did not have CI tests! But
the local test system was already in place. I investigated to enable it
on OS/400, but gave up because it was a too heavy work for a single man
(requires perl at least). I then relied on tests on other platforms for
the functionalities and often manually tested the OS/400 specific parts.
A simple but very incomplete CI would be to have an automatic pull +
compile every night.
> - Not as many users, because no binary builds. It's pretty easy to
> build, but having to build it at all is a hurdle. Not to mention the
> other dependencies (zlib, libssh2).

This can be combined with the automatic nightly build mentioned above.

zlib and libssh2 are optional for libcurl and should also be in poor
shape: I've not heard about someone maintaining the OS/400 versions
since 2016 when I lost access to an IBM i (I'm also the OS/400 version
author for these libraries).

> - I'd be tempted to offer binary builds that can be linked from
> /download.html. Compilers let you target two versions back, and you can
> get pretty much the entire install base that matters.
> - Binaries would basically involve a savefiles of the POSIX
> filesystem parts (the headers) and the native system objects (the
> shared library, build artifacts... also headers in a different form)
AFAICR, the ILS save file could also be a QSYS object included in a
single downloadable SAVF.
> - GSKit is the system TLS library on i, and IBM is actually fairly good
> about backporting feature updates to it for older versions of i (i.e.
> TLSv1.3 et al). Plus features someone might care about like crypto
> acceleration. However, it's definitely not popular anywhere else.
This is why curl and its gskit backend need a regular maintainer that
has an OS/400 access!
> Long-term, it might be useful to look into porting a different TLS library,
> even if it adds another dependency.
> - Native environment on i is basically something CHERI/WebAssembly
> shaped, but with EBCDIC. Something like mbedTLS/BearSSL that doesn't
> ask much of its host, sprinkled with iconv.

I partially agree: the drawbacks are TLS libs are not yet ported to
OS/400, are heavy and very picky about security.

If you need an iconv wrapper that is more conform to other
implementations than the IBM systems one, see (yes, I
ported libxml2 too!).



Received on 2023-01-06