Re: SSL_library_init not found in libssl in current

[JP <rlntlss83%gmail.com@localhost>]

my mistake -- it was in there on Apr 18 at least.  i guess that's a little old

OpenSSL version 1.1.1b 26 Feb 2019 here

On Thu, Apr 25, 2019 at 6:28 PM Greg A. Woods <woods%planix.com@localhost> wrote:
>
> At Thu, 25 Apr 2019 17:18:09 +0200, Martin Husemann <martin%duskware.de@localhost> wrote:
> Subject: Re: SSL_library_init not found in libssl in current
> >
> > On Thu, Apr 25, 2019 at 08:34:05PM +0530, Mayuresh wrote:
> > > On Thu, Apr 25, 2019 at 04:57:10PM +0200, Martin Husemann wrote:
> > > > Note that the issue is the openssl version, not the architecture (or
> > > > am I missing something?)
> > >
> > > I'd think so. Just that mail from JP on this thread says the symbol is
> > > present on current amd64. I personally have only evbarm current and 8.0
> > > amd64.
> >
> > Yeah, but it is not present in amd64 -current as of a few days ago any more ;-)
>
> More than a few days....
>
> I don't have it by default in a build from a Jan 31 checkout.
>
> However I do still have the manual page, which ends with:
>
>        The SSL_library_init() and OpenSSL_add_ssl_algorithms() functions were
>        deprecated in OpenSSL 1.1.0 by OPENSSL_init_ssl().
>
> BTW, that manual page also clearly states the function should be found
> in libcrypto (NOT libssl).  But....
>
> However, if one examines the source tree one quickly finds out that
> SSL_library_init() is now a macro (in openssl/ssl.h) which is only made
> visible if the source including it has arranged to build with the
> appropriate API compatability level.
>
> This doesn't seem to be documented in places I would consider obvious,
> but it is seen in a comment in openssl/opensslconf.h:
>
> /*
>  * Applications should use -DOPENSSL_API_COMPAT=<version> to suppress the
>  * declarations of functions deprecated in or before <version>. Otherwise, they
>  * still won't see them if the library has been built to disable deprecated
>  * functions.
>  */
>
> There's also a related note in the CHANGES file:
>
>
>   *) Revert default OPENSSL_NO_DEPRECATED setting.  Instead OpenSSL
>      continues to support deprecated interfaces in default builds.
>      However, applications are strongly advised to compile their
>      source files with -DOPENSSL_API_COMPAT=0x10100000L, which hides
>      the declarations of all interfaces deprecated in 0.9.8, 1.0.0
>      or the 1.1.0 releases.
>
>      In environments in which all applications have been ported to
>      not use any deprecated interfaces OpenSSL's Configure script
>      should be used with the --api=1.1.0 option to entirely remove
>      support for the deprecated features from the library and
>      unconditionally disable them in the installed headers.
>      Essentially the same effect can be achieved with the "no-deprecated"
>      argument to Configure, except that this will always restrict
>      the build to just the latest API, rather than a fixed API
>      version.
>
>      As applications are ported to future revisions of the API,
>      they should update their compile-time OPENSSL_API_COMPAT define
>      accordingly, but in most cases should be able to continue to
>      compile with later releases.
>
>      The OPENSSL_API_COMPAT versions for 1.0.0, and 0.9.8 are
>      0x10000000L and 0x00908000L, respectively.  However those
>      versions did not support the OPENSSL_API_COMPAT feature, and
>      so applications are not typically tested for explicit support
>      of just the undeprecated features of either release.
>      [Viktor Dukhovni]
>
>
> That says that deprecated APIs should still be supported by a default
> build of OpenSSL, and indeed I believe that's how NetBSD installs it.
>
> However it doesn't help for www/squid3.  That's because its configure
> script does not add "#include <openssl/ssl.h>" to the test program.
>
> It may also be useful to add a line like this to www/squid3/Makefile,
> but of course that won't actually make it work -- it'll just document
> that it needs at least OpenSSL-1.0.0:
>
>         CFLAGS+=        -DOPENSSL_API_COMPAT=0x10000000L
>
> The configure script will still need to be patched.
>
> Of course as mentioned squid-3 is heading on to old and should soon be
> replaced by all users with squid-4, and especially pkgsrc should
> deprecate squid-3 and provide the latest squid-4 by default.
>
> --
>                                         Greg A. Woods <gwoods%acm.org@localhost>
>
> +1 250 762-7675                           RoboHack <woods%robohack.ca@localhost>
> Planix, Inc. <woods%planix.com@localhost>     Avoncote Farms <woods%avoncote.ca@localhost>