From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc36.google.com (mail-oo1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) by sourceware.org (Postfix) with ESMTPS id 00AC33857728 for ; Wed, 27 Sep 2023 13:58:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 00AC33857728 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oo1-xc36.google.com with SMTP id 006d021491bc7-57b8a0f320dso4614917eaf.1 for ; Wed, 27 Sep 2023 06:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1695823127; x=1696427927; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=yyt6xh1EXkUOhVlfl6YJNgLpqSY6uN9BkeVgmE2x+BA=; b=zv3x6AZf5VL8Ey8MyatodKRAqPd2D4YBFEuJBU7ojj25j1aKMP6iRDyEA/Hriog7g6 ZaUNYDkfiE+T+MtEwSuWs18ad/diP80+sdUaD/Mx0cAU+TuNcyVVKJA2a+7ymR9KZ1Iv bixw19jWOjsy98c5xw6g8V+JqjUI2ntalCuCVbj6lJeHsY9cHCmS5PaL2zSIM8zk+O3P NEk0wuXxT1tCK6gVU+++S/ekxV58nj1R9atsWHQOhS+XDOFxMB81l/X8js15gqgSdxOU Lk5jrJxlwFmo18CwGEMdeXaAVko+W0tTRwQTXnvUMn/GvPgV5DYOBfM+oB0Zm/42UumP MCxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695823127; x=1696427927; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yyt6xh1EXkUOhVlfl6YJNgLpqSY6uN9BkeVgmE2x+BA=; b=B3i9nPSRUTOjgmcekXGGAGfPeOdFKKhMzcUkwdj44FcFaHqKMkKvD/Z8h/ynoG9TAI VOwxR1yzb+J7Y2CTntSDGLuIwRMSmVQA4oEvPfEEO5IvxCsm9X0piLrb6FQbG5ZaYBQj lWEiRuV1FsEUU3pkrMPQ0n7j/Won5BKBnesoHmmu0jEea1l1kxsmoJ0JjQEgp4O9kqjK IFih6ubO+dPgZJJR3m9QKHZR/2DA9P/Ofb0/BOAEdoambLm/a4YSDv/h8pLmUr4I3dbi xONfrA1P2Yl/u70hveLEtVxFsDRMG5ENlOv7JoOcKxn1ndpOGufmjhfMOmOHsdHXKXjl 7j7w== X-Gm-Message-State: AOJu0YwpiKr13s1Vs3pX6ySTM/Q8m2RjCVXB9A7EPC5ivQn8FBftiq6/ Iml4wIeUkD4MyOCQDfQHV0/UA1M0GHxuKDjTMI8HaQ== X-Google-Smtp-Source: AGHT+IHjOKHRwUyMo6IxL57+JPXnRMWROfnbs6L4CTjW9fXFHWQiFp8oIYJqdtZYVxjXYGbPGChs8g== X-Received: by 2002:a05:6358:723:b0:132:f294:77fe with SMTP id e35-20020a056358072300b00132f29477femr1988955rwj.2.1695823127143; Wed, 27 Sep 2023 06:58:47 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:6eb0:6d4f:92fe:5e4e:27d3? ([2804:1b3:a7c1:6eb0:6d4f:92fe:5e4e:27d3]) by smtp.gmail.com with ESMTPSA id b5-20020aa78705000000b0068ff267f094sm1210811pfo.158.2023.09.27.06.58.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Sep 2023 06:58:46 -0700 (PDT) Message-ID: Date: Wed, 27 Sep 2023 10:58:44 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/4] Remove libcrypt Content-Language: en-US To: Zack Weinberg , GNU libc development References: <80f93982-dac6-4d4e-b9eb-9a5d09710a9c@app.fastmail.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <80f93982-dac6-4d4e-b9eb-9a5d09710a9c@app.fastmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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]. > > Patch #1 was compile-tested on x86_64-linux with both --enable-crypt > and the default --disable-crypt; furthermore, in the --enable-crypt > configuration, I ran "make xcheck subdirs='crypt locale'" with no > failures. Patch #2 was only compile tested. For patch #3, which only > touches the manual, I did 'make info html' and inspected the output. > (I don't have TeX on this computer so I couldn't run 'make pdf'.) > Finally, after patch #4 I ran the complete testsuite ('make check' > only) and found no new failures. 26 tests are failing on my machine > due to probable environment issues, but they were all failing on trunk > before I started making changes, and none of them appear to have > anything to do with this patchset. 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). I also see no point in adding extra costly md5 tests, since the integrity support is not really implemented in glibc. If you really think changing the md5 implementation for localedef integrity would be really useful, it would be better to be proposed in a different patch. > > 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. > > There are a few files of test data that mention the crypt directory > and/or its contents, e.g. benchtests/strcoll-inputs/filelist#en_US.UTF-8. > As best I can tell, the intent of these is just to have a big pile of > strings and it doesn't matter whether the named files exist, so I > haven't altered them. > > I seem to have a slightly different version of autoconf than the one > that was last used to regenerate the top-level configure script. If > that's a problem, let me know. > > I deleted the paragraph at the beginning of crypt.texi about legal > restrictions on cryptographic software, because after this patchset > the only cryptographic code in glibc itself will be the MD5 > implementation used by localedef (see first patch in this series), > which is not exposed to users of the library, and the DES > implementation in sunrpc/, which is also slated for removal (right?) > If this paragraph should be preserved, please let me know. > 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). [1] https://patchwork.sourceware.org/project/glibc/list/?series=24938