[PATCH] Deprecate libcrypt and don't build it by default.

[Dmitry V. Levin]

On Thu, Aug 31, 2017 at 12:29:48PM -0500, Carlos O'Donell wrote:
> On 08/29/2017 04:20 PM, Zack Weinberg wrote:
> > On Tue, Aug 29, 2017 at 4:58 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> >> On Tue, 29 Aug 2017, Zack Weinberg wrote:
> >>> On Tue, Aug 29, 2017 at 4:16 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> >>>>
> >>>> I don't believe libxcrypt's claim to be a binary-compatible replacement
> >>>> for libcrypt.so.1.  It looks to me like it uses symbol version GLIBC_2.0
> >>>> unconditionally for the glibc symbols,
> >>>
> >>> Well, that's just a plain old bug.  Obviously a bug that needs to be
> >>> fixed before we can call libxcrypt a binary-compatible drop-in
> >>> replacement, but not a _difficult_ bug - they can crib from the
> >>> libcrypt.abilist files.  I'm willing to try to work up a patch if
> >>> Björn agrees.
> >>
> >> I'm not convinced that duplicating all the information about which ABIs
> >> use which symbol versions, and how to distinguish different ABIs on each
> >> architecture that has ABIs with different base versions, is a good idea.
> > 
> > The plan would be to remove libcrypt from glibc one or two releases
> > after this deprecation, so it's not so much _duplicating_ the
> > information as _moving_ it.
> 
> I disagree that removal can happen on those timescales, but I agree that
> it would be a good idea to split libcrypt out of glibc to allow for a
> different development model

If the consensus is to remove libcrypt from glibc sooner or later rather
than extend libcrypt with API from crypt_blowfish project, then libxcrypt
is not going to be the only alternative.

In ALT, I merged crypt_blowfish into glibc's libcrypt more than 16 years
ago, and the way it's done is incompatible with the approach taken later
by libxcrypt:
function names in XCRYPT_2.0 interface differ from function names in new
interfaces we added, and the plugin approach implemented in libxcrypt that
uses dlopen+dlsym to pull in encryption methods is absolutely no-no for
the system libcrypt.

As extending libcrypt within glibc doesn't seem to be a viable option, the
current status quo works well for us because the burden of rebasing a huge
patch on top of the stale libcrypt is minimal.

On the contrary, libcrypt removal would force ALT to fork a standalone
libcrypt, that is, to invest our time and efforts into a project without
any clear benefits to anyone.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20170908/e4b04767/attachment.sig>