This is a long term goal, so I'm opening this mostly to have a place to dump some links and summarize current state.
From the latest fedora:31 image: - gnutls - gpgme - libgcrypt - libgpg-error - libxcrypt - openssl - openssl-libs
What is missing from this list: nss! Yay, we only have two out of the three complete crypto stacks.
I also see: libpwquality, cracklib. We probably don't need those either.
I generally discuss this as either 3.5 or 4 crypto stacks, namely:
WRT the base image:
openssl is used by the most packages. Moving systemd from libgcrypt/gnutls to openssl (which is already available as a meson configure time option) would leave gnupg2, which is used by RPM for verifying package signatures, as the sole consumer of gnutls (for secure downloading from keyservers) and libgcrypt (for crypto). Ironically, even gnutls doesn't even use libgcrypt any more, having switched to nettle. While I could see that gnupg2 (being a GNU project) wouldn't want to move from gnutls to openssl, at least switching from libgcrypt to nettle (which would require porting) might still be an option. (Or maybe not, given that they both come from the same project.)
As for libxcrypt, it was actually part of glibc originally, and provides a POSIX C function interface that isn't really provided elsewhere AFAIK. (For example, even python3 which uses openssl throughout still relies on libxcrypt for crypt(3) etc.) I'm not so sure if this can be replaced.
Metadata Update from @asamalik: - Issue tagged with: Package Notes
Metadata Update from @asamalik: - Issue tagged with: Focus Area: Use Case Analysis
Just a note: gcrypt dependency in the package installation stack is a bit different: dnf → python3-dnf → python3-gpg → gpgme → gnupg2 → libgcrypt.
systemd obviously still requires libgcrypt directly. We're working on making openssl an option.
Login to comment on this ticket.