[courier-users] courier-authlib: exported symbols

[Markus Wanner]

Hello Sam,

I'm about to take over maintenance of the courier-mta packages in
Debian, so I'll likely have further questions.

Let's start with a simple one regarding courier-authlib:

Compared to 0.66.4, these three symbols have vanished from
libcourierauthcommon.so.0 in version 0.67.0:

* ***@Base 0.66.4
* ***@Base 0.66.4
* ***@Base 0.66.4

What happened to them?

Removing symbols is certain to be backwards-incompatible, but the
library's soversion didn't change. If the authlib is intended to be
backwards-incompatible, mind to incement the soversion?
Do all of these really need to be visible?

Kind Regards

Markus Wanner

[Sam Varshavchik]

Post by Markus Wanner
Hello Sam,
I'm about to take over maintenance of the courier-mta packages in
Debian, so I'll likely have further questions.
Compared to 0.66.4, these three symbols have vanished from
What happened to them?
Removing symbols is certain to be backwards-incompatible, but the
library's soversion didn't change. If the authlib is intended to be
backwards-incompatible, mind to incement the soversion?
(c++)"courier::auth::config_file::expand_string(std::__cxx11::basic_string<char,

libcourierauthcommon is not solely an externally-linked library. It's also
linked to by other .so-s in the package. These symbols correspond to
internal APIs.

Post by Markus Wanner
Do all of these really need to be visible?

Yes. Other modules in the library need them. The libraries could be
refactored so that the internal APIs are placed into a separate, non-
versioned .so

[Markus Wanner]

Sam,

Post by Sam Varshavchik
libcourierauthcommon is not solely an externally-linked library. It's
also linked to by other .so-s in the package. These symbols correspond
to internal APIs.

Am I correct to assume that libcourierauthcommon is an internal library
and not part of the public API of courier-auth, i.e. users of
courier-auth shouldn't ever directly link to it?

Do libauthpam.so and libauthcustom.so exposed a public API?

Kind Regards

Markus Wanner

[Alessandro Vesely]

Hi Markus,

Post by Markus Wanner

Post by Sam Varshavchik
libcourierauthcommon is not solely an externally-linked library. It's
also linked to by other .so-s in the package. These symbols correspond
to internal APIs.

Am I correct to assume that libcourierauthcommon is an internal library
and not part of the public API of courier-auth, i.e. users of
courier-auth shouldn't ever directly link to it?
Do libauthpam.so and libauthcustom.so exposed a public API?

I, for one, run my own pipeauth

ldd /etc/courier/authlib/authProg
linux-vdso.so.1 => (0x00007fffb59bc000)
libcourierauthsasl.so => /usr/local/lib/courier-authlib/libcourierauthsasl.so (0x00007ff1e44cd000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff1e4140000)
libcourierauthcommon.so => /usr/local/lib/courier-authlib/libcourierauthcommon.so (0x00007ff1e3f37000)
libcourierauth.so => /usr/local/lib/courier-authlib/libcourierauth.so (0x00007ff1e3d2a000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff1e46d0000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff1e3a23000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff1e37a1000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff1e358b000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007ff1e3354000)

API recently changed, so my authProg is now portable, but I haven't autoconfed it yet.
Ale

[Markus Wanner]

Hello Alessandro,

Post by Alessandro Vesely
I, for one, run my own pipeauth
ldd /etc/courier/authlib/authProg
linux-vdso.so.1 => (0x00007fffb59bc000)
libcourierauthsasl.so => /usr/local/lib/courier-authlib/libcourierauthsasl.so (0x00007ff1e44cd000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff1e4140000)
libcourierauthcommon.so => /usr/local/lib/courier-authlib/libcourierauthcommon.so (0x00007ff1e3f37000)
libcourierauth.so => /usr/local/lib/courier-authlib/libcourierauth.so (0x00007ff1e3d2a000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff1e46d0000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff1e3a23000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff1e37a1000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff1e358b000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007ff1e3354000)

The interesting question here would be whether you're linking against
libcourierauthsasl (and using its symbols only) or if your authProg
depends on libcourierauthcommon, directly. (Indirectly, via
libcourierauthsasl, libcourierauthcommon will always be linked in either
case.)

(Other than that I note that you're not using Debian packages, in the
first place, so you wouldn't be affected. I still appreciate your
inputs. Maybe there are Debian users doing or wanting to do the same.)

Kind Regards

Markus Wanner

[Sam Varshavchik]

Post by Markus Wanner
Sam,

Post by Sam Varshavchik
libcourierauthcommon is not solely an externally-linked library. It's
also linked to by other .so-s in the package. These symbols correspond
to internal APIs.

Am I correct to assume that libcourierauthcommon is an internal library
and not part of the public API of courier-auth, i.e. users of
courier-auth shouldn't ever directly link to it?

No, I said "solely". Apps do link to libcourierauthcommon.

Post by Markus Wanner
Do libauthpam.so and libauthcustom.so exposed a public API?

No, these ones are internal modules only.