Message ID | 20180521173853.5172-5-zackw@panix.com |
---|---|
State | New |
Headers | show |
Series | libcrypt phaseout | expand |
On Mon, 21 May 2018, Zack Weinberg wrote:
> unistd.h continues to define _XOPEN_CRYPT to 1 and to declare crypt.
I'd expect _XOPEN_CRYPT to change in patch 1, since it includes encrypt
and setkey.
On Mon, May 21, 2018 at 3:51 PM, Joseph Myers <joseph@codesourcery.com> wrote: > On Mon, 21 May 2018, Zack Weinberg wrote: > >> unistd.h continues to define _XOPEN_CRYPT to 1 and to declare crypt. > > I'd expect _XOPEN_CRYPT to change in patch 1, since it includes encrypt > and setkey. No, this is an intentional deviation from the present state of POSIX, anticipating the removal of those functions from the standard. zw
On Mon, 21 May 2018, Zack Weinberg wrote: > On Mon, May 21, 2018 at 3:51 PM, Joseph Myers <joseph@codesourcery.com> wrote: > > On Mon, 21 May 2018, Zack Weinberg wrote: > > > >> unistd.h continues to define _XOPEN_CRYPT to 1 and to declare crypt. > > > > I'd expect _XOPEN_CRYPT to change in patch 1, since it includes encrypt > > and setkey. > > No, this is an intentional deviation from the present state of POSIX, > anticipating the removal of those functions from the standard. That would only seem relevant to the _XOPEN_CRYPT value in future POSIX modes, not current ones. The conform/ data is in any case meant to correspond to the standard versions in question (plus defect corrections from TCs etc., not plus feature changes from other revisions to the standard). Intentionally unsupported features are listed in that data with appropriate XFAILs (see e.g. those for varargs.h in conform/Makefile).
On Mon, May 21, 2018 at 6:34 PM, Joseph Myers <joseph@codesourcery.com> wrote: > On Mon, 21 May 2018, Zack Weinberg wrote: > >> On Mon, May 21, 2018 at 3:51 PM, Joseph Myers <joseph@codesourcery.com> wrote: >> > On Mon, 21 May 2018, Zack Weinberg wrote: >> > >> >> unistd.h continues to define _XOPEN_CRYPT to 1 and to declare crypt. >> > >> > I'd expect _XOPEN_CRYPT to change in patch 1, since it includes encrypt >> > and setkey. >> >> No, this is an intentional deviation from the present state of POSIX, >> anticipating the removal of those functions from the standard. > > That would only seem relevant to the _XOPEN_CRYPT value in future POSIX > modes, not current ones. Making _XOPEN_CRYPT be -1 or undefined in current conformance modes would be a disservice to any program that is actually using it, since it is overwhelmingly likely that they are using it to detect crypt, not encrypt or setkey. > The conform/ data is in any case meant to correspond to the standard > versions in question (plus defect corrections from TCs etc., not plus > feature changes from other revisions to the standard). Intentionally > unsupported features are listed in that data with appropriate XFAILs (see > e.g. those for varargs.h in conform/Makefile). This I can change. zw
On 05/22/2018 12:34 AM, Joseph Myers wrote: > On Mon, 21 May 2018, Zack Weinberg wrote: > >> On Mon, May 21, 2018 at 3:51 PM, Joseph Myers <joseph@codesourcery.com> wrote: >>> On Mon, 21 May 2018, Zack Weinberg wrote: >>> >>>> unistd.h continues to define _XOPEN_CRYPT to 1 and to declare crypt. >>> >>> I'd expect _XOPEN_CRYPT to change in patch 1, since it includes encrypt >>> and setkey. >> >> No, this is an intentional deviation from the present state of POSIX, >> anticipating the removal of those functions from the standard. > > That would only seem relevant to the _XOPEN_CRYPT value in future POSIX > modes, not current ones. So we should stop defining _XOPEN_CRYPT, but continue to declare crypt in <unistd.h> for __USE_MISC || __USE_XOPEN? That would work for me. I would like to see this committed this cycle, and will try to get this committed on Zack's behalf. > The conform/ data is in any case meant to correspond to the standard > versions in question (plus defect corrections from TCs etc., not plus > feature changes from other revisions to the standard). Intentionally > unsupported features are listed in that data with appropriate XFAILs (see > e.g. those for varargs.h in conform/Makefile). I find these XFAILs fairly annoying, by the way. Especially for things we simply cannot fix because we do not supply the header (<ndbm.h> comes to my mind). Thanks, Florian
On Wed, Jun 20, 2018 at 4:40 PM, Florian Weimer <fweimer@redhat.com> wrote: > On 05/22/2018 12:34 AM, Joseph Myers wrote: >> On Mon, 21 May 2018, Zack Weinberg wrote: >>> No, this is an intentional deviation from the present state of POSIX, >>> anticipating the removal of those functions from the standard. >> >> That would only seem relevant to the _XOPEN_CRYPT value in future POSIX >> modes, not current ones. > > So we should stop defining _XOPEN_CRYPT, but continue to declare crypt in > <unistd.h> for __USE_MISC || __USE_XOPEN? That would work for me. Again, I think that it is inappropriate to stop defining _XOPEN_CRYPT in any mode. Yes, this is an intentional deviation from POSIX, but I think it is far less likely to break existing programs than the alternative. zw
On 06/21/2018 12:47 AM, Zack Weinberg wrote: > On Wed, Jun 20, 2018 at 4:40 PM, Florian Weimer <fweimer@redhat.com> wrote: >> On 05/22/2018 12:34 AM, Joseph Myers wrote: >>> On Mon, 21 May 2018, Zack Weinberg wrote: >>>> No, this is an intentional deviation from the present state of POSIX, >>>> anticipating the removal of those functions from the standard. >>> >>> That would only seem relevant to the _XOPEN_CRYPT value in future POSIX >>> modes, not current ones. >> >> So we should stop defining _XOPEN_CRYPT, but continue to declare crypt in >> <unistd.h> for __USE_MISC || __USE_XOPEN? That would work for me. > > Again, I think that it is inappropriate to stop defining _XOPEN_CRYPT > in any mode. Yes, this is an intentional deviation from POSIX, but I > think it is far less likely to break existing programs than the > alternative. How can we resolve this conflict? We have mostly cleaned up Fedora 28 to build with !_XOPEN_CRYPT already. There weren't many changes AFAICS, and they fall broadly into two categories: (1) Not including <crypt.h> for the crypt function, only <unistd.h>. (2) Using DES functions. (1) was far more common than (2). We'll keep the declaration of crypt in <unistd.h> for _DEFAULT_SOURCE, so (1) will not be a problem. (2) will not be addressed independently of the definition of _XOPEN_CRYPT. This is why I'm fine with Joseph's approach. It may even make it marginally easier to check whether you need your own DES implementation. I would like to see a decision soon because I'm wondering if I have to back out the libxcrypt switch. Thanks, Florian
On 06/21/2018 11:31 AM, Florian Weimer wrote: > On 06/21/2018 12:47 AM, Zack Weinberg wrote: >> On Wed, Jun 20, 2018 at 4:40 PM, Florian Weimer <fweimer@redhat.com> >> wrote: >>> On 05/22/2018 12:34 AM, Joseph Myers wrote: >>>> On Mon, 21 May 2018, Zack Weinberg wrote: >>>>> No, this is an intentional deviation from the present state of POSIX, >>>>> anticipating the removal of those functions from the standard. >>>> >>>> That would only seem relevant to the _XOPEN_CRYPT value in future POSIX >>>> modes, not current ones. >>> >>> So we should stop defining _XOPEN_CRYPT, but continue to declare >>> crypt in >>> <unistd.h> for __USE_MISC || __USE_XOPEN? That would work for me. >> >> Again, I think that it is inappropriate to stop defining _XOPEN_CRYPT >> in any mode. Yes, this is an intentional deviation from POSIX, but I >> think it is far less likely to break existing programs than the >> alternative. > > How can we resolve this conflict? > > We have mostly cleaned up Fedora 28 to build with !_XOPEN_CRYPT already. > There weren't many changes AFAICS, and they fall broadly into two > categories: > > (1) Not including <crypt.h> for the crypt function, only <unistd.h>. > (2) Using DES functions. > > (1) was far more common than (2). > > We'll keep the declaration of crypt in <unistd.h> for _DEFAULT_SOURCE, > so (1) will not be a problem. (2) will not be addressed independently > of the definition of _XOPEN_CRYPT. > > This is why I'm fine with Joseph's approach. It may even make it > marginally easier to check whether you need your own DES implementation. > > I would like to see a decision soon because I'm wondering if I have to > back out the libxcrypt switch. In Fedora, of course. Sorry for being unclear. Florian
On Thu, Jun 21, 2018 at 5:31 AM, Florian Weimer <fweimer@redhat.com> wrote: > On 06/21/2018 12:47 AM, Zack Weinberg wrote: >> On Wed, Jun 20, 2018 at 4:40 PM, Florian Weimer <fweimer@redhat.com> >>> >>> So we should stop defining _XOPEN_CRYPT, but continue to declare crypt in >>> <unistd.h> for __USE_MISC || __USE_XOPEN? That would work for me. >> >> >> Again, I think that it is inappropriate to stop defining _XOPEN_CRYPT >> in any mode. Yes, this is an intentional deviation from POSIX, but I >> think it is far less likely to break existing programs than the >> alternative. > > How can we resolve this conflict? > > We have mostly cleaned up Fedora 28 to build with !_XOPEN_CRYPT already. > There weren't many changes AFAICS, and they fall broadly into two > categories: > > (1) Not including <crypt.h> for the crypt function, only <unistd.h>. > (2) Using DES functions. > > (1) was far more common than (2). > > We'll keep the declaration of crypt in <unistd.h> for _DEFAULT_SOURCE, so > (1) will not be a problem. (2) will not be addressed independently of the > definition of _XOPEN_CRYPT. Based on this I withdraw my objection. I was primarily worried about programs that might substitute their own, possibly DES-only, crypt() implementation if _XOPEN_CRYPT wasn't defined. zw
diff --git a/INSTALL b/INSTALL index 052b1b6f89..37ec68fb3d 100644 --- a/INSTALL +++ b/INSTALL @@ -197,6 +197,17 @@ if 'CFLAGS' is specified it must enable optimization. For example: libnss_nisplus are not built at all. Use this option to enable libnsl with all depending NSS modules and header files. +'--disable-crypt' + Do not install the passphrase-hashing library 'libcrypt' or the + header file 'crypt.h'. 'unistd.h' will still declare the function + 'crypt', as required by POSIX. Using this option does not change + the set of programs that may need to be linked with '-lcrypt'; it + only means that the GNU C Library will not provide that library. + + This option is for hackers and distributions experimenting with + independently-maintained implementations of libcrypt. It may + become the default in a future release. + '--disable-experimental-malloc' By default, a per-thread cache is enabled in 'malloc'. While this cache can be disabled on a per-application basis using tunables diff --git a/Makeconfig b/Makeconfig index 1afe86475c..608ffe648c 100644 --- a/Makeconfig +++ b/Makeconfig @@ -566,7 +566,7 @@ link-libc-printers-tests = $(link-libc-rpath) \ $(link-libc-tests-after-rpath-link) # This is how to find at build-time things that will be installed there. -rpath-dirs = math elf dlfcn nss nis rt resolv crypt mathvec support +rpath-dirs = math elf dlfcn nss nis rt resolv mathvec support rpath-link = \ $(common-objdir):$(subst $(empty) ,:,$(patsubst ../$(subdir),.,$(rpath-dirs:%=$(common-objpfx)%))) else # build-static @@ -1205,9 +1205,14 @@ all-subdirs = csu assert ctype locale intl catgets math setjmp signal \ stdlib stdio-common libio malloc string wcsmbs time dirent \ grp pwd posix io termios resource misc socket sysvipc gmon \ gnulib iconv iconvdata wctype manual shadow gshadow po argp \ - crypt localedata timezone rt conform debug mathvec support \ + localedata timezone rt conform debug mathvec support \ dlfcn elf +ifeq ($(build-crypt),yes) +all-subdirs += crypt +rpath-dirs += crypt +endif + ifndef avoid-generated # sysd-sorted itself will contain rules making the sysd-sorted target # depend on Depend files. But if you just added a Depend file to an diff --git a/NEWS b/NEWS index 0bd21948f6..e80d3d800c 100644 --- a/NEWS +++ b/NEWS @@ -86,6 +86,19 @@ Deprecated and removed features, and other changes affecting compatibility: binaries. It was just another name for the standard function 'crypt', and it has not appeared in any header file in many years. +* We have tentative plans to hand off maintenance of the passphrase-hashing + library, libcrypt, to a separate development project that will, we hope, + keep up better with new passphrase-hashing algorithms. We will continue + to declare 'crypt' in <unistd.h>, as required by POSIX, and programs that + use 'crypt' or 'crypt_r' should not need to change at all; however, system + integrators will need to install <crypt.h> and libcrypt from the separate + project. + + In this release, if the configure option --disable-crypt is used, glibc + will not install <crypt.h> or libcrypt, making room for the separate + project's versions of these files. The plan is to make this the default + behavior in a future release. + Changes to build and runtime requirements: [Add changes to build and runtime requirements here] diff --git a/config.make.in b/config.make.in index 9e5e24b2c6..d9891b2cd8 100644 --- a/config.make.in +++ b/config.make.in @@ -96,6 +96,7 @@ cross-compiling = @cross_compiling@ force-install = @force_install@ link-obsolete-rpc = @link_obsolete_rpc@ build-obsolete-nsl = @build_obsolete_nsl@ +build-crypt = @build_crypt@ build-nscd = @build_nscd@ use-nscd = @use_nscd@ build-hardcoded-path-in-tests= @hardcoded_path_in_tests@ diff --git a/configure b/configure index 7a8bd3f817..ef18302215 100755 --- a/configure +++ b/configure @@ -676,6 +676,7 @@ build_obsolete_nsl link_obsolete_rpc libc_cv_static_nss_crypt libc_cv_nss_crypt +build_crypt experimental_malloc enable_werror all_warnings @@ -779,6 +780,7 @@ enable_all_warnings enable_werror enable_multi_arch enable_experimental_malloc +enable_crypt enable_nss_crypt enable_obsolete_rpc enable_obsolete_nsl @@ -1448,6 +1450,8 @@ Optional Features: architectures --disable-experimental-malloc disable experimental malloc features + --disable-crypt do not build nor install the passphrase hashing + library, libcrypt --enable-nss-crypt enable libcrypt to use nss --enable-obsolete-rpc build and install the obsolete RPC code for link-time usage @@ -3505,6 +3509,15 @@ fi +# Check whether --enable-crypt was given. +if test "${enable_crypt+set}" = set; then : + enableval=$enable_crypt; build_crypt=$enableval +else + build_crypt=yes +fi + + + # Check whether --enable-nss-crypt was given. if test "${enable_nss_crypt+set}" = set; then : enableval=$enable_nss_crypt; nss_crypt=$enableval @@ -3512,6 +3525,11 @@ else nss_crypt=no fi +if test x$build_libcrypt = xno && test x$nss_crypt = xyes; then + { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: --enable-nss-crypt has no effect when libcrypt is disabled" >&5 +$as_echo "$as_me: WARNING: --enable-nss-crypt has no effect when libcrypt is disabled" >&2;} + nss_crypt=no +fi if test x$nss_crypt = xyes; then nss_includes=-I$(nss-config --includedir 2>/dev/null) if test $? -ne 0; then diff --git a/configure.ac b/configure.ac index ca1282a6b3..dc517017f5 100644 --- a/configure.ac +++ b/configure.ac @@ -302,11 +302,22 @@ AC_ARG_ENABLE([experimental-malloc], [experimental_malloc=yes]) AC_SUBST(experimental_malloc) +AC_ARG_ENABLE([crypt], + AC_HELP_STRING([--disable-crypt], + [do not build nor install the passphrase hashing library, libcrypt]), + [build_crypt=$enableval], + [build_crypt=yes]) +AC_SUBST(build_crypt) + AC_ARG_ENABLE([nss-crypt], AC_HELP_STRING([--enable-nss-crypt], [enable libcrypt to use nss]), [nss_crypt=$enableval], [nss_crypt=no]) +if test x$build_libcrypt = xno && test x$nss_crypt = xyes; then + AC_MSG_WARN([--enable-nss-crypt has no effect when libcrypt is disabled]) + nss_crypt=no +fi if test x$nss_crypt = xyes; then nss_includes=-I$(nss-config --includedir 2>/dev/null) if test $? -ne 0; then diff --git a/conform/Makefile b/conform/Makefile index 864fdeca21..74fbda0786 100644 --- a/conform/Makefile +++ b/conform/Makefile @@ -193,13 +193,11 @@ linknamespace-libs-thr = $(linknamespace-libs-isoc) \ $(common-objpfx)rt/librt.a $(static-thread-library) linknamespace-libs-posix = $(linknamespace-libs-thr) \ $(common-objpfx)dlfcn/libdl.a -linknamespace-libs-xsi = $(linknamespace-libs-posix) \ - $(common-objpfx)crypt/libcrypt.a +linknamespace-libs-xsi = $(linknamespace-libs-posix) linknamespace-libs-ISO = $(linknamespace-libs-isoc) linknamespace-libs-ISO99 = $(linknamespace-libs-isoc) linknamespace-libs-ISO11 = $(linknamespace-libs-isoc) -linknamespace-libs-XPG4 = $(linknamespace-libs-isoc) \ - $(common-objpfx)crypt/libcrypt.a +linknamespace-libs-XPG4 = $(linknamespace-libs-isoc) linknamespace-libs-XPG42 = $(linknamespace-libs-XPG4) linknamespace-libs-POSIX = $(linknamespace-libs-thr) linknamespace-libs-UNIX98 = $(linknamespace-libs-xsi) @@ -209,6 +207,11 @@ linknamespace-libs-XOPEN2K8 = $(linknamespace-libs-xsi) linknamespace-libs = $(foreach std,$(conformtest-standards),\ $(linknamespace-libs-$(std))) +ifeq ($(build-crypt),yes) +linknamespace-libs-xsi += $(common-objpfx)crypt/libcrypt.a +linknamespace-libs-XPG4 += $(common-objpfx)crypt/libcrypt.a +endif + $(linknamespace-symlist-stdlibs-tests): $(objpfx)symlist-stdlibs-%: \ $(linknamespace-libs) LC_ALL=C $(READELF) -W -s $(linknamespace-libs-$*) > $@; \ diff --git a/crypt/Makefile b/crypt/Makefile index 303800df73..3811b6e298 100644 --- a/crypt/Makefile +++ b/crypt/Makefile @@ -32,10 +32,6 @@ libcrypt-routines := crypt-entry md5-crypt sha256-crypt sha512-crypt crypt \ tests := cert md5c-test sha256c-test sha512c-test badsalttest -ifeq ($(crypt-in-libc),yes) -routines += $(libcrypt-routines) -endif - ifeq ($(nss-crypt),yes) nss-cpp-flags := -DUSE_NSS \ -I$(shell nss-config --includedir) -I$(shell nspr-config --includedir) diff --git a/elf/Makefile b/elf/Makefile index 2dcd2b88e0..5b94f8d038 100644 --- a/elf/Makefile +++ b/elf/Makefile @@ -387,14 +387,21 @@ $(objpfx)tst-_dl_addr_inside_object: $(objpfx)dl-addr-obj.os CFLAGS-tst-_dl_addr_inside_object.c += $(PIE-ccflag) endif -# By default tst-linkall-static should try to use crypt routines to test -# static libcrypt use. +# We can only test static libcrypt use if libcrypt has been built, +# and either NSS crypto is not in use, or static NSS libraries are +# available. +ifeq ($(build-crypt),no) +CFLAGS-tst-linkall-static.c += -DUSE_CRYPT=0 +else +ifeq ($(nss-crypt),no) +CFLAGS-tst-linkall-static.c += -DUSE_CRYPT=1 +else +ifeq ($(static-nss-crypt),no) +CFLAGS-tst-linkall-static.c += -DUSE_CRYPT=0 +else CFLAGS-tst-linkall-static.c += -DUSE_CRYPT=1 -# However, if we are using NSS crypto and we don't have a static -# library, then we exclude the use of crypt functions in the test. -# We similarly exclude libcrypt.a from the static link (see below). -ifeq (yesno,$(nss-crypt)$(static-nss-crypt)) -CFLAGS-tst-linkall-static.c += -UUSE_CRYPT -DUSE_CRYPT=0 +endif +endif endif include ../Rules @@ -1115,7 +1122,6 @@ localplt-built-dso := $(addprefix $(common-objpfx),\ rt/librt.so \ dlfcn/libdl.so \ resolv/libresolv.so \ - crypt/libcrypt.so \ ) ifeq ($(build-mathvec),yes) localplt-built-dso += $(addprefix $(common-objpfx), mathvec/libmvec.so) @@ -1123,6 +1129,9 @@ endif ifeq ($(have-thread-library),yes) localplt-built-dso += $(filter-out %_nonshared.a, $(shared-thread-library)) endif +ifeq ($(build-crypt),yes) +localplt-built-dso += $(addprefix $(common-objpfx), crypt/libcrypt.so) +endif vpath localplt.data $(+sysdep_dirs) @@ -1397,6 +1406,7 @@ $(objpfx)tst-linkall-static: \ $(common-objpfx)resolv/libanl.a \ $(static-thread-library) +ifeq ($(build-crypt),yes) # If we are using NSS crypto and we have the ability to link statically # then we include libcrypt.a, otherwise we leave out libcrypt.a and # link as much as we can into the tst-linkall-static test. This assumes @@ -1412,6 +1422,7 @@ ifeq (no,$(nss-crypt)) $(objpfx)tst-linkall-static: \ $(common-objpfx)crypt/libcrypt.a endif +endif # The application depends on the DSO, and the DSO loads the plugin. # The plugin also depends on the DSO. This creates the circular diff --git a/elf/tst-linkall-static.c b/elf/tst-linkall-static.c index e8df38f74e..d0f2592e67 100644 --- a/elf/tst-linkall-static.c +++ b/elf/tst-linkall-static.c @@ -18,7 +18,9 @@ #include <math.h> #include <pthread.h> -#include <crypt.h> +#if USE_CRYPT +# include <crypt.h> +#endif #include <resolv.h> #include <dlfcn.h> #include <utmp.h> diff --git a/manual/install.texi b/manual/install.texi index 4bbbfcffa5..6e18f85b8b 100644 --- a/manual/install.texi +++ b/manual/install.texi @@ -230,6 +230,18 @@ libnss_nisplus are not built at all. Use this option to enable libnsl with all depending NSS modules and header files. +@item --disable-crypt +Do not install the passphrase-hashing library @file{libcrypt} or the +header file @file{crypt.h}. @file{unistd.h} will still declare the +function @code{crypt}, as required by POSIX@. Using this option does +not change the set of programs that may need to be linked with +@option{-lcrypt}; it only means that @theglibc{} will not provide that +library. + +This option is for hackers and distributions experimenting with +independently-maintained implementations of libcrypt. It may become +the default in a future release. + @item --disable-experimental-malloc By default, a per-thread cache is enabled in @code{malloc}. While this cache can be disabled on a per-application basis using tunables