Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 699422 (libxcrypt-migration) - sys-libs/glibc: switch to libxcrypt as libcrypt.so.1 (or .so.2) provider
Summary: sys-libs/glibc: switch to libxcrypt as libcrypt.so.1 (or .so.2) provider
Status: RESOLVED FIXED
Alias: libxcrypt-migration
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Gentoo Toolchain Maintainers
URL: https://wiki.gentoo.org/wiki/Project:...
Whiteboard: Migration pushed to tree in ~arch
Keywords: PullRequest
Depends on: 798963 802210 824926 749933 796722 798468 799131 799707 801403 802207 802222 802267 802648 802807 804085 805347 821496 822849
Blocks:
  Show dependency tree
 
Reported: 2019-11-06 07:27 UTC by Sergei Trofimovich (RETIRED)
Modified: 2022-09-10 11:28 UTC (History)
10 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 Sergei Trofimovich (RETIRED) gentoo-dev 2019-11-06 07:27:16 UTC
glibc-2.28 allows you to disable libcrypt.so.1 and it's header:

* We have tentative plans to hand off maintenance of the passphrase-hashing
  library, libcrypt, to a separate development project that will, we hope,
  keep up better with new passphrase-hashing algorithms.  We will continue
  to declare 'crypt' in <unistd.h>, and programs that use 'crypt' or
  'crypt_r' should not need to change at all; however, distributions will
  need to install <crypt.h> and libcrypt from a separate project.

  In this release, if the configure option --disable-crypt is used, glibc
  will not install <crypt.h> or libcrypt, making room for the separate
  project's versions of these files.  The plan is to make this the default
  behavior in a future release.

https://github.com/besser82/libxcrypt provides a substitute in various forms (ABI compatible and not compatible).

We need to come up with a transition plan to keep user's systems working while moving to a new library.
Comment 1 Patrick McLean gentoo-dev 2019-11-06 07:35:04 UTC
A package.use.force-ed "crypt" USE flag could be useful in testing transition plans, and hopefully come up with one that breaks the least things.

We could also do some tinderbox runs with it turned off to find packages that would need their dependencies updated.
Comment 2 Sergei Trofimovich (RETIRED) gentoo-dev 2019-11-06 07:42:45 UTC
A few immediate requirements I see are:
1. /lib64/libcrypt.so.1 (amd64) should be provided either by glibc or by libxcrypt
2. have a dependency story: what should clients depend on? Some options are:
  - depend on glibc (glibc has an RDEPEND). rebuild information will not be propagated if/when libxcrpt changes ABI
  - depend on libxcrypt explicitly
  - depend on a virtual. virtual will need to provide ABI information
3. transition of ownership from glibc to libxcrypt must not break running applications. that can be done either by keeping libcrypt.so.1 in glibc for a while or by installing libcrypt.so.1 from libxcrypt
4. other libcs will need a story around symbol ownership: for example musl provides crypt() as part of libc.so. I'm not sure it there is a way to disable it.
Comment 3 Sergei Trofimovich (RETIRED) gentoo-dev 2019-11-06 20:06:46 UTC
5. There needs to be clear expectation of (in)compatibility switching libcrypt.so.1 across providers: are they 1:1 compatible or not. AFAIU the current state is that libxcrypt is a superset of glibc.
Comment 4 Larry the Git Cow gentoo-dev 2019-11-06 20:10:42 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=95fbc62a625a8025f3317e6ddd3b5c431a0968c8

commit 95fbc62a625a8025f3317e6ddd3b5c431a0968c8
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2019-11-06 20:10:23 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2019-11-06 20:10:36 +0000

    sys-libs/glibc: introduce USE=+crypt
    
    Today libcrypt.so.1 is provided by glibc. Eventually glibc will
    stop providing it in favoud of external providers like libcrypt.
    
    USE=crypt exposes a knob to disable libcrypt.so.1 installation.
    Use at your own risk. There currently is no replacement yet in
    Gentoo.
    
    Bug: https://bugs.gentoo.org/699422
    Package-Manager: Portage-2.3.78, Repoman-2.3.17
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

 sys-libs/glibc/glibc-2.30-r2.ebuild | 3 ++-
 sys-libs/glibc/metadata.xml         | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

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

commit dd4520d0493793c95dcfd23d0c10adc2cbc4b79a
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2019-11-06 20:07:01 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2019-11-06 20:10:35 +0000

    profiles/base/package.use.force: use.force glibc[crypt]
    
    This will allow dropping bundled crypt by early adopters.
    
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

 profiles/base/package.use.force | 7 +++++++
 1 file changed, 7 insertions(+)
