| 16 Jul 2022 |
 vcunat | * As it seems very likely that fixes will be simply adding the separate libcrypt as build input to whatever starts missing it. | 20:45:56 |
 hexa | true | 20:47:17 |
| hexa | trying to follow https://github.com/NixOS/nixpkgs/issues/112371#issue-803317691 | 20:47:29 |
| hexa | does that make sense? | 20:47:32 |
| hexa |
Add a flag withLibcrypt (defaults to true) to glibc package that disables building and installing libcrypt.so.1 and crypt.h if set to false.
| 20:47:37 |
 K900 | As someone who's got trouble with rabbit holes, I'd just like to remind you that you wanted to not do this | 20:47:39 |
| hexa |
One-by-one update packages that expect libcrypt.so.1 in glibc by giving them a flag useGlibcLibcrypt (defaults to true).
| 20:47:48 |
| hexa | yeah, but someone has to | 20:47:59 |
| hexa | I hope I won't have to do this alone | 20:48:05 |
| hexa |
- Allow opting out of libcrypt in glibc
- Find packages that require libcrypt.so (through magic?) and make libcrypt optional
| 20:49:42 |
| hexa | *
- Allow opting out of libcrypt in glibc
- Find packages that require libcrypt.so (through magic?) and make libcrypt optional
- Create global
uesGlibcLibcrypt toggle and bind everything to it
| 20:50:10 |
| K900 | Maybe just rip out libcrypt instead and see what explodes? | 20:50:15 |
| K900 | And replace with libxcrypt as we find it | 20:50:20 |
| K900 | AFAIU libxcrypt should be a drop-in replacement | 20:50:31 |
| hexa | yeah, I think the "finding" part is checking what explodes | 20:50:42 |
| hexa | and fixing it up, ideally with what you just said | 20:51:02 |
| K900 | Yeah I'm mostly not sure about the global toggle bit | 20:51:15 |
| hexa | yeah, I'm not sure we really need it | 20:51:26 |
| hexa | like … packages that are stuck on libcrypt can glibc.override maybe? | 20:51:43 |
| K900 |
On Linux-based systems, by default libxcrypt will be binary backward compatible with the libcrypt.so.1 shipped as part of the GNU C Library. This means that all existing binary executables linked against glibc’s libcrypt should work unmodified with this library’s libcrypt.so.1. We have taken pains to provide exactly the same symbol versions as were used by glibc on various CPU architectures, and to account for the variety of ways in which the Openwall extensions were patched into glibc’s libcrypt by some Linux distributions. (For instance, compatibility symlinks for SUSE’s “libowcrypt” are provided.)
| 20:52:39 |
| K900 | https://github.com/besser82/libxcrypt | 20:52:42 |
| hexa | alrighty | 20:52:51 |
| K900 | They worked really fucking hard to be compatible | 20:52:52 |
| K900 | So I'm hoping there will not be many explosions | 20:53:06 |
| K900 | Or any explosions | 20:53:09 |
| hexa | then the plan gets clearer | 20:53:18 |
| K900 | I'm pretty sure Arch just dropped it in one day and the binary compatibility just ... worked | 20:53:28 |
| hexa | making things go boom and adding libxcrypt it is | 20:53:28 |
| vcunat | Fedora has been using a split libxcrypt for quite some time, so there should at least be patches for the important packages. | 20:58:20 |
| hexa |
programs that use certain legacy APIs supplied by glibc’s libcrypt (encrypt, encrypt_r, setkey, setkey_r, and fcrypt) cannot be compiled against libxcrypt.
| 21:10:41 |
