Re: [PATCH 0/4] Remove libcrypt

["Zack Weinberg" <zack@owlfolio.org>]

On Wed, Sep 27, 2023, at 9:58 AM, Adhemerval Zanella Netto wrote:
> On 21/09/23 17:48, Zack Weinberg wrote:
>> In
>> https://sourceware.org/pipermail/libc-alpha/2023-September/151664.html
>> Adhemerval suggested that now would be a good time to complete the
>> removal of libcrypt.  This patch series does just that.  If you would
>> rather not apply it by hand, you can get it from the zack/remove-
>> libcrypt branch (with somewhat different commit messages -- I'll fix
>> that before merging).
>
> In fact I also sent patchset to remove libcrypt just a couple of hours
> before yours [1].

Yes, I saw that only after posting my patch set.  I didn't realize, from
your message saying that you thought it was a good time to proceed, that
you intended to work on it yourself.

> I really don't see any value of changing the md5 implementation glibc
> uses on localedef, current implementation does not have any red flag
> (such as alloca usage), it is used solely for integrity (which in
> theory could be any other algorithm, albeit changing it might add some
> compatibility issues); and for this change I think we should the code
> as similar as possible (avoid any internal API change).

Fair enough.

> I also see no point in adding extra costly md5 tests, since the
> integrity support is not really implemented in glibc.

That test isn't new, I just moved it from the crypt directory.  It looks
like your patch leaves md5.c in the crypt directory?  What did you do
with the tests in there?

>> stdio-common/Versions says that __snprintf is exported as
>> GLIBC_PRIVATE because libcrypt uses it.  I doubt that was the only
>> ancillary library using that symbol, but I don't know how to find
>> other uses, so I left the export in place; it can always be
>> removed later.
>
> The GLIBC_PRIVATE as just used between glibc installed shared objects,
> so any other external users probing on GLIBC_PRIVATE was never
> supported.

I meant, I don't know how to check whether there are any other uses of
__snprintf@GLIBC_PRIVATE *within glibc* after removing libcrypt.

> I slight more inclined to go with my patch, mainly because it tries to
> avoid changing internal APIs and pack the whole removal in only one
> patch (I also proposed the sparc crypt optimization for last release,
> but I postpone to send while libcrypt was actually removed).

The only piece of my patchset that I think is really worth keeping, is
the changes I made to the documentation.  How about you go ahead and
merge your patchset and then I'll resubmit the doc changes on top of
that?  Also I'll send a patch moving md5.c to locale/ so we can
completely remove the crypt directory (one fewer top-level directory to
walk over in the build makes a measurable difference in how long a null
incremental build takes).

zw