Comment 5 Michael 'veremitz' Everitt 2019-11-08 22:44:25 UTC
As regards to musl, I wrote to the mailing-list, and this was the reply: https://www.openwall.com/lists/musl/2019/11/08/10 . Somewhat out of my depth here, if someone wants to pick up the baton .. ;)
Comment 6 Sergei Trofimovich (RETIRED) gentoo-dev 2020-02-07 08:33:38 UTC
Practically toolchain@ does not drive the transition.

None of the questions of #comment3 / #comment4 were answered here or in https://archives.gentoo.org/gentoo-dev/message/94a9934d91472fcc48f54ee1084cab1e. 

It makes it very hard for me to reason about interaction of libxcrypt with glibc or other libcs.

Closing as OBSOLETE for toolchain@.
Comment 7 Andreas K. Hüttel archtester gentoo-dev 2020-04-23 21:07:56 UTC
> None of the questions of #comment3 / #comment4 were answered here or in
> https://archives.gentoo.org/gentoo-dev/message/
> 94a9934d91472fcc48f54ee1084cab1e. 

I'll have a look and prepare. Feel free to refer questions to me.
Comment 8 Andreas K. Hüttel archtester gentoo-dev 2021-01-01 16:41:14 UTC
OK trying to summarize the current state here:

> 1. /lib64/libcrypt.so.1 (amd64) should be provided either by glibc or by
> libxcrypt

It is provided by sys-libs/glibc[crypt] and by sys-libs/libxcrypt[compat]

I suspect libxcrypt installs into /usr/lib64 though.

> 2. have a dependency story: what should clients depend on? Some options are:
>   - depend on glibc (glibc has an RDEPEND). rebuild information will not be
> propagated if/when libxcrpt changes ABI
>   - depend on libxcrypt explicitly
>   - depend on a virtual. virtual will need to provide ABI information

Currently we have a virtual virtual/libcrypt

Slot 1: 
Installs libcrypt.so.1 and corresponding headers via glibc

Slot 2:
Installs libcrypt.so.2 and corresponding headers via libxcrypt
Makes no statement whether libcrypt.so.1 is installed, but it cannot be provided by glibc, only by libxcrypt.
(The virtual requests libxcrypt[system], which requires glibc[-crypt]. [system] controls where the library header files go, directly into include or in a subdir.)

> 3. transition of ownership from glibc to libxcrypt must not break running
> applications. that can be done either by keeping libcrypt.so.1 in glibc for
> a while or by installing libcrypt.so.1 from libxcrypt

This can be achieved via enabling the compat useflag of libxcrypt (which installs libcrypt.so.1). 

Now the precise transition process (emerge rebuild sequence) is a more interesting question. If preserved-libs works, that should be no problem though.

> 4. other libcs will need a story around symbol ownership: for example musl
> provides crypt() as part of libc.so. I'm not sure it there is a way to
> disable it.

The reply from musl upstream linked in comment #5: We dont care. Feel free to load libxcrypt and that way shadow our internal implementation.

> 5. There needs to be clear expectation of (in)compatibility switching
> libcrypt.so.1 across providers: are they 1:1 compatible or not. AFAIU the
> current state is that libxcrypt is a superset of glibc.

Correct. Current state:

* Binaries built against glibc[crypt] should work just fine with libxcrypt[compat].
* Binaries built against libxcrypt will link against libcrypt.so.2

This means switching back from libxcrypt to glibc is only possible via preserved-libs etc. 

==

