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. -- Scott Schmit
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
