Message ID | 87zfz7gnrs.fsf@oldenburg.str.redhat.com |
---|---|
State | New |
Headers | show |
Series | posix: Revert the removal of the crypt prototype from <unistd.h> | expand |
On Tue, Nov 21, 2023, at 9:54 AM, Florian Weimer wrote: > Many applications still rely on this prototype. Rebuilds without this > prototype result in an implicit function declaration, which can > introduce security vulnerabilities due to 32-bit pointer truncation. Did you consider __attribute_deprecated_msg__("include <crypt.h> for the crypt prototype")? ...I guess we can't do that if it'd still generate a deprecation warning when _both_ unistd.h and crypt.h are included (in either order), though. Otherwise LGTM. zw
* Zack Weinberg: > On Tue, Nov 21, 2023, at 9:54 AM, Florian Weimer wrote: >> Many applications still rely on this prototype. Rebuilds without this >> prototype result in an implicit function declaration, which can >> introduce security vulnerabilities due to 32-bit pointer truncation. > > Did you consider __attribute_deprecated_msg__("include <crypt.h> for the > crypt prototype")? ...I guess we can't do that if it'd still generate a > deprecation warning when _both_ unistd.h and crypt.h are included (in either > order), though. Current GCC produces a warning if <unistd.h> followed by <crypt.h>, with a note that points towards the non-deprecated declaration. This is rather confusing. In general, attributes are not superseded by redeclarations. So I don't think the attribute is an option here. Thanks, Florian
On Tue, Nov 21, 2023, at 10:42 AM, Florian Weimer wrote: > * Zack Weinberg: >> On Tue, Nov 21, 2023, at 9:54 AM, Florian Weimer wrote: >>> Many applications still rely on this prototype. Rebuilds without this >>> prototype result in an implicit function declaration, which can >>> introduce security vulnerabilities due to 32-bit pointer truncation. >> >> Did you consider __attribute_deprecated_msg__("include <crypt.h> for the >> crypt prototype")? ...I guess we can't do that if it'd still generate a >> deprecation warning when _both_ unistd.h and crypt.h are included (in either >> order), though. > > Current GCC produces a warning if <unistd.h> followed by <crypt.h>, with > a note that points towards the non-deprecated declaration. Yeah, I was afraid of that. Oh well. zw
diff --git a/NEWS b/NEWS index 139cfef1b0..8c1c149f91 100644 --- a/NEWS +++ b/NEWS @@ -52,7 +52,10 @@ Deprecated and removed features, and other changes affecting compatibility: * libcrypt has been removed from the GNU C Library. The configure options "--enable-crypt" and "--enable-nss-crypt" are no longer available. <crypt.h>, libcrypt.a, and libcrypt.so.1 will not be - installed, and <unistd.h> will not declare the crypt function. + installed. For now <unistd.h> continues to declare the crypt + function by default, to avoid introducing vulnerabilities into + existing applications due to a missing prototype. This declaration + is deprecated and may be removed in a future glibc release. The replacement for libcrypt is libxcrypt, maintained separately from GNU libc, but available under compatible licensing terms, and providing diff --git a/posix/unistd.h b/posix/unistd.h index 1f9cd8cbf0..5b91ad4aaa 100644 --- a/posix/unistd.h +++ b/posix/unistd.h @@ -1150,6 +1150,19 @@ ssize_t copy_file_range (int __infd, __off64_t *__pinoff, extern int fdatasync (int __fildes); #endif /* Use POSIX199309 */ +#ifdef __USE_MISC +/* One-way hash PHRASE, returning a string suitable for storage in the + user database. SALT selects the one-way function to use, and + ensures that no two users' hashes are the same, even if they use + the same passphrase. The return value points to static storage + which will be overwritten by the next call to crypt. + + This declaration is deprecated; applications should include + <crypt.h> instead. */ +extern char *crypt (const char *__key, const char *__salt) + __THROW __nonnull ((1, 2)); +#endif + #ifdef __USE_XOPEN /* Swab pairs bytes in the first N bytes of the area pointed to by FROM and copy the result to TO. The value of TO must not be in the