Fully remove deprecated and unsafe functions from libcrypt
Summary
This change is about removing binary support for deprecated and unsafe functions and bumping libcrypt.so to libcrypt.so.2.
Owner
- Name: Björn Esser <besser82@fedoraproject.org>
- Release notes owner:
Current status
- Targeted release: Fedora 30
- Last updated: 2019-01-30
- Tracker bug: #1666033
- Release notes tracker: #280
Detailed Description
In Fedora 28 we replaced glibc's libcrypt with the fully binary compatible libcrypt library from the external libxcrypt project. There are certain interfaces (encrypt, encrypt_r, setkey, setkey_r) that are mandatory by POSIX or various other standards.
At the time those interfaces have been implemented they internally relied on using the DES encryption algorithm, that today is widely considered unsecure and insufficient for applications which require sane data encryption. There are various recommendations new written code should not use them anymore.
For keeping binary backwards compatibility we made sure the libcrypt library still provides those interfaces for existing applications, but code cannot be compiled against them anymore. For that reason there is no application left in Fedora that uses them. With the latest release of glibc, its upstream developers made sure those interfaces cannot be compiled against their libcrypt anymore, too.
Some users may use software from third-parties that may still use those interfaces silently and possibly sacrificing the security of the user's sensitive data silently.
For that reason those interfaces should genrally not be available by default for existing third-party applications in Fedora anymore. Fedora users should be aware whether they use applications that utilize secure encryption algorithms or not.
To accomplish this we are going to bump the shared object name of libcrypt.so from 1 to 2 and remove all of the functions that are considered unsafe. The maintain POSIX or otherwise compatibility, we keep providing a compatibility library (libcrypt.so.1) in a separated package, that can be installed by the user.
Benefit to Fedora
Most of the benefits have already been explained in the detailed description above.
For those given reasons the key benefit for Fedora is to provide their users a default installation that ensures no third-party software can use unsafe encryption algorithms silently. If a user still wants to use such applications (or really requires the usage of those few POSIX interfaces otherwise), it is required for them to install an additional compatibility-package prior to using such an application.
Scope
- Proposal owners: Build the libxcrypt package with bumped so-name, enable compatibility library for third-party applications and rebuild the packages that require libcrypt.so.1. After all packages have been rebuilt strip all hashing methods but the ones provided by former glibc libcrypt from the compatibility library.
- Other developers: No involvement needed, but testing their packages still work as expected.
- Release engineering: #8023
- List of deliverables: This change does not block any deliverable.
- Policies and guidelines: N/A (not needed for this Change)
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
The library with the bumped so-name will be pulled automatically on upgrades by autogenerated rpm dependencies. Users of third-party applications linked against libcrypt.so.1 my need to install the libxcrypt-compat package.
How To Test
There is no real testing needed, as the common interfaces of libcrypt.so.2 do not differ from the ones of libcrypt.so.1, just the legacy bits, which are not used by any application inside Fedora anymore, are removed. Thus basic testing (does it start?) of the applications using the crypt() (or crypt_gensalt()) interfaces is sufficient.
User Experience
No user-visible impacts, but maybe the need for manually installing the libxcrypt-compat package for some third-party applications.
Dependencies
There are about 187 pacakges that require libcrypt.so.1, which need to be rebuild at some point (e.g. during mass-rebuild). There is no immediate rebuild needed as we still provide a reduced, but still sufficient, libcrypt.so.1 library for POSIX compatibility.
Contingency Plan
- Change the symlink from the libxcrypt-devel package to point to the libcrypt.so.1 library again.
- Rebuild all packages, that already require libcrypt.so.2
- Fully revert the so-name bump.
Documentation
The version of the libxcrypt package included with Fedora 30 now ships the libcrypt.so.2 library and does not provide the legacy API functions that have been provided by glibc's libcrypt.so.1. The removed functions by name are encrypt, encrypt_r, setkey, setkey_r, and fcrypt.
If you are using a third-party application that links against those functions, or that is linked against glibc's libcrypt, you may need to install the libxcrypt-compat package manually.
All existing binary executables linked against glibc's libcrypt should work unmodified with the libcrypt.so.1 library supplied by the libxcrypt-compat package.
Release Notes
See the paragraph about documentation above.