Title: migrating from glibc[crypt] to libxcrypt in stable
Author: Andreas K. Hüttel <dilfridge@gentoo.org>
Author: Sam James <sam@gentoo.org>
Posted: 2021-10-18
Revision: 1
News-Item-Format: 2.0

The implementation of libcrypt.so within glibc has been deprecated
for a long time and will be removed in the near future.

For this reason, we are following other distributions (where
this has been tested for years already) and switching to the 
external libxcrypt implementation, now also in stable installations.

This will be a regular update, and in nearly all cases you
will not have to take any action and not observe any problems.

We do recommend, however, that your system is *fully* up
to date first. This is a standard recommendation but in this
specific case, it is useful to have a simplified depgraph
to ensure that Portage is able to smoothly calculate
an upgrade path.

We also recommend being in a root shell (not via 'sudo'
or similar tools) so that if any issues occur during the upgrade,
you are not locked out of the console. It is not expected
that any such issues will occur but this is a precaution.

It is also recommended that users do _not_ have
FEATURES="collision-protect" enabled because it is
aggressive in protecting even orphaned files. Instead,
use FEATURES="unmerge-orphans" which is almost identical
in behaviour.

That is, please take the opportunity to fully upgrade your
systems now, before the migration occurs, to simplify matters.

This change will occur on 2021-11-01 for stable users.
~arch users by default should already have switched.

If for whatever reason you do *not* wish to switch now -
which is only delaying the inevitable - you
need to take the following steps:
* unmask and enable the crypt USE flag of sys-libs/glibc
* mask the system USE flag of sys-libs/libxcrypt
* mask >=virtual/libcrypt-2
* unmask virtual/libcrypt:0/1

If you wish to manually migrate now, there are a series
of steps described on the wiki (see below), but the outline is:
* unforce the crypt USE flag of sys-libs/glibc and disable it
* unmask the system and split-usr (if applicable) USE flag of sys-libs/libxcrypt
and enable it
* unmask ~virtual/libcrypt-2

Please note that if you last changed your password before ~2008,
it may be using md5crypt or similar other weak mechanisms in /etc/shadow;
a bug in PAM [0][1] may mean that you were unable to login. We recommend
using "passwd" to change/refresh your password so it is using modern
methods. A new version of PAM has been added to the tree to resolve this issue.

In some cases, Portage may schedule a rebuild of certain packages in an
incorrect order [2]. If building a package fails, please try upgrading
Python itself to help avoid spurious build failures, and then
libcrypt and libxcrypt first:

# emerge -v1 --ignore-built-slot-operator-deps=y dev-lang/python:3.8 dev-lang/python:3.9
# emerge -v1 virtual/libcrypt sys-libs/libxcrypt

And then continue the world upgrade with Portage's "--keep-going=y".

If you hit conflicts, please see the wiki page linked below, but
common helpful tips are:
* try more backtracking (e.g. --backtrack=1000)
* try --ignore-built-slot-operator-deps=y temporarily on the world upgrade,
then run a world upgrade again without it.

Do NOT attempt to unmerge glibc at any point.

For more information or troubleshooting tips, please see:
* https://wiki.gentoo.org/wiki/Project:Toolchain/libcrypt_implementation
* https://bugs.gentoo.org/699422
* Reach out to our support channels (https://www.gentoo.org/support/)

[0] https://bugs.gentoo.org/802267
[1] https://bugs.gentoo.org/802807
[2] https://bugs.gentoo.org/802210