Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others

[Marco d'Itri]

Package: wnpp
Severity: wishlist
Owner: Marco d'Itri <m...@linux.it>

I intend to package the new version of libxcrypt, which will replace the
orphaned libxcrypt source package.

Some day it may replace crypt(3), currently provided by glibc:
https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt

I already have significant experience with crypt(3) thanks to
mkpasswd(1) provided by my whois package.

* Package name : libxcrypt
Version : 4.1.0
Upstream Author : Björn Esser and Zack Weinberg
* URL : https://github.com/besser82/libxcrypt
* License : LGPL
Programming Lang: C
Description : Extended crypt library for DES, MD5, Blowfish and others

--
ciao,
Marco

[Marco d'Itri]

On Jul 18, Marco d'Itri <m...@linux.it> wrote:

> Some day it may replace crypt(3), currently provided by glibc:
> https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt

I tried creating a package which would divert libc's libcrypt, but it
appears to be much harder than I thought.

Installing it would looke like:

1) libcrypt1.preinst diverts glibc's libcrypt.so.1
2) dpkg does things
3) dpkg installs libxcrypt's libcrypt.so.1
4) dpkg does more things
5) libcrypt1.postinst runs/triggers ldconfig

And this means that perl (a libcrypt dependency) would be broken between
1 and 5 (or maybe 1 and 3): is this ever going to work?

But even if this worked correctly, glibc installs a libcrypt-N.NN.so,
whose exact name I expect changes among different releases.

Is there any way to implement all this safely?

--
ciao,
Marco

[Philipp Kern]

Make sure that glibc splits out libcrypt into its own package, have
libc6 depend on it and then provide libcrypt1? (Because it's really
providing libcrypt's ABI from another package.) Versioning might be
tricky, though.

Kind regards
Philipp Kern

[Marco d'Itri]

On Jul 20, Philipp Kern <pk...@debian.org> wrote:

> Make sure that glibc splits out libcrypt into its own package, have libc6
> depend on it and then provide libcrypt1? (Because it's really providing
> libcrypt's ABI from another package.) Versioning might be tricky, though.

At some point glibc will just stop building libcrypt, I am looking for
an interim solution that will not require coordination with the glibc
maintainers.

--
ciao,
Marco

[Marco d'Itri]

On Jul 20, Philipp Kern <pk...@debian.org> wrote:

> I think it's odd to say "here, I'm packaging up a replacement for your
> library, but I'm not going to coordinate with you" when we are preparing
> a (somewhat) coherent distribution, so I don't think that option should
> be discarded. (Unless you have a reasonable worry that you experiment
> will fail and hence don't want to bother people, I guess.)
At this point it is not an experiment anymore since Fedora switched and
removal from glibc is still planned for a future release.
I just wanted to have something usable and working before starting to
discuss a transition plan.

--
ciao,
Marco

[Guillem Jover]

On Fri, 2018-07-20 at 02:18:51 +0200, Marco d'Itri wrote:
> On Jul 18, Marco d'Itri <m...@linux.it> wrote:
> > Some day it may replace crypt(3), currently provided by glibc:
> > https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt

> I tried creating a package which would divert libc's libcrypt, but it
> appears to be much harder than I thought.
>
> Installing it would looke like:
>
> 1) libcrypt1.preinst diverts glibc's libcrypt.so.1
> 2) dpkg does things
> 3) dpkg installs libxcrypt's libcrypt.so.1
> 4) dpkg does more things
> 5) libcrypt1.postinst runs/triggers ldconfig
>
> And this means that perl (a libcrypt dependency) would be broken between
> 1 and 5 (or maybe 1 and 3): is this ever going to work?

Given that this new package is going to replace a part of glibc, it
will need to behave as if it was part of the pseudo-Essential package
set. When it comes to the diversion that means it needs to be added
*without* the rename, so that we always have the libcrypt.so.1 present.

But otherwise why would it be broken?

> But even if this worked correctly, glibc installs a libcrypt-N.NN.so,
> whose exact name I expect changes among different releases.

