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

[Carlos O'Donell <carlos at redhat dot com>]

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

For example libcrypt + Network Security Services (NSS) (--enable-nss-crypt)
is used by many users who need US government compliance with FIPS 140-1. It's
not clear to me that libxcrypt provides that kind of compliance. This means
that until then we'd need to keep the compat code in glibc. This doesn't mean
we can just sit around waiting for things to happen, I think Red Hat can and
should take an active role in helping libxcrypt.

Like the Sun RPC to TIRPC transition, it is a long, long, way to Tipperary.

-- 
Cheers,
Carlos.