Discussion:
Bug#941853: crypt(3) should be provided by libxcrypt
Add Reply
Marco d'Itri
2019-10-06 16:00:01 UTC
Reply
Permalink
Package: glibc
Version: 2.29-2
Severity: normal

The libc implementation of crypt(3) has been deprecated since 2.28.
libxcrypt is needed to support modern hashing algorithms.

How do you want to coordinate switching to libxcrypt?

The libxcrypt implementation is source and binary backward compatible,
so no transitions are needed. I think that we only need to coordinate
Replaces/Depends.

The libxcrypt package lives in https://salsa.debian.org/md/libxcrypt .

It has been in Fedora since over one year:
https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
--
ciao,
Marco
Marco d'Itri
2019-10-06 20:20:02 UTC
Reply
Permalink
The libxcrypt implementation is indeed source backward compatible,
however doesn't seem binary backward compatible. libc6 provides
libcrypt.so.1 while libxcrypt provides libcrypt.so.2.
It provides both, but currently I am not even building libcrypt.so.2
since I do not see the point.

***@bongo:/USR3/src/P/libxcrypt$ dpkg-deb -c libcrypt1_4.4.8-1_amd64.deb
drwxr-xr-x root/root 0 2019-09-01 22:04 ./
drwxr-xr-x root/root 0 2019-09-01 22:04 ./lib/
drwxr-xr-x root/root 0 2019-09-01 22:04 ./lib/x86_64-linux-gnu/
-rw-r--r-- root/root 202680 2019-09-01 22:04 ./lib/x86_64-linux-gnu/libcrypt.so.1.1.0
drwxr-xr-x root/root 0 2019-09-01 22:04 ./usr/
drwxr-xr-x root/root 0 2019-09-01 22:04 ./usr/share/
drwxr-xr-x root/root 0 2019-09-01 22:04 ./usr/share/doc/
drwxr-xr-x root/root 0 2019-09-01 22:04 ./usr/share/doc/libcrypt1/
-rw-r--r-- root/root 6476 2019-09-01 21:03 ./usr/share/doc/libcrypt1/NEWS.gz
-rw-r--r-- root/root 4052 2019-03-06 00:02 ./usr/share/doc/libcrypt1/README.md.gz
-rw-r--r-- root/root 799 2019-09-01 22:04 ./usr/share/doc/libcrypt1/changelog.Debian.gz
-rw-r--r-- root/root 5628 2019-09-01 22:04 ./usr/share/doc/libcrypt1/copyright
lrwxrwxrwx root/root 0 2019-09-01 22:04 ./lib/x86_64-linux-gnu/libcrypt.so.1 -> libcrypt.so.1.1.0
lrwxrwxrwx root/root 0 2019-09-01 22:04 ./usr/share/doc/libcrypt1/TODO -> TODO.md

So I think that libc6 should have Depends/Replaces on libcrypt1.

I suggest that we make a pass in experimental to be sure to not leave
unstable uninstallable for days.
--
ciao,
Marco
Aurelien Jarno
2019-10-06 20:40:01 UTC
Reply
Permalink
Hi,
Post by Marco d'Itri
Package: glibc
Version: 2.29-2
Severity: normal
The libc implementation of crypt(3) has been deprecated since 2.28.
libxcrypt is needed to support modern hashing algorithms.
How do you want to coordinate switching to libxcrypt?
The libxcrypt implementation is source and binary backward compatible,
so no transitions are needed. I think that we only need to coordinate
Replaces/Depends.
The libxcrypt implementation is indeed source backward compatible,
however doesn't seem binary backward compatible. libc6 provides
libcrypt.so.1 while libxcrypt provides libcrypt.so.2.

It is therefore not possible to build glibc with --disable-crypt. I
guess what we can do is to remove crypt.h, libcrypt.a and libcrypt.so
from libc6-dev and add a depends on libcrypt2-dev to libc6-dev. On its
side, libcrypt2-dev should break and replace libc6-dev with the right
version.

There should be no need to add a depends from libc6 to libcrypt2 as the
two libraries have a different soname and thus are co-installable.

If that sounds ok, I guess we can do that in the next glibc upload.

Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
***@aurel32.net http://www.aurel32.net
Aurelien Jarno
2019-10-06 22:20:01 UTC
Reply
Permalink
Ah this doesn't match the version in unstable, it's only in NEW for now.
I guess we need to wait for it to get out of there first.
For reasons which I do not understand, the ftpmasters obliquely let me
know that they will not accept libxcrypt from NEW until the libc
maintainers will explicitly confirm that we have agreed on a plan to use
it. Do you mind confirming this?
AFAIK, the glibc team have never been asked about that.

For the ftpmasters: I confirm we'll replace libcrypt.so.1 from libc6 by
the one from libxcrypt. Therefore please accept the package.
Post by Marco d'Itri
So I think that libc6 should have Depends/Replaces on libcrypt1.
Agreed for the Depends. I don't get why it needs a Replaces. On the
other hand libcrypt1 needs a Replaces: libc6, libc6.1, libc0.1, libc0.3
with the correct version.
Package: libcrypt1
Breaks: libc6 (<< 2.29-X)
Replaces: libc6 (<< 2.29-X)
Package: libcrypt1-dev
Breaks: libc6-dev (<< 2.29-X)
Replaces: libc6-dev (<< 2.29-X)
Package: libc6
Depends: libcrypt1
Package: libc6-dev
Depends: libcrypt1-dev
And all the architecture-specific variations which I will figure out.
This is libc0.1, libc0.3, libc6 and libc6.1 for the library package.
This is libc0.1-dev, libc0.3-dev, libc6-dev and libc6.1-dev for the
library packages.