This one is tied to the major.minor glibc version, so I think you
should just ignore it. I'd expect at most glibc itself to perhaps rely
on it, anything else using it would not be very sane IMO.

Thanks,
Guillem

[Marco d'Itri]

On Jul 20, Guillem Jover <gui...@debian.org> wrote:

> > And this means that perl (a libcrypt dependency) would be broken between
> > 1 and 5 (or maybe 1 and 3): is this ever going to work?
>
> Given that this new package is going to replace a part of glibc, it
> will need to behave as if it was part of the pseudo-Essential package
> set. When it comes to the diversion that means it needs to be added
> *without* the rename, so that we always have the libcrypt.so.1 present.

I am not sure about how this would work: can you point me to an example
package?

> But otherwise why would it be broken?

Because indeed when using dpkg-divert --rename the file would be missing
for some time.

> > But even if this worked correctly, glibc installs a libcrypt-N.NN.so,
> > whose exact name I expect changes among different releases.
> This one is tied to the major.minor glibc version, so I think you
> should just ignore it. I'd expect at most glibc itself to perhaps rely
> on it, anything else using it would not be very sane IMO.

I just feared ldconfig deciding to change the .so.1 symlink, I could not
find any documentation about when it decides to change existing symlinks
and then how it chooses between different versions of the same library.

--
ciao,
Marco

[Michael Stone]

For purely testing purposes you could rely on a local diversion.
(Install as a different library name, divert libcrypt, symlink.) Or you
just build the package with the final names and force the conflicts. But
the usable and working version demands a coordinated libc package.

Mike Stone

[Michael Stone]

Remove libcrypt from glibc first, with a dependency on a libxcrypt that
replaces it. I don't think it's safe to try as a diversion. You could
maybe have fun with symlinks (see the /bin/sh saga) if you wanted to be
able to switch back and forth, but if libcrypt is really leaving glibc
there wouldn't seem to be any point to that.

Mike Stone

[Ben Hutchings]

On Fri, 2018-07-20 at 15:12 +0200, Marco d'Itri wrote:
> On Jul 20, Guillem Jover <gui...@debian.org> wrote:
>
> > > And this means that perl (a libcrypt dependency) would be broken between
> > > 1 and 5 (or maybe 1 and 3): is this ever going to work?
> >
> > Given that this new package is going to replace a part of glibc, it
> > will need to behave as if it was part of the pseudo-Essential package
> > set. When it comes to the diversion that means it needs to be added
> > *without* the rename, so that we always have the libcrypt.so.1 present.
>
> I am not sure about how this would work: can you point me to an example
> package?
>
> > But otherwise why would it be broken?
>
> Because indeed when using dpkg-divert --rename the file would be missing
> for some time.

[...]

I think you can do something like:

# build time: install libraries in a subdirectory to avoid conflict
make install libdir=/lib/$DEB_HOST_MULTIARCH/libxcrypt1

# postinst time: use link & rename to replace working version atomically.
# $DEB_HOST_MULTIARCH actually needs to be substituted at build time.
for src in /lib/$DEB_HOST_MULTIARCH/libxcrypto/libcrypt.so.*; do
dst=/lib/$DEB_HOST_MULTIARCH/$(basename $src)
dpkg-divert --package libxcrypt1 --add --divert $dst $dst.glibc
ln $dst $dst.glibc
ln $src $dst.xcrypto
mv $dst.xcrypto $dst
done

# prerm time: just rename
for src in /lib/$DEB_HOST_MULTIARCH/libxcrypto/libcrypt.so.*; do
dst=/lib/$DEB_HOST_MULTIARCH/$(basename $src)
dpkg-divert --package libxcrypt1 --remove --divert $dst $dst.glibc
mv $dst.glibc $dst
done

Ben.

--
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.

[Michael Stone]

On Sat, Jul 21, 2018 at 02:35:59AM +0100, Ben Hutchings wrote:
>I think you can do something like:

[...]

># postinst time: use link & rename to replace working version atomically.

It's technically possible, but AFAICT a policy violation.

Mike Stone