Message ID | 80f93982-dac6-4d4e-b9eb-9a5d09710a9c@app.fastmail.com |
---|---|
Headers | show |
Series | Remove libcrypt | expand |
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
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
On 27/09/23 15:05, Zack Weinberg wrote: > 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? I removed them entirely, my patch moves the md5.c and the md5-block.c to locale/programs (with some minor changes to remove the md5_stream function that is not used by localedef) since the integrity check is not really used anywhere. > >>> 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. Afaiu it should be caught in built time if any other shared library still uses it. > >> 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). Joseph asked to remove the shlib-versions entries, so what about I add your documentation on top my patch and send a v2?
On Wed, Sep 27, 2023, at 2:19 PM, Adhemerval Zanella Netto wrote: >> 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). > > Joseph asked to remove the shlib-versions entries, so what about I add > your documentation on top my patch and send a v2? If you don't mind doing that work, please go ahead. zw