I guess we should keep building libcrypt1 for the bi/tri-arch packages.
(Also, do not forget about the man pages in the -dev packages.)
The man page was not provided by the -dev package but by manpages-dev.
There is also a libcrypt1 udeb: do you prefer to start building it now
or deal with it later?
We must build the libcrypt1 udeb, and add a depends from libc6-deb to
libcrypt1-udeb, otherwise we might break d-i. At some point we might
want to rebuild all udebs (at least by hand to detect the affected
udebs) and drop that dependency.

Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
***@aurel32.net http://www.aurel32.net
Aurelien Jarno
2019-10-07 12:30:01 UTC
Reply
Permalink
Dear debian-boot: for the benefit of the ftpmasters, please confirm that
you have no objections to src:libxcrypt generating a libcrypt1-udeb
package (initially in experimental) which will provide crypt(3)
currently in the libc udeb.
Post by Aurelien Jarno
I guess we should keep building libcrypt1 for the bi/tri-arch packages.
What do I need to do about this?
There are two options:
- We continue to build libcrypt1 from the glibc package for the
bi/tri-arch packages.
- src:libxcrypt starts to build lib32crypt1, lib64-crypt1, libn32crypt1
and libx32crypt1, using gcc-multilib.

Note that the second option can be implemented in a second step.

Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
***@aurel32.net http://www.aurel32.net
Aurelien Jarno
2019-10-09 19:30:01 UTC
Reply
Permalink
Post by Aurelien Jarno
Dear debian-boot: for the benefit of the ftpmasters, please confirm that
you have no objections to src:libxcrypt generating a libcrypt1-udeb
package (initially in experimental) which will provide crypt(3)
currently in the libc udeb.
Post by Aurelien Jarno
I guess we should keep building libcrypt1 for the bi/tri-arch packages.
What do I need to do about this?
- We continue to build libcrypt1 from the glibc package for the
bi/tri-arch packages.
- src:libxcrypt starts to build lib32crypt1, lib64-crypt1, libn32crypt1
and libx32crypt1, using gcc-multilib.
Note that the second option can be implemented in a second step.
I have implemented the first option in the libxcrypt branch:

https://salsa.debian.org/glibc-team/glibc/tree/libxcrypt
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
***@aurel32.net http://www.aurel32.net
Marco d'Itri
2019-10-09 23:40:02 UTC
Reply
Permalink
Post by Aurelien Jarno
https://salsa.debian.org/glibc-team/glibc/tree/libxcrypt
And here you can see a tentative libxcrypt package: does it look right
to you?

https://salsa.debian.org/md/libxcrypt/blob/master/debian/control

├── libcrypt1
│   ├── DEBIAN
│   │   ├── control
│   │   ├── md5sums
│   │   ├── shlibs
│   │   ├── symbols
│   │   └── triggers
│   └── usr
│   ├── lib
│   │   └── x86_64-linux-gnu
│   │   ├── libcrypt.so.1 -> libcrypt.so.1.1.0
│   │   └── libcrypt.so.1.1.0
│   └── share
│   └── doc
│   └── libcrypt1
│   ├── changelog.Debian.gz
│   ├── changelog.gz
│   └── copyright

├── libcrypt1-dev
│   ├── DEBIAN
│   │   ├── control
│   │   └── md5sums
│   └── usr
│   ├── include
│   │   └── crypt.h
│   ├── lib
│   │   └── x86_64-linux-gnu
│   │   ├── libcrypt.a
│   │   ├── libcrypt.so -> libcrypt.so.1.1.0
│   │   └── pkgconfig
│   │   ├── libcrypt.pc -> libxcrypt.pc
│   │   └── libxcrypt.pc
│   └── share
│   ├── doc
│   │   ├── libcrypt1
│   │   │   ├── README.md.gz
│   │   │   └── TODO.md.gz
│   │   └── libcrypt1-dev -> libcrypt1
│   └── man
│   ├── man3
│   │   ├── crypt.3.gz
│   │   ├── crypt_checksalt.3.gz
│   │   ├── crypt_gensalt.3.gz
│   │   ├── crypt_gensalt_ra.3.gz -> crypt_gensalt.3.gz
│   │   ├── crypt_gensalt_rn.3.gz -> crypt_gensalt.3.gz
│   │   ├── crypt_preferred_method.3.gz
│   │   ├── crypt_r.3.gz -> crypt.3.gz
│   │   ├── crypt_ra.3.gz -> crypt.3.gz
│   │   └── crypt_rn.3.gz -> crypt.3.gz
│   └── man5
│   └── crypt.5.gz

├── libcrypt1-udeb
│   ├── DEBIAN
│   │   └── control
│   └── usr
│   └── lib
│   ├── libcrypt.so.1 -> libcrypt.so.1.1.0
│   └── libcrypt.so.1.1.0
--
ciao,
Marco
Loading...