From Fedora Project Wiki
 
(11 intermediate revisions by 4 users not shown)
Line 10: Line 10:
 
* Name: [[User:besser82| Björn Esser]], [[User:fweimer| Florian Weimer]]
 
* Name: [[User:besser82| Björn Esser]], [[User:fweimer| Florian Weimer]]
 
* Email: besser82@fedoraproject.org, fweimer@redhat.com
 
* Email: besser82@fedoraproject.org, fweimer@redhat.com
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
+
* Release notes ticket: [https://pagure.io/fedora-docs/release-notes/issue/87 #87]
 
<!--* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address> -->
 
<!--* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address> -->
 
  
 
== Current status ==
 
== Current status ==
 
* Targeted release: [[Releases/28 | Fedora 28 ]]  
 
* Targeted release: [[Releases/28 | Fedora 28 ]]  
 
* Last updated: {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
 
* Last updated: {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Tracker bug: <will be assigned by the Wrangler>
+
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1537261 #1537261]
  
  
Line 23: Line 22:
  
 
Since there has been some discussion in the last time about [https://sourceware.org/ml/libc-alpha/2017-08/msg01257.html removing libcrypt from glibc] in some time and splitting it out into a separate project which can evolve quicker, Zack Weinberg and I put some work into [https://github.com/besser82/libxcrypt libxcrypt] to make it a basically suitable replacement.
 
Since there has been some discussion in the last time about [https://sourceware.org/ml/libc-alpha/2017-08/msg01257.html removing libcrypt from glibc] in some time and splitting it out into a separate project which can evolve quicker, Zack Weinberg and I put some work into [https://github.com/besser82/libxcrypt libxcrypt] to make it a basically suitable replacement.
 
libxcrypt is fully binary compatible with software linked against glibc's libcrypt and does not require any rebuilds.  However, the converse is not true: programs linked against libxcrypt will not work with glibc's libcrypt.  Also, programs that use certain legacy APIs supplied by glibc's libcrypt (encrypt, encrypt_r, setkey, setkey_r, and fcrypt) cannot be compiled against libxcrypt.
 
  
 
It comes with a set of extended interfaces pioneered by Openwall Linux, crypt_rn, crypt_ra, crypt_gensalt, crypt_gensalt_rn, and crypt_gensalt_ra.
 
It comes with a set of extended interfaces pioneered by Openwall Linux, crypt_rn, crypt_ra, crypt_gensalt, crypt_gensalt_rn, and crypt_gensalt_ra.
Line 33: Line 30:
 
== Benefit to Fedora ==
 
== Benefit to Fedora ==
  
+
With libxcrypt the following benefits are expected:
 
+
* new hashing algorithms are easiely integratable
 +
* faster development cycle compared to glibc's libcrypt
 +
* support for all hashing algorithms ever introduced to the crypt function
 +
 
  
 
== Scope ==
 
== Scope ==
 +
 
* Proposal owners:
 
* Proposal owners:
 
** Apply needed packaging changes to glibc
 
** Apply needed packaging changes to glibc
** Import and build libxcrypt for Fedora 28
+
** Review, import and build libxcrypt for Fedora 28 (review ticket: <strike>[https://bugzilla.redhat.com/show_bug.cgi?id=1532794 #1532794]</strike>)
  
 
* Other developers:
 
* Other developers:
 +
** Add <code>#include &lt;crypt.h&gt;</code> if it was missing before (e.g. detecting it is present by configure or conditionalizing on _XOPEN_CRYPT '''not''' being defined by <code>&lt;unistd.h></code>).  <code>&lt;unistd.h></code> no longer provides a declaration of the <code>crypt</code> function.
 +
** Optionally, add <code>BuildRequires: libxcrypt-devel</code> (which will eventually be needed some time after the Fedora 28 release).
 
** Test their applications using one of the following interfaces for unexpected changes in functionality:
 
** Test their applications using one of the following interfaces for unexpected changes in functionality:
 
*** crypt()
 
*** crypt()
Line 51: Line 54:
 
*** setkey_r()
 
*** setkey_r()
  
* Release engineering: [https://pagure.io/releng/issue/7160 #7160]
+
* Release engineering: [https://pagure.io/releng/issue/7160 #7160 none expected]
 
<!-- ** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: -->
 
<!-- ** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: -->
 
* Policies and guidelines: N/A (not needed for this Change)
 
* Policies and guidelines: N/A (not needed for this Change)
 
* Trademark approval: N/A (not needed for this Change)
 
* Trademark approval: N/A (not needed for this Change)
 
  
 
== Upgrade/compatibility impact ==
 
== Upgrade/compatibility impact ==
  
 +
On Linux-based systems, by default libxcrypt will be binary backward compatible with the libcrypt.so.1 shipped as part of the GNU C Library. This means that all existing binary executables linked against glibc's libcrypt should work unmodified with this library's libcrypt.so.1. We have taken pains to provide exactly the same "symbol versions" as were used by glibc on various CPU architectures, and to account for the variety of ways in which the Openwall extensions were patched into glibc's libcrypt by some Linux distributions.
  
 +
However, the converse is not true: programs linked against the libcrypt.so.1 built by libxcrypt will not work with glibc's libcrypt.  Also, programs that use certain legacy APIs supplied by glibc's libcrypt (encrypt, encrypt_r, setkey, setkey_r, and fcrypt) cannot be compiled against libxcrypt.
  
  
Line 66: Line 70:
 
* Logout of your current user session and check if you can login again.
 
* Logout of your current user session and check if you can login again.
 
* Change your user password and check if you can login with the new one.
 
* Change your user password and check if you can login with the new one.
* Check if all packages built against libcrypt are working as expected.  You can get a list of those packages with the following command:  `sudo dnf repoquery --whatrequires 'libcrypt.so*' | sed -e 's!-[0-9]\+.*$!!g' | sort -u`
+
* Check if all packages built against libcrypt are working as expected.  You can get a list of those packages with the following command:  <code>sudo dnf repoquery --whatrequires 'libcrypt.so*' | sed -e 's!-[0-9]\+.*$!!g' | sort -u</code>
  
  
 
== User Experience ==
 
== User Experience ==
  
 
+
No noticable changes for end-users.  Software developers can use some new functionality.
  
  
 
== Dependencies ==
 
== Dependencies ==
  
 
+
None, except for glibc (and the needed changes there).
  
  
 
== Contingency Plan ==
 
== Contingency Plan ==
  
* Contingency mechanism: Revert changes and restore glibc's libcrypt
+
* Contingency mechanism: Revert changes and restore glibc's libcrypt (and rebuild binaries which link against libxcrypt-only symbols)
 
* Contingency deadline: Completion deadline (testable)
 
* Contingency deadline: Completion deadline (testable)
* Blocks release? Yes
+
* Blocks release? No
* Blocks product? none
+
* Blocks product? None
  
  
 
== Documentation ==
 
== Documentation ==
  
 
+
tba.
  
  
 
== Release Notes ==
 
== Release Notes ==
  
 +
tba.
  
  
 
+
[[Category:ChangeAcceptedF28]]
[[Category:ChangePageIncomplete]]
 
<!-- [[Category:ChangeReadyForWrangler]] -->
 
 
 
 
[[Category:SystemWideChange]]
 
[[Category:SystemWideChange]]

Latest revision as of 14:48, 2 March 2018

Replace glibc's libcrypt with libxcrypt

Summary

There are plans to remove libcrypt from glibc, so we should have a replacement.


Owner

Current status


Detailed Description

Since there has been some discussion in the last time about removing libcrypt from glibc in some time and splitting it out into a separate project which can evolve quicker, Zack Weinberg and I put some work into libxcrypt to make it a basically suitable replacement.

It comes with a set of extended interfaces pioneered by Openwall Linux, crypt_rn, crypt_ra, crypt_gensalt, crypt_gensalt_rn, and crypt_gensalt_ra.

The crypt and gensalt functions are supporting all (except for Crypt16, which was used on Ultrix and Tru64, only) widely used password hashing algorithms, which before were specific to just some operating system's implementations of libcrypt.


Benefit to Fedora

With libxcrypt the following benefits are expected:

  • new hashing algorithms are easiely integratable
  • faster development cycle compared to glibc's libcrypt
  • support for all hashing algorithms ever introduced to the crypt function


Scope

  • Proposal owners:
    • Apply needed packaging changes to glibc
    • Review, import and build libxcrypt for Fedora 28 (review ticket: #1532794)
  • Other developers:
    • Add #include <crypt.h> if it was missing before (e.g. detecting it is present by configure or conditionalizing on _XOPEN_CRYPT not being defined by <unistd.h>). <unistd.h> no longer provides a declaration of the crypt function.
    • Optionally, add BuildRequires: libxcrypt-devel (which will eventually be needed some time after the Fedora 28 release).
    • Test their applications using one of the following interfaces for unexpected changes in functionality:
      • crypt()
      • crypt_r()
      • encrypt()
      • encrypt_r()
      • fcrypt()
      • setkey()
      • setkey_r()
  • Release engineering: #7160 none expected
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

On Linux-based systems, by default libxcrypt will be binary backward compatible with the libcrypt.so.1 shipped as part of the GNU C Library. This means that all existing binary executables linked against glibc's libcrypt should work unmodified with this library's libcrypt.so.1. We have taken pains to provide exactly the same "symbol versions" as were used by glibc on various CPU architectures, and to account for the variety of ways in which the Openwall extensions were patched into glibc's libcrypt by some Linux distributions.

However, the converse is not true: programs linked against the libcrypt.so.1 built by libxcrypt will not work with glibc's libcrypt. Also, programs that use certain legacy APIs supplied by glibc's libcrypt (encrypt, encrypt_r, setkey, setkey_r, and fcrypt) cannot be compiled against libxcrypt.


How To Test

  • Logout of your current user session and check if you can login again.
  • Change your user password and check if you can login with the new one.
  • Check if all packages built against libcrypt are working as expected. You can get a list of those packages with the following command: sudo dnf repoquery --whatrequires 'libcrypt.so*' | sed -e 's!-[0-9]\+.*$!!g' | sort -u


User Experience

No noticable changes for end-users. Software developers can use some new functionality.


Dependencies

None, except for glibc (and the needed changes there).


Contingency Plan

  • Contingency mechanism: Revert changes and restore glibc's libcrypt (and rebuild binaries which link against libxcrypt-only symbols)
  • Contingency deadline: Completion deadline (testable)
  • Blocks release? No
  • Blocks product? None


Documentation

tba.


Release Notes

tba.