libsodium is not part of the CentOS Stream/RHEL content set and has known issues for certification compliance.  It is also identified as an unwanted package in the ELN content resolver:

https://github.com/minimization/content-resolver-input/blob/master/configs/sst_security_crypto-unwanted.yaml

We will not be adding it at this time and therefore PHP cannot enable support for it.

(In reply to Josh Boyer from comment #2)
> libsodium is not part of the CentOS Stream/RHEL content set and has known
> issues for certification compliance.

The problem with this is that ever since the sodium extension was bundled into PHP with PHP 7.2[1], applications have been increasingly adopting it. And even in the RFC, the PHP community has taken the stance (for better or worse) that OpenSSL does not provide adequate security.

What am I supposed to do when a bundled extension that is now only part of the core and is increasingly required by applications? It's a unique API provided by PHP rather than an implementation detail of some generic API in PHP.

[1]: https://wiki.php.net/rfc/libsodium

Just to add a comment as a PHP developer (and who encountered this problem today). One problem with not providing php-sodium is that once a database has password hashed with argon2i (for example using remirepo or another Linux distribution), it is then impossible to verify them on a rhel/centos machine with the official repo without installing a polyfill of a dubious quality.

For PHP >= 7.4 having PHP compiled with the libsodium package is not recommended anymore but what is needed to solve the problem is having php-sodium extension at least on epel (and so not officially supported).

(In reply to Carl Schwan from comment #4)
> Just to add a comment as a PHP developer (and who encountered this problem
> today). One problem with not providing php-sodium is that once a database
> has password hashed with argon2i (for example using remirepo or another
> Linux distribution), it is then impossible to verify them on a rhel/centos
> machine with the official repo without installing a polyfill of a dubious
> quality.
> 
> For PHP >= 7.4 having PHP compiled with the libsodium package is not
> recommended anymore but what is needed to solve the problem is having
> php-sodium extension at least on epel (and so not officially supported).

Thank you for the added data point.  Unfortunately, it is unlikely to change the answer to this RFE.  We can leave the bug open if you'd like, but our intentions are to be as clear as possible that we do not intend to include libsodium in RHEL 9/CentOS Stream 9.

(For future reference on process, this would really need two bugs.  The first against the distribution component to add libsodium, which again will not be added.  Then a bug such as this against PHP to enable the feature.)

(In reply to Carl Schwan from comment #4)

> what is needed to solve the problem is having
> php-sodium extension at least on epel (and so not officially supported).

For now it is no possible to build extensions for modules
https://pagure.io/epel/issue/75

For EPEL-8 this is a major blocker.

For EPEL-9 things could seem better as php is no more a module
so it will be possible to provide php-sodium there.

But only for default PHP version 8.0, not for possible future
versions probably shipped as modules. So can be considered as
worst, as using extensions from EPEL will forbid the update
to any newer versions.


BTW, workaround exists...
(other 3rd party repo, of course unsupported)

Reopening this will not change the fact that libsodium will not ship in RHEL9.

At some point OpenSSL will hopefully ship an argon implementation and that can become accessible via PHP in RHEL. That is not planned for 3.0.0 so is also unlikely to happen for RHEL 9.0.  When there is a feasible route to supporting Argon in PHP let's track that.