Am Dienstag, den 15.01.2019, 23:16 -0500 schrieb Scott Schmit: > On Wed, Jan 02, 2019 at 04:14:59PM -0500, Ben Cotton wrote: > > == Detailed Description == > <snip helpful background> > > > 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. > > <big thumbs up> DES has been proven insecure against brute force for > over two decades. > > <snip a lot of good engineering to make it hard to keep using these > broken functions> > > > 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. > > But this happens all the time with other libraries, so I doubt an > uninformed user will understand you did it on purpose unless you do > something more. > > How do we plan to describe the package in the > summary/description? And > if they don't look at that, what clue will the user get that they > might > want to re-think the install of the compat package? > > Maybe this package should be named > "libxcrypt-compat-insecure-read-description-before-install"? Or at > least *something* that screams "wait, maybe I should look into this > more, this isn't standard operating procedure..."? > > > == User Experience == > > No user-visible impacts, but maybe the need for manually installing > > the libxcrypt-compat package for some third-party applications. > > This seems a little problematic given the motivation behind this > change. > > > == Documentation == > > The version of the libxcrypt package included with Fedora 30 now > > ships > > the libcrypt.so2 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. > > And I object to nothing in this section informing the user that "those > interfaces ... possibly sacrific[e] the security of the user's > sensitive > data silently." Especially since it appears that this will the > wording > that goes into the release notes. > > > == Release Notes == > > See the paragraph about documentation above. > > See objections above. Please have a look at this separate change proposal [1]. It is discussed here [2]. Basically the named unsafe functions are subject to be changed in the compat library to some no-function stubs which still guarantee to be compliant to POSIX and other standarts, so "Average Joe" users do not face that security problem even when installing the compat package. [1] https://fedoraproject.org/wiki/Changes/libcrypt_so_1_Let_encrypt_encrypt_r_setkey_setkey_r_and_fcrypt_return_ENOSYS_instead_of_performing_any_real_operation [2] https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/YRGAKN3RMIB23HNTWRDYX4Y6QA6D2YVL/
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
