Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 686478 - sys-libs/libxcrypt: horribly outdated version
Summary: sys-libs/libxcrypt: horribly outdated version
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: The Gentoo Linux Hardened Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-21 16:45 UTC by Michał Górny
Modified: 2019-11-08 19:37 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-05-21 16:45:03 UTC
From #gentoo-security:

<dkonn> hi! I would like to bring to your attention a deficiency in gentoo's pam/libc passwd configuration. it's been SIX years since sys-libs/libxcrypt saw an update which provides blowfish hashing to passwd, which implies usage of sha2, which does not support multi-round hashing until recently
<dkonn> or md5 for those who fail to change their own passwords


FWICS, the current upstream is https://github.com/besser82/libxcrypt

The only revdep right now is app-emulation/libguestfs.  Apparently the PAM support was disabled but it might be worthwhile to reenable it after the bump.

Alternatively, if you're not interested in bumping it, we should probably lastrite it.
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-08-29 10:31:49 UTC
So I've finally looked into bumping this... and it turns out upstream decided to go for making it 'drop-in' replacement for -lcrypt.  This means that it installs libcrypt.so*, crypt.h and manpages that collide with glibc and eclass-manpages.  The old names (libxcrypt, xcrypt.h) can be optionally installed as backwards compatibility files but the new files are unconditional.

@base-system, do you have any suggestion how to deal with it?  Or should we just forget about libxcrypt and kill it with fire?
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-08-29 10:37:52 UTC
(sorry, wrong CC)
Comment 3 Sergei Trofimovich (RETIRED) gentoo-dev 2019-08-29 18:41:29 UTC
The vague upstream plan is to get libcrypt off glibc at some point:
    https://sourceware.org/ml/libc-alpha/2017-08/msg01257.html
libxcrypt is a proposed substitute for packages that still need that API.

Once/if that happens it would make sense to pull in external implementation. I guess the upstream timeline is "not too soon".

Until then libxcrypt's libcrypt.so is suspected of being binary-incompatible with glibc libcrypt.so:
    https://sourceware.org/ml/libc-alpha/2017-08/msg01257.html
Thus will require a bit of work to get it usable in place of glibc's libcrypt (at least as an upgrade path for existing users). Maybe we can live with some breakage.

I'd prefer gentoo not to carry downstream patches to disable glibc's implementation of libcrypt and would wait for upstream's action first.

Up to maintainer what to do with the sys-libs/libxcrypt in the mean time.
Comment 4 Michael 'veremitz' Everitt 2019-08-30 20:13:38 UTC
libguestfs has a set of useful utilities for manipulating VM images, eg. qcow2, etc and adjusting size, partition layout, etc. http://libguestfs.org/ .

It would be unfortunate to lose this tool if libxcrypt has to be last-rited.
Comment 5 Magnus Granberg gentoo-dev 2019-11-03 16:03:55 UTC
There is no way to make it work without patching hell out of it.
So for may part is to last-rited it.
Comment 6 Magnus Granberg gentoo-dev 2019-11-03 20:56:16 UTC
libguestfs have a dep on it. mainteners can that package run without libxcrypt?
Comment 7 Michael 'veremitz' Everitt 2019-11-03 21:02:11 UTC
RE: libguestfs - I wonder if we could add a test for ELIBC != glibc for now, as other libcs without libcrypt baked-in still need libxcrypt. That is, IF it compiles and runs happily as proposed ..

Attempting a build here, will report back.
Comment 8 Sergei Trofimovich (RETIRED) gentoo-dev 2019-11-03 21:43:06 UTC
(In reply to Magnus Granberg from comment #6)
> libguestfs have a dep on it. mainteners can that package run without
> libxcrypt?

Yes, ./configure detects both -lxcrypt and -lcrypt.
Comment 9 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-11-03 21:44:56 UTC
One possible hack would be to install it somewhere isolated, e.g. in /usr/lib*/xcrypt/ and use -L whenever we want to link it instead of regular -lcrypt.
Comment 10 Patrick McLean gentoo-dev 2019-11-04 05:38:04 UTC
I am going to take a look at updating this and patching it to install to the "old" location later this week.
Comment 11 Larry the Git Cow gentoo-dev 2019-11-05 02:53:15 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8efc5d79172a5337ec56ddcff487a277dbf88886

commit 8efc5d79172a5337ec56ddcff487a277dbf88886
Author:     Patrick McLean <patrick.mclean@sony.com>
AuthorDate: 2019-11-05 02:52:19 +0000
Commit:     Patrick McLean <chutzpah@gentoo.org>
CommitDate: 2019-11-05 02:52:59 +0000

    sys-libs/libxcrypt: Version bump to 4.4.10 (bug #686478)
    
    This installs to an alternate `xcrypt` subdirectory as suggested by
    Michał Górny at https://bugs.gentoo.org/686478#c9 to avoid the issues
    mentioned at https://bugs.gentoo.org/686478#c1
    
    Since this installs a pkgconfig, any reverse dependency using pkgconfig
    should pick up the path change automatically. Otherwise they will have
    to be updated.
    
    Closes: https://bugs.gentoo.org/686478
    Copyright: Sony Interactive Entertainment Inc.
    Package-Manager: Portage-2.3.78, Repoman-2.3.17
    Signed-off-by: Patrick McLean <chutzpah@gentoo.org>

 sys-libs/libxcrypt/Manifest                        |  1 +
 .../files/libxcrypt-4.4.10-pythonver.patch         | 17 +++++++
 sys-libs/libxcrypt/libxcrypt-4.4.10.ebuild         | 57 ++++++++++++++++++++++
 sys-libs/libxcrypt/metadata.xml                    | 21 ++++----
 4 files changed, 87 insertions(+), 9 deletions(-)
Comment 12 Patrick McLean gentoo-dev 2019-11-05 05:37:38 UTC
Since libxcrypt installs libcrypt.so.2 and glibc installs libcrypt.so.1, it's theoretically possible to make them co-exist in the system libdir. It's a bit nicer than putting them in libdir/xcrypt.

The problem is that you might end up with a bunch of automagic dependencies, and uninstalling libxcrypt would hose your system.