@chutzpah: could you please proofread this whether I summarized it correctly?
Comment 9 Patrick McLean gentoo-dev 2021-01-04 19:17:33 UTC
(In reply to Andreas K. Hüttel from comment #8)
> OK trying to summarize the current state here:
> 
> > 1. /lib64/libcrypt.so.1 (amd64) should be provided either by glibc or by
> > libxcrypt
> 
> It is provided by sys-libs/glibc[crypt] and by sys-libs/libxcrypt[compat]
> 
> I suspect libxcrypt installs into /usr/lib64 though.

sys-libs/libxcrypt[compat] installs 
libcrypt.so.1 to /lib64 (along with libcrypt.so.2)

> > 2. have a dependency story: what should clients depend on? Some options are:
> >   - depend on glibc (glibc has an RDEPEND). rebuild information will not be
> > propagated if/when libxcrpt changes ABI
> >   - depend on libxcrypt explicitly
> >   - depend on a virtual. virtual will need to provide ABI information
> 
> Currently we have a virtual virtual/libcrypt
> 
> Slot 1: 
> Installs libcrypt.so.1 and corresponding headers via glibc
> 
> Slot 2:
> Installs libcrypt.so.2 and corresponding headers via libxcrypt
> Makes no statement whether libcrypt.so.1 is installed, but it cannot be
> provided by glibc, only by libxcrypt.
> (The virtual requests libxcrypt[system], which requires glibc[-crypt].
> [system] controls where the library header files go, directly into include
> or in a subdir.)
> 
> > 3. transition of ownership from glibc to libxcrypt must not break running
> > applications. that can be done either by keeping libcrypt.so.1 in glibc for
> > a while or by installing libcrypt.so.1 from libxcrypt
> 
> This can be achieved via enabling the compat useflag of libxcrypt (which
> installs libcrypt.so.1). 

Just to note here, the compat useflag of libxcrypt is on by default.

> 
> Now the precise transition process (emerge rebuild sequence) is a more
> interesting question. If preserved-libs works, that should be no problem
> though.

preserved-libs does detect libcrypt.so.1 and preserve it if necessary, though as I note above the compat useflag on libxcrypt is on by default, so it will install libcrypt.so.1.

> > 4. other libcs will need a story around symbol ownership: for example musl
> > provides crypt() as part of libc.so. I'm not sure it there is a way to
> > disable it.

virtual/libcrypt:2 currently won't pull in libxcrypt on musl systems (and uclibc systems).

> The reply from musl upstream linked in comment #5: We dont care. Feel free
> to load libxcrypt and that way shadow our internal implementation.
> 
> > 5. There needs to be clear expectation of (in)compatibility switching
> > libcrypt.so.1 across providers: are they 1:1 compatible or not. AFAIU the
> > current state is that libxcrypt is a superset of glibc.
> 
> Correct. Current state:
> 
> * Binaries built against glibc[crypt] should work just fine with
> libxcrypt[compat].
> * Binaries built against libxcrypt will link against libcrypt.so.2
> 
> This means switching back from libxcrypt to glibc is only possible via
> preserved-libs etc. 
> 
> ==
> 
> @chutzpah: could you please proofread this whether I summarized it correctly?

I noted a couple of clarifications and corrections above.
Comment 10 Larry the Git Cow gentoo-dev 2021-06-17 05:03:44 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4e2b8599caede5cdcb747d7505ffae04144d7efe

commit 4e2b8599caede5cdcb747d7505ffae04144d7efe
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-06-17 04:23:18 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-06-17 05:03:17 +0000

    sys-libs/libxcrypt: assign to toolchain@
    
    Switch to toolchain@ as maintainer given this is soon(?) going
    to replace a core part of glibc (libcrypt).
    
    hardened@ is a quiet, less-well-defined project which makes it
    less suitable for an important package.
    
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Sam James <sam@gentoo.org>

 sys-libs/libxcrypt/metadata.xml | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)
Comment 11 Larry the Git Cow gentoo-dev 2021-06-18 22:51:01 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=929025d74438f10d7b9d9f79d2002a953eb89aba

commit 929025d74438f10d7b9d9f79d2002a953eb89aba
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-06-18 22:47:31 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-06-18 22:50:12 +0000

    profiles: add note to libxcrypt mask(s) to treat with care for non-glibc
    
    We'll need to keep the masks for non-glibc (musl, uclibc{,-ng}, ...) so
    make a note of it to prevent an issue down the line.
    
    Reported-by: Arfrever Frehtes Taifersar Arahesis <arfrever.fta@gmail.com>
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Sam James <sam@gentoo.org>

 profiles/base/package.use.force | 4 ++--
 profiles/base/package.use.mask  | 1 +
 profiles/package.mask           | 1 +
 3 files changed, 4 insertions(+), 2 deletions(-)
Comment 12 Larry the Git Cow gentoo-dev 2021-06-24 22:02:01 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0aba872326b1a2fd8fab415959bf1759f2b0a635

commit 0aba872326b1a2fd8fab415959bf1759f2b0a635
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-06-24 22:01:26 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-06-24 22:01:35 +0000

    virtual/libcrypt: destabilize 2
    
    Needed to avoid accidents when we do the unmasking in the future.
    
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Sam James <sam@gentoo.org>

 virtual/libcrypt/libcrypt-2.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Comment 13 Larry the Git Cow gentoo-dev 2021-06-26 23:09:37 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4cc70444a0077f9b807593ab322d05a6b3737666

