Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Apr 2023 11:30:03 +0200
From:      Baptiste Daroussin <bapt@FreeBSD.org>
To:        Ed Maste <emaste@freebsd.org>
Cc:        Konstantin Belousov <kostikbel@gmail.com>,  freebsd-arch <freebsd-arch@freebsd.org>
Subject:   Re: OpenSSL in the FreeBSD base system / FreeBSD 14
Message-ID:  <rvpqifnghrz6xyb6ugc6uxzsxafauzofele2fs5v4qsb7aaqkv@c66dthztcs46>
In-Reply-To: <CAPyFy2DDpqfBuzdosGgLwnOENmxog-x5NM0YpYAC9Tthi4DbiA@mail.gmail.com>
References:  <CAPyFy2Afao5tnujFtwiF6avdkqAXRGDOTSq-JSCkHvvbfUvhaA@mail.gmail.com> <ZEBmahjXXlvtzP-L@kib.kiev.ua> <CAPyFy2DDpqfBuzdosGgLwnOENmxog-x5NM0YpYAC9Tthi4DbiA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 24, 2023 at 01:06:14PM -0400, Ed Maste wrote:
> On Wed, 19 Apr 2023 at 18:08, Konstantin Belousov <kostikbel@gmail.com> wrote:
> >
> > On Wed, Apr 19, 2023 at 12:50:59PM -0400, Ed Maste wrote:
> > > A related issue is base system libraries that depend on OpenSSL would
> > > also need to be made private. This includes gssapi, heimdal, and
> > > libfetch.
> > Does ssh and pam in the base depend on the base openssl?
> > If yes, then it still leaks into the applications despite being private.
> 
> Yes, I see the following libraries which bring in libssl:
> 
> /usr/lib/libprivateldns.so.5
> /usr/lib/libprivatessh.so.5
> /usr/lib/libprivateunbound.so.5
> /usr/lib/pam_ssh.so.6
> /usr/lib/libfetch.so.6
> 
> and libcrypto (privatelibs excluded):
> 
> /lib/libzfsbootenv.so.1
via inheritance from libzfs.so.4 not directly linked to libcrypto
> /lib/libbe.so.1
via inheritance from libzfs.so.4 not directly linked to libcrypto
> /lib/libzfs.so.4
"only used" for libzfs_crypto

> /usr/lib/pam_zfs_key.so.6
> /usr/lib/libkafs5.so.11
> /usr/lib/libgssapi_ntlm.so.10
> /usr/lib/libarchive.so.7

Ports already uses libarchive from ports unconditionnaly so not a pb here.
I was due to the fact that libarchive was linked to libmd instead on libcrypto
in the past, and was causing issues when libmd symbols where in collision with
libcrypto (which is fixed since but the ports tree did not move).

So not a problem here.

> /usr/lib/libkdc.so.11
> /usr/lib/libradius.so.4
> /usr/lib/libgssapi_krb5.so.10
> /usr/lib/libkrb5.so.11
> /usr/lib/libhx509.so.11
> /usr/lib/pam_radius.so.6
> /usr/lib/libssl.so.111
> /usr/lib/libkadm5srv.so.11
> /usr/lib/libkadm5clnt.so.11
> /usr/lib/libhdb.so.11
> /usr/lib/pam_ssh.so.6
> /usr/lib/libheimntlm.so.11
> /usr/lib/libfetch.so.6
> /usr/lib/libmp.so.7
> /usr/lib/pam_krb5.so.6
> /usr/lib/libbsnmp.so.6
> /usr/lib/pam_ksu.so.6
> 
> Baptiste reported elsewhere that libfetch's use in ports is very
> limited, so it could easily be made into a private lib.
> 
Or even an internallib considering there will be do consumer left but fetch(1)

best regards,
Bapt



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?rvpqifnghrz6xyb6ugc6uxzsxafauzofele2fs5v4qsb7aaqkv>