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>
Attachment:
pgpa3NNoQVxEw.pgp
Description: OpenPGP Digital Signature