From: Petr Lautrbach <plautrba@redhat.com>
To: SElinux list <selinux@vger.kernel.org>
Cc: Stephen Smalley <stephen.smalley.work@gmail.com>
Subject: Re: drop symbol versioning from libsepol and libsemanage?
Date: Thu, 13 Aug 2020 19:47:22 +0200 [thread overview]
Message-ID: <20200813174722.GA14310@localhost.localdomain> (raw)
In-Reply-To: <CAEjxPJ7khd7dprzEKgc5zeyaHWWRQ7P8pOg09LtiBVaOi6jYTg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1911 bytes --]
On Fri, Aug 07, 2020 at 02:54:18PM -0400, Stephen Smalley wrote:
> As noted in https://github.com/SELinuxProject/selinux/issues/245,
> symbol versioning in libsepol causes problems for LTO. libsepol and
> libsemanage have a handful of versioned symbols due to incompatible
> ABI changes made early in the CIL integration. However, as far as I
> can tell, these symbols were only used by other components of the
> selinux userspace, not externally. Should we stop supporting the old
> versions going forward and simplify the maps? If so, does this truly
> require bumping the .so version or can we omit that since there are no
> external users? Thoughts?
>
AFAIK libsemanage is used by some 3rd parties. We've had requests to ship
libsemanage-devel in RHEL-8 repositories in order customers build their
applications.
From my packager POV I like symbol versioning - it helps to prevent some
dependency issues in development branches, e.g. when libsemanage is built with
new libsepol symbol but the new package doesn't require newer libsepol. rpm is
able to solve that:
$ rpm -q --requires libsemanage
...
libselinux(x86-64) >= 3.1-2
libselinux.so.1()(64bit)
libselinux.so.1(LIBSELINUX_1.0)(64bit)
libsepol.so.1()(64bit)
libsepol.so.1(LIBSEPOL_1.0)(64bit)
libsepol.so.1(LIBSEPOL_1.1)(64bit)
libsepol.so.1(LIBSEPOL_3.0)(64bit)
...
$ rpm -q --provides libsemanage
config(libsemanage) = 3.1-2.fc33
libsemanage = 3.1-2.fc33
libsemanage(x86-64) = 3.1-2.fc33
libsemanage.so.1()(64bit)
libsemanage.so.1(LIBSEMANAGE_1.0)(64bit)
libsemanage.so.1(LIBSEMANAGE_1.1)(64bit)
LTO seems to cause problems to other projects as well
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XMIQMN5KNAZUPX6O3LN6JJGTCZTP4B7J/
So I'd prefer if we try to do and use symbol versioning correctly, but it's not
hard requirement from my side.
Petr
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-08-13 17:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-07 18:54 drop symbol versioning from libsepol and libsemanage? Stephen Smalley
2020-08-13 17:47 ` Petr Lautrbach [this message]
2020-08-13 17:56 ` Stephen Smalley
2020-08-18 13:40 ` Petr Lautrbach
2020-08-24 14:15 ` Stephen Smalley
2020-08-26 7:47 ` Petr Lautrbach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200813174722.GA14310@localhost.localdomain \
--to=plautrba@redhat.com \
--cc=selinux@vger.kernel.org \
--cc=stephen.smalley.work@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.