Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117089 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 76148 invoked from network); 21 Feb 2022 08:51:47 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 21 Feb 2022 08:51:47 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id ECABB18053C for ; Mon, 21 Feb 2022 02:10:58 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS24940 176.9.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from chrono.xqk7.com (chrono.xqk7.com [176.9.45.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 21 Feb 2022 02:10:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bastelstu.be; s=mail20171119; t=1645438256; bh=9EO9qKIlAzRnTwXo5Dy9sqlfveNNKv+EFi7ec42vvN0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=SrdI1Cjo4JZkuiia8+avPVW0M3dyDwhup1f9ll6Ybo7WDVYLba6HJVXZ136AIcaKA yjztYvcFE6P+6mlf+Yag/Mx4MqVDKG9HfApRIpZ3/Gd9CYTSwl5eKKSinkh3hUlA2n mM16AmcLAs6CpbkXu3vctVYX+4Qbe3BbcW8Jszj58UA+Kf/zGk1/jxW1s8CpXYBcA4 PL7ASDUCCEP4ovw93yPw0Udmb1/Ih4/On9eM/+FXZ5vIM2EJJqXdX5xvS8CfZG9mf5 La9gdqwkbehgdnS2+vL1+HItMWSO++WZG8/GkTQbumrA6kwXFjgjhUV3dKk7Itzgbj xMV5UlfD7utPQ== Message-ID: Date: Mon, 21 Feb 2022 11:10:56 +0100 MIME-Version: 1.0 Content-Language: en-US To: Marco Pivetta , Stanislav Malyshev Cc: PHP Internals List References: <5983302.2649742.1645319015766@email.ionos.com> <6238bf00-011e-35cc-d84b-4082b4f05099@gmail.com> <497325306.1564942.1645357444018@email.ionos.com> <3c6871ca-589d-6812-800c-a3b9ad6bb575@bastelstu.be> <40015164-ac0c-336d-c7d6-c4766d6caff8@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] RFC proposal to deprecate crypt() From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=) Hi Marco On 2/21/22 10:15, Marco Pivetta wrote: >> If it's not going to be removed, what's the point of annoying people >> with deprecation warnings (that they would patch out/silence anyway)? >> > > Probably to be removed in `9.0` or `10.0`? Yes, it should be removed at > some point. In contrast to other deprecations (e.g. the utf8_encode/decode currently discussed), deprecating and ultimately removing crypt() results in an actual loss of functionality. Even if we leave out that home-grown nested BCrypt hashing out of the picture, crypt() allows one to interoperate with non-PHP-software that does not support BCrypt, but supports the SHA-X variants. I already mentioned Dovecot as an example, but BCrypt support in glibc in general is something that was added only somewhat recently (and I'm not even sure if that's only for Debian-based systems or generally available [1]). Yes, users should just use password_hash() if they need to hash passwords. Yes, the documentation for crypt() should more prominently point to password_hash() as the better alternative. But if crypt()'s features are what you need, then alternatives to crypt() (e.g. a userland implementation or FFI) certainly are going to be even worse. Best regards Tim Düsterhus [1] https://sourceware.org/bugzilla/show_bug.cgi?id=16814