On 06/19/2018 08:11 PM, Kevin R. Bulgrien wrote:
> Having found oneself in a situation where TLS 1.2 is about to become a hard
> requirement, an opportunity to upgrade a very old (7.15.1) curl/libcurl has
> arisen.

TLS 1.3 is upon us real soon now and I should think TLS 1.2 has been a
hard "requirement" for a long long time now.

> The environment that needs upgrade is an OpenServer 5.0.7 system. GNU tools
> are available, and it has been possible to build a number of newer tools in
> this environment. In fact, it was possible to build up to curl 7.53.1 with
> only a modicum of fuss needed to adapt to the present state of the build
> environment; the openssl-1.0.2o.tar.gz LTS release built fine with no issue.

I suggest OpenSSL 1.1.0h and curl 7.60.0 as the place to start.
Works fine on yet another hard core UNIX environment here :

n0$ /usr/local/bin/openssl version
OpenSSL 1.1.0h 27 Mar 2018

n0$ /usr/local/bin/curl --version
curl 7.60.0 (sparc64-sun-solaris2.10) libcurl/7.60.0 OpenSSL/1.1.0h
zlib/1.2.8 libidn2/2.0.4 libssh2/1.8.0
Release-Date: 2018-05-16
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
UnixSockets HTTPS-proxy

n0$ psrinfo -pv
The physical processor has 6 virtual processors (0-4 6)
   SPARC64-VII+ (portid 1024 impl 0x7 ver 0xa1 clock 2860 MHz)
n0$

> As curl 7.53.1 is by far new enough to support TLS 1.2, one could stop with
> this success, but, it seems prudent to assure a capability of building up to
> current, not only to address vulnerabilities between 7.53.1 and current, but
> also, to prepare for building follow-on releases per future vulnerabilities.

*nod*

> As gcc on this system as been more reliable ...

What rev of gcc do you have on hand and did you bootstrap it yourself?

>than the native cc for this sort
> of effort, use of the GNU tools created an issue in include/curl/system.h.
> It was not terribly difficult to resolve this issue with a change based on
> the fall-through code:
>
> #else
> /* generic "safe guess" on old 32 bit style */
> # define CURL_TYPEOF_CURL_OFF_T long
> # define CURL_FORMAT_CURL_OFF_T "ld"
> # define CURL_FORMAT_CURL_OFF_TU "lu"
> # define CURL_SUFFIX_CURL_OFF_T L
> # define CURL_SUFFIX_CURL_OFF_TU UL
> # define CURL_TYPEOF_CURL_SOCKLEN_T int
> #endif
>
> The change incorporates use of a _SCO_DS define mentioned along with a code
> sample that "illustrates how to test for various SCO UNIX platforms when
> doing conditional compilations".
>
> http://osr507doc.sco.com/en/DevSysoview/Ccompil.html#Multiplat
>
> The patch is:
>
> --- ../curl-7.60.0.orig/include/curl/system.h 2018-05-07 04:18:02.000000000 -0500
> +++ ./include/curl/system.h 2018-06-18 02:11:08.000000000 -0500
> @@ -320,6 +320,14 @@
> # define CURL_PULL_SYS_TYPES_H 1
> # define CURL_PULL_SYS_SOCKET_H 1
>
> +#elif defined(_SCO_DS) /* SCO OpenServer 5 */
> +# define CURL_TYPEOF_CURL_OFF_T long
> +# define CURL_FORMAT_CURL_OFF_T "ld"
> +# define CURL_FORMAT_CURL_OFF_TU "lu"
> +# define CURL_SUFFIX_CURL_OFF_T L
> +# define CURL_SUFFIX_CURL_OFF_TU UL
> +# define CURL_TYPEOF_CURL_SOCKLEN_T int
> +
> /* ===================================== */
> /* KEEP MSVC THE PENULTIMATE ENTRY */
> /* ===================================== */
>
> The patch is untested at this time, because the source still will not build
> without additional changes, but, in fact, this system is an old 32 bit
> operating system, so is probably reasonable for the moment.

I have had plenty of experience dealing with old systems and fully
understand the struggle. Even worse are the gnuisms and strange gnu
extensions tossed into nearly everything open source these days.

>
> Currently, a build of 7.60.0 blows up as shown here:
>
> warnless.c:101:4: #error "SIZEOF_CURL_OFF_T not defined"
> warnless.c: In function `curlx_uztoso':
> warnless.c:192: error: `CURL_MASK_SCOFFT' undeclared (first use in this function)
> warnless.c:192: error: (Each undeclared identifier is reported only once
> warnless.c:192: error: for each function it appears in.)
> make[2]: *** [libcurl_la-warnless.lo] Error 1
> make[2]: Leaving directory `/csdi/admin/kevinb/src/curl/curl-7.60.0/lib'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/csdi/admin/kevinb/src/curl/curl-7.60.0/lib'
> make: *** [all-recursive] Error 1
>

Did you try aclocal and then autoconf to rebuild "configure" locally ?

> As SIZEOF_CURL_OFF_T appears to be conceptually affected by the configure
> script, lib/curl_setup.h, lib/curl_config.h, and other files unique to
> other build environments, it seemed prudent to request some advice as to
> how to begin to tackle the rest of the patch, particularly since I am not
> familiar with this code base, and, since it would be nice to come up with
> an acceptable project patch for this build environment.
>
> Could anyone suggest how/where it might be prudent to begin unraveling the
> aforementioned issues? If additional information can make it easier to
> give such advice, I'm more than willing to provide it. I think this is
> the correct mailing list, but feel free to direct me to a more
> appropriate venue.
>
> Thanks in advance.
>

I'd need to fire up ( yet again ) a SCO OpenServer implementation in
vmware to even begin. Good to hear that it is still out there running.
Makes me ask if you have prodution application code still running there
and why not port that elsewhere as opposed to dealing with a GNU stack
on top of ye old SCO which we all know and love but has seen its days?

Dennis Clarke
old UNIX silverback
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-06-19