commit 4cc70444a0077f9b807593ab322d05a6b3737666
Author:     Georgy Yakovlev <gyakovlev@gentoo.org>
AuthorDate: 2021-06-25 05:24:12 +0000
Commit:     Georgy Yakovlev <gyakovlev@gentoo.org>
CommitDate: 2021-06-26 23:08:22 +0000

    metadata/install-qa-check.d: add virtual/libcrypt dep check
    
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org>

 metadata/install-qa-check.d/60libcrypt-deps | 38 +++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)
Comment 14 Larry the Git Cow gentoo-dev 2021-06-28 01:31:52 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6aeaf45b893a4047095067fcfc0e52f5f50afb32

commit 6aeaf45b893a4047095067fcfc0e52f5f50afb32
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-06-28 01:30:00 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-06-28 01:31:43 +0000

    profiles: change virtual/libcrypt mask to ~ prefix
    
    This is needed to ensure users don't have obsolete >= unmasks
    in their configurations which might, in future, be used
    for other purposes (like disabling compatibility mode, even if
    that's indefinitely masked).
    
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Sam James <sam@gentoo.org>

 profiles/package.mask | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Comment 15 Michael 'veremitz' Everitt 2021-06-28 18:29:00 UTC
ago,

might I suggest instead of blocking this bug with a load of spam entries from your testing system, that perhaps you use the Tracker bug 798963 .

Thank you
Comment 16 Agostino Sarubbo gentoo-dev 2021-06-28 18:35:45 UTC
(In reply to Michael 'veremitz' Everitt from comment #15)
> ago,
> 
> might I suggest instead of blocking this bug with a load of spam entries
> from your testing system, that perhaps you use the Tracker bug 798963 .
> 
> Thank you

Bugs were filed before read irc messages were I was advised.
Comment 17 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-07-01 00:02:48 UTC
News item posted: https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=204d52b41581306d7fa30dd0634c581b18b8eedc.

Migration slated for 14th July.
Comment 18 Larry the Git Cow gentoo-dev 2021-07-02 02:30:12 UTC
The bug has been referenced in the following commit(s):

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

commit e165e102e112609de700e78b2fb6d4145ab4a6fe
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-07-01 04:08:32 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-07-02 02:27:00 +0000

    sys-libs/libxcrypt: switch to pre-generated autotools tarballs
    
    There are actually *two* circular dependencies involving Perl:
    
    1) Use self-generated (for now) `make dist` tarballs to avoid a circular
       dependency with libxcrypt->automake->perl->libxcrypt.
    
       (Thanks juippis and floppym! We noticed this because juippis hit an
       interesting edge case when using binpkgs.)
    
    2) We initially tried to pre-generate the results of a Perl tool called
       during `./configure` in order to avoid unconditionally needing
       Perl.
    
       (I thought we could do this because the input is constant for all of the
       Gentoo build variants - for now.
    
       I later realised there's other Perl usage which we're stuck with
       for now without pre-generating a *lot*.)
    
       (Thanks mattst88! We noticed this while digging into suggestions
       for upstream.)
    
    So, for now, we're just fixing 1), and adding a BDEPEND on Perl for 2) to
    make it explicit.
    
    (Both best explained within the comments of the ebuild.)
    
    Bug: https://bugs.gentoo.org/699422
    Closes: https://github.com/gentoo/gentoo/pull/21493
    Reported-by: Joonas Niilola <juippis@gentoo.org>
    Reported-by: Mike Gilbert <floppym@gentoo.org>
    Reported-by: Matt Turner <mattst88@gentoo.org>
    Signed-off-by: Sam James <sam@gentoo.org>

 sys-libs/libxcrypt/Manifest                |  4 +-
 sys-libs/libxcrypt/libxcrypt-4.4.20.ebuild | 80 +++++++++++++++++++++++-------
 sys-libs/libxcrypt/libxcrypt-4.4.23.ebuild | 80 +++++++++++++++++++++++-------
 3 files changed, 126 insertions(+), 38 deletions(-)
Comment 19 Larry the Git Cow gentoo-dev 2021-07-05 23:46:49 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=3bd3959aa328c89f1ef959bfc342acef117c28a4

commit 3bd3959aa328c89f1ef959bfc342acef117c28a4
Author:     Alexey Sokolov <sokolov@google.com>
AuthorDate: 2021-07-01 22:49:22 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-07-05 23:46:43 +0000

    2021-06-30-libxcrypt-migration: Translate libxcrypt news to Russian
    
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Alexey Sokolov <sokolov@google.com>
    Signed-off-by: Sam James <sam@gentoo.org>

 .../2021-06-30-libxcrypt-migration.ru.txt          | 47 ++++++++++++++++++++++
 1 file changed, 47 insertions(+)
