Broken libscrypt.so symlink

[Tristan Seligmann]

[ Impact ]

libscrypt-dev ships a broken symlink from /usr/lib/libscrypt.so to debian/tmp/usr/lib/libscrypt.so.0. This causes builds linking with -lscrypt to pick up its static library /usr/lib/libscrypt.a instead. This happens silently.

[ Test Case ]

Check if libscrypt-dev's /usr/lib/libscrypt.so symlink points to libscrypt.so.0 instead of debian/tmp/usr/lib/libscrypt.so.0.

[ Regression Potential ]

None. As we see, even if the symlink is broken, the linker falls back to something else.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Logan Rosen (logan)]

This bug was fixed in the package libscrypt - 1.20-1

---------------
libscrypt (1.20-1) experimental; urgency=low

  * ACK NMUs, thanks for the fixes.
  * New upstream release (Closes: #746041).
    - Drop patches from NMUs due to inclusion of equivalent changes upstream.
  * Add myself as co-maintainer.
  * Bump Standards-Version.
  * Add a symbols file.
  * Tweak -dev package description.
  * Update Vcs-* fields.
  * Update copyright file.

 -- Tristan Seligmann <email address hidden> Sun, 14 Dec 2014 05:28:49 +0200

libscrypt (1-2.2) unstable; urgency=medium

  * Non-maintainer upload.
  * Fix FTBFS on big endian architecture.
    Patch by Aurelien Jarno.
    Add big-endian.patch.
    Closes: #728254.

 -- Anibal Monsalve Salazar <email address hidden> Mon, 21 Jul 2014 06:32:03 +0100

libscrypt (1-2.1) unstable; urgency=medium

  * Non-maintainer upload
  * Make symlink relative (Closes: #731174)

 -- David Prévot <email address hidden> Wed, 25 Dec 2013 20:48:11 -0400

[Cory Bloor (slavik81)]

This is still broken in Ubuntu 14.04 (1-2ubuntu2). Was that an oversight?

[Philipp Kern (pkern)]

As it turns out the side-effect of this is that binaries linking against scrypt are picking it up statically because there's a libscrypt.a that works.

[Philipp Kern (pkern)]

Debdiff to fix this in trusty attached.

[Robie Basak (racb)]

This would changing anything that builds now to building against the shared library instead of the static library, right? What are the implications of this? This should really be discussed in Regression Potential.

Second, what's the real world impact of this? Why is there a need to SRU this? What is the impact of this bug to *users* in Trusty?

[Philipp Kern (pkern)]

The implication is that packages built against scrypt on trusty link against it statically. It's a grave Debian policy violation for one, it's a terrible thing for a security-related library for another. If there's any update to the library, other packages don't pick it up. It's also clear that it has been fixed in newer Ubuntu versions since over two years with no reported regression.

That being said, it's clear that for in-distro packages reverse dependencies of libscrypt would need to be recompiled to pick up the dependency. However, they are of course not easy to identify because they never inherited the shlibs dependency in the first place.

Similarly I can make the argument that it does not affect any package in the archive because unless they are recompiled they won't see the updated symlink. In the end it's mostly to help people building their own packages on Ubuntu against libscrypt to do it correct and in the manner you'd expect an Ubuntu system to behave.

[Robie Basak (racb)]

> If there's any update to the library, other packages don't pick it up.

Right, but as you point out, this upload won't fix this.

> In the end it's mostly to help people building their own packages on Ubuntu against libscrypt to do it correct and in the manner you'd expect an Ubuntu system to behave.

That's true, but I'd expect users doing anything *new* to be doing it on 16.04 or on 16.10, where I presume this bug is already fixed? Changing this in 14.04 will change behaviour (as is intended), but this could equally break users relying on particular previous behaviour.

My opinion would be different for 16.04. For 14.04, I'm on the fence, and I'd like a second opinion from another ~ubuntu-sru.

[Robie Basak (racb)]

Please see https://irclogs.ubuntu.com/2017/02/22/%23ubuntu-release.html#t14:35 for some further discussion on this with another ~ubuntu-sru member.

Following that discussion:

1) The problem appears to be theoretical at this point, since libscrypt has never been updated in an existing stable release.

2) Fixing this must necessarily change behaviour (linking will link dynamically instead of statically). Users might shout about this as much as they'd shout about not having the shared library available.

3) This is (presumably) fixed in newer stable Ubuntu releases, including 16.04 LTS.

So I believe the decision is "no" for now, unless one of those things changes. If there is an update in libscrypt, we'd need to find the reverse dependencies and fix them for any update to be useful. Andy points out that looking up reverse dependencies in newer releases where this is fixed will at least give us a first approximation of what needs to be addressed.

I appreciate that this is a marginal decision and welcome further discussion. I'll set the bug status to "Won't Fix" for now, and reject from the queue, but this can change if the situation changes or if a contrary decision is made.