Comment 20 Larry the Git Cow gentoo-dev 2021-07-14 20:46:09 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6f79a445a9d0cfeec8ff47d591b3f76cbe2e8b86

commit 6f79a445a9d0cfeec8ff47d591b3f76cbe2e8b86
Author:     Andreas K. Hüttel <dilfridge@gentoo.org>
AuthorDate: 2021-07-14 18:48:11 +0000
Commit:     Andreas K. Hüttel <dilfridge@gentoo.org>
CommitDate: 2021-07-14 20:45:57 +0000

    package.mask: unmask virtual/libcrypt-2, except on musl/uclibc
    
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>

 profiles/features/musl/package.mask   | 4 ++++
 profiles/features/uclibc/package.mask | 4 ++++
 profiles/package.mask                 | 5 -----
 3 files changed, 8 insertions(+), 5 deletions(-)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4ced298fd259cbd089f994e084b30a58718b37fe

commit 4ced298fd259cbd089f994e084b30a58718b37fe
Author:     Andreas K. Hüttel <dilfridge@gentoo.org>
AuthorDate: 2021-07-14 18:47:12 +0000
Commit:     Andreas K. Hüttel <dilfridge@gentoo.org>
CommitDate: 2021-07-14 20:45:54 +0000

    package.use.{mask,force}: adapt for libxcrypt transition, except musl/uclibc
    
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>

 profiles/base/package.use.force            |  8 ++++----
 profiles/base/package.use.mask             | 10 ++++++----
 profiles/features/musl/package.use.force   |  4 ++++
 profiles/features/musl/package.use.mask    |  4 ++++
 profiles/features/uclibc/package.use.force |  6 ++++++
 profiles/features/uclibc/package.use.mask  |  4 ++++
 6 files changed, 28 insertions(+), 8 deletions(-)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3d0633cc281cb8beb325beaa9627c9858c20fdd5

commit 3d0633cc281cb8beb325beaa9627c9858c20fdd5
Author:     Andreas K. Hüttel <dilfridge@gentoo.org>
AuthorDate: 2021-07-14 18:41:34 +0000
Commit:     Andreas K. Hüttel <dilfridge@gentoo.org>
CommitDate: 2021-07-14 20:45:51 +0000

    sys-libs/glibc: ~arch revision bump without changes
    
    Bug: https://bugs.gentoo.org/699422
    Package-Manager: Portage-3.0.20, Repoman-3.0.3
    Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>

 sys-libs/glibc/glibc-2.33-r2.ebuild | 1520 +++++++++++++++++++++++++++++++++++
 1 file changed, 1520 insertions(+)

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

commit d1af401d6306a20c90bea3f3c05bf6c4d6e74529
Author:     Andreas K. Hüttel <dilfridge@gentoo.org>
AuthorDate: 2021-07-14 18:40:11 +0000
Commit:     Andreas K. Hüttel <dilfridge@gentoo.org>
CommitDate: 2021-07-14 20:45:48 +0000

    sys-libs/libxcrypt: Revision bump without changes
    
    Bug: https://bugs.gentoo.org/699422
    Package-Manager: Portage-3.0.20, Repoman-3.0.3
    Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>

 sys-libs/libxcrypt/libxcrypt-4.4.23-r1.ebuild | 207 ++++++++++++++++++++++++++
 1 file changed, 207 insertions(+)
Comment 21 Larry the Git Cow gentoo-dev 2021-07-22 23:41:21 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=0d11e58acccb28e8371d53ed53806a8a2d7b16be

commit 0d11e58acccb28e8371d53ed53806a8a2d7b16be
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-07-20 21:28:48 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-07-22 23:41:12 +0000

    2021-07-21-libxcrypt-migration: new news item for libxcrypt migration changes
    
    This amends the previous news item to include more information
    about PAM issues.
    
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Sam James <sam@gentoo.org>

 .../2021-06-30-libxcrypt-migration.ru.txt          | 47 ----------------------
 .../2021-07-23-libxcrypt-migration.en.txt          |  4 +-
 2 files changed, 2 insertions(+), 49 deletions(-)
Comment 22 Larry the Git Cow gentoo-dev 2021-07-29 21:50:26 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=1d2f17df23f2245cd51da75b0c9ca8bc12bdf7d0

commit 1d2f17df23f2245cd51da75b0c9ca8bc12bdf7d0
Author:     Alexey Sokolov <sokolov@google.com>
AuthorDate: 2021-07-29 21:43:06 +0000
Commit:     Stefan Strogin <steils@gentoo.org>
CommitDate: 2021-07-29 21:49:02 +0000

    2021-07-23-libxcrypt-migration: add updated Russian translation
    
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Alexey Sokolov <sokolov@google.com>
    Signed-off-by: Stefan Strogin <steils@gentoo.org>

 .../2021-07-23-libxcrypt-migration.ru.txt          | 67 ++++++++++++++++++++++
 1 file changed, 67 insertions(+)
Comment 23 Larry the Git Cow gentoo-dev 2021-10-31 21:25:10 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=c0fc80bac65a65d04ca4ce503c233d238d43d390

commit c0fc80bac65a65d04ca4ce503c233d238d43d390
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-10-31 21:22:33 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-10-31 21:25:05 +0000

    2021-10-18-libxcrypt-migration-stable: tweak guidance slightly
    
    Bug: https://bugs.gentoo.org/809410
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Sam James <sam@gentoo.org>

 .../2021-10-18-libxcrypt-migration-stable.en.txt          | 15 +++++++++++++++
 1 file changed, 15 insertions(+)
Comment 24 Larry the Git Cow gentoo-dev 2021-11-11 21:04:20 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3d081cb997d18d200c71e1ff394e17db2f01f38d

commit 3d081cb997d18d200c71e1ff394e17db2f01f38d
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-11-11 21:02:52 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-11-11 21:02:52 +0000

    sys-libs/glibc: drop Python 3.10 from PYTHON_COMPAT to avoid circular deps
    
    Needed for now to try help upgrades and avoid circular dependencies
    with glibc -> python -> libcrypt -> libxcrypt -> glibc -> ...
    
    Bug: https://bugs.gentoo.org/699422
    Bug: https://bugs.gentoo.org/702806
    Bug: https://bugs.gentoo.org/809410
    Signed-off-by: Sam James <sam@gentoo.org>

 sys-libs/glibc/glibc-2.33-r7.ebuild | 5 ++++-
 sys-libs/glibc/glibc-2.34-r1.ebuild | 5 ++++-
 sys-libs/glibc/glibc-9999.ebuild    | 5 ++++-
 3 files changed, 12 insertions(+), 3 deletions(-)
Comment 25 Larry the Git Cow gentoo-dev 2021-11-12 04:58:49 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=1c4eb83b3e4a1f453d16e8a2356ddf61651b5310

commit 1c4eb83b3e4a1f453d16e8a2356ddf61651b5310
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-11-12 04:58:26 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-11-12 04:58:26 +0000

    2021-10-18-libxcrypt-migration-stable: mention being in root shell if possible
    
    Bug: https://bugs.gentoo.org/699422
    Bug: https://bugs.gentoo.org/809410
    Signed-off-by: Sam James <sam@gentoo.org>

 .../2021-10-18-libxcrypt-migration-stable.en.txt                     | 5 +++++
 1 file changed, 5 insertions(+)
Comment 26 Larry the Git Cow gentoo-dev 2021-11-22 06:28:25 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=01fd1ed53bffbcb11aa1734eb0ca42d3597318f5

commit 01fd1ed53bffbcb11aa1734eb0ca42d3597318f5
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-11-22 06:08:11 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-11-22 06:28:17 +0000

    profiles: mask (older) virtual/libcrypt:0/1 for glibc to ease upgrades
    
    Mask the older virtual/libcrypt subslot (which permits glibc[crypt] instead
    of libxcrypt) to ease upgrades.
    
    Not yet doing this for musl (need to figure that out still) or uclibc (which
    is going away, see news).
    
    Was on the fence about doing this given it makes it slightly more
    awkward to put off the upgrade if desired, but that's really discouraged
    at this point, and I think it's worth it to make upgrades easier
    for more people.
    
    This helps Portage realise it can/should upgrade to virtual/libcrypt:0/2
    rather than giving very confusing blocker errors (which it often, but not
    always, gets past).
    
    Final push to do this was a forum post: https://forums.gentoo.org/viewtopic-t-1145602.html
    
    Bug: https://bugs.gentoo.org/699422
    Bug: https://bugs.gentoo.org/809410
    Signed-off-by: Sam James <sam@gentoo.org>

 profiles/base/package.mask            | 9 +++++++++
 profiles/features/musl/package.mask   | 1 +
 profiles/features/uclibc/package.mask | 1 +
 3 files changed, 11 insertions(+)
Comment 27 Larry the Git Cow gentoo-dev 2021-11-22 06:29:35 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=8f2ad6dd0515374e473b79d6f6cbc32ac8050680

commit 8f2ad6dd0515374e473b79d6f6cbc32ac8050680
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-11-22 06:14:07 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-11-22 06:14:07 +0000

    2021-10-18-libxcrypt-migration-stable: mention unmasking libcrypt:0/1 for delay
    
    If users want to delay the upgrade (please don't do this though), they
    will (shortly) need to unmask virtual/libcrypt:0/1 too.
    
    Bug: https://bugs.gentoo.org/699422
    Bug: https://bugs.gentoo.org/809410
    Signed-off-by: Sam James <sam@gentoo.org>

 .../2021-10-18-libxcrypt-migration-stable.en.txt                         | 1 +
 1 file changed, 1 insertion(+)
Comment 28 Larry the Git Cow gentoo-dev 2021-11-25 00:49:55 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=4cd7ab13760667cc70b151cfb592ef9868dcba70

commit 4cd7ab13760667cc70b151cfb592ef9868dcba70
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-11-25 00:49:07 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-11-25 00:49:07 +0000

    2021-07-23-libxcrypt-migration: delete older version of libxcrypt news item
    
    We've updated the "in stable" one (the newer news item) a few times so having
    this one around is confusing.
    
    Bug: https://bugs.gentoo.org/809410
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Sam James <sam@gentoo.org>

 .../2021-07-23-libxcrypt-migration.en.txt          | 65 ---------------------
 .../2021-07-23-libxcrypt-migration.ru.txt          | 67 ----------------------
 2 files changed, 132 deletions(-)
Comment 29 Larry the Git Cow gentoo-dev 2021-12-16 06:25:49 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=b76a1d4a5fa5a0e2a81d93c086d3077da82de89b

commit b76a1d4a5fa5a0e2a81d93c086d3077da82de89b
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-12-16 06:25:26 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-12-16 06:25:26 +0000

    2021-10-18-libxcrypt-migration-stable: improve readability a bit
    
    Bug: https://bugs.gentoo.org/699422
    Bug: https://bugs.gentoo.org/809410
    Signed-off-by: Sam James <sam@gentoo.org>

 .../2021-10-18-libxcrypt-migration-stable.en.txt   | 31 +++++++++++++++++-----
 1 file changed, 24 insertions(+), 7 deletions(-)
Comment 30 Larry the Git Cow gentoo-dev 2022-04-23 23:55:34 UTC
The bug has been referenced in the following commit(s):

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

commit aabea35bb6fdc0e5de5b899c0c2efa8e9570b1e1
Author:     Adrian Ratiu <adrian.ratiu@collabora.com>
AuthorDate: 2022-04-22 13:38:58 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2022-04-23 23:54:32 +0000

    sys-libs/libxcrypt: add cross-* build support
    
    This logic is required for cross LLVM toolchains built against
    glibc with its libcrypt disabled because compiler-rt requires a
    crypt.h header for its sanitizers, leading to a circular build
    dependency situation:
    
    libxcrypt -> compiler-rt -> libxcrypt
    
    To break this circular dep other cross-compilation build systems
    like Yocto have disabled compiler-rt sanitizers entirely [1] or
    a crypt.h header might be copied into the compiler-rt sources.
    
    A better solution than the above two is to directly be able to
    build libxcrypt before compiler-rt in the cross toolchain setup
    steps which is what this addition enables.
    
    [1] https://github.com/kraj/meta-clang/pull/426
    
    Bug: https://bugs.gentoo.org/699422
    Co-authored-by: Sam James <sam@gentoo.org>
    Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
    Closes: https://github.com/gentoo/gentoo/pull/20601
    Signed-off-by: Sam James <sam@gentoo.org>

 sys-libs/libxcrypt/libxcrypt-4.4.28.ebuild | 64 +++++++++++++++++++++++++-----
 1 file changed, 55 insertions(+), 9 deletions(-)
Comment 31 Andreas K. Hüttel archtester gentoo-dev 2022-04-25 21:35:50 UTC
Nothing to track here anymore, all done in stable.
Comment 32 Larry the Git Cow gentoo-dev 2022-09-10 11:28:31 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=68061fbd8345c59ec19fbad1bf1569d55186c19a

commit 68061fbd8345c59ec19fbad1bf1569d55186c19a
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2022-09-08 03:40:44 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2022-09-10 11:28:03 +0000

    profiles/features/musl: set -crypt on sys-libs/musl
    
    musl will still work with its own libcrypt, but applications
    and libraries are starting to need a fancier libcrypt (libxcrypt)
    so let's disable USE=crypt by default on sys-libs/musl to
    have libxcrypt provide crypt.h & libcrypt.so (musl's libcrypt
    is included in libc.so).
    
    This brings musl in line with the changes we made for glibc a while
    ago. The situation with glibc is a bit different because the migration
    is mandatory there, while we're just strongly recommending it for musl
    because sys-libs/libxcrypt[-system] causes headaches (see linked
    PAM bug for an example, but I've also hit a similar issue with Python
    yesterday).
    
    Bug: https://bugs.gentoo.org/867991
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Sam James <sam@gentoo.org>
    Closes: https://github.com/gentoo/gentoo/pull/27187
    Signed-off-by: Sam James <sam@gentoo.org>

 profiles/features/musl/package.use | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

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

commit f63e433a3db50537ff903195e7e7c90b80d68047
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2022-09-08 03:23:18 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2022-09-10 11:28:03 +0000

    profiles/features/musl: unmask sys-libs/libxcrypt[system]
    
    This brings musl in line with the changes we made for glibc a while
    ago. The situation with glibc is a bit different because the migration
    is mandatory there, while we're just strongly recommending it for musl
    because sys-libs/libxcrypt[-system] causes headaches (see linked
    PAM bug for an example, but I've also hit a similar issue with Python
    yesterday).
    
    Bug: https://bugs.gentoo.org/867991
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Sam James <sam@gentoo.org>

 profiles/features/musl/package.mask      | 5 -----
 profiles/features/musl/package.use.force | 4 ++--
 profiles/features/musl/package.use.mask  | 2 +-
 3 files changed, 3 insertions(+), 8 deletions(-)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4b7575b3f13e546dd2431d0ab8db699935392bdb

commit 4b7575b3f13e546dd2431d0ab8db699935392bdb
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2022-09-08 03:34:26 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2022-09-10 11:28:03 +0000

    virtual/libcrypt: add 2-r1 with support for musl
    
    This brings musl in line with the changes we made for glibc a while
    ago. The situation with glibc is a bit different because the migration
    is mandatory there, while we're just strongly recommending it for musl
    because sys-libs/libxcrypt[-system] causes headaches (see linked
    PAM bug for an example, but I've also hit a similar issue with Python
    yesterday).
    
    Bug: https://bugs.gentoo.org/867991
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Sam James <sam@gentoo.org>

 virtual/libcrypt/libcrypt-2-r1.ebuild | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=777ef3df1b81456b7b733d5673b341c6b9a22d88

commit 777ef3df1b81456b7b733d5673b341c6b9a22d88
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2022-09-08 03:24:29 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2022-09-10 11:28:03 +0000

    sys-libs/libxcrypt: wire up musl USE=system support
    
    This brings musl in line with the changes we made for glibc a while
    ago. The situation with glibc is a bit different because the migration
    is mandatory there, while we're just strongly recommending it for musl
    because sys-libs/libxcrypt[-system] causes headaches (see linked
    PAM bug for an example, but I've also hit a similar issue with Python
    yesterday).
    
    Bug: https://bugs.gentoo.org/867991
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Sam James <sam@gentoo.org>

 sys-libs/libxcrypt/libxcrypt-4.4.28-r2.ebuild | 304 ++++++++++++++++++++++++++
 1 file changed, 304 insertions(+)

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

commit fbdcef42c8f58fdd5175f2130afd56b8e42ef226
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2022-09-08 03:21:04 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2022-09-10 11:28:02 +0000

    sys-libs/musl: add USE=crypt for libxcrypt support
    
    Add USE=crypt to allow enabling/disabling crypt.h installation
    (to allow sys-libs/libxcrypt[system] usage). Many things are starting
    to want functions from libxcrypt itself (additional functions and
    algorithms).
    
    musl isn't removing crypt.h (and the relevant functions from its libc),
    unlike glibc, but we need to allow disabling the installation of crypt.h
    to allow libxcrypt[system] usage (which provides crypt.h & libcrypt.so
    instead, with more functionality).
    
    This brings musl in line with the changes we made for glibc a while
    ago. The situation with glibc is a bit different because the migration
    is mandatory there, while we're just strongly recommending it for musl
    because sys-libs/libxcrypt[-system] causes headaches (see linked
    PAM bug for an example, but I've also hit a similar issue with Python
    yesterday).
    
    Bug: https://bugs.gentoo.org/867991
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Sam James <sam@gentoo.org>

 sys-libs/musl/musl-1.2.3-r1.ebuild | 181 +++++++++++++++++++++++++++++++++++++
 sys-libs/musl/musl-9999.ebuild     |  10 +-
 2 files changed, 190 insertions(+), 1 deletion(-)