Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117094 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 88282 invoked from network); 21 Feb 2022 10:44:47 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 21 Feb 2022 10:44:47 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D0B3A18053E for ; Mon, 21 Feb 2022 04:03:56 -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=-0.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 21 Feb 2022 04:03:56 -0800 (PST) Received: by mail-ej1-f52.google.com with SMTP id a8so32730132ejc.8 for ; Mon, 21 Feb 2022 04:03:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=syPrjiAW7oFpi9u6sBliO9JzliYSnLo1wigvFqDnMwo=; b=B+4LdijB1G0acNhnz8yG9AId/Mv2unnB8aJw7X5S0HJsljCHJMuJfsl0yhG94I0Ash jvzuqR1wLORYSEIv21SmaZRw8VT7HHyfJMCkUo1mPF28cSA5I0GF7/kvqcFIHIkwJe1B GwTC50ukXloBqOIAwKFPceJK8mzRIOMS1GVw0r5RjLKOg6sIBtUWcrsQv2euem7BQ1Qe RtVmjzxxsn6mGbneSLp4QCpUXI3QpfOkDL8wO28gj7AKozyDhj+JOzjIAD0nnAB5m7S5 bP3uuazJ5SuraYm9Zz1rcav0fAYIizyLTHxrmNyWX4ZO47jByQpko3xZfp/BEG/Pr51W pE+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=syPrjiAW7oFpi9u6sBliO9JzliYSnLo1wigvFqDnMwo=; b=DPaQUMG3oh7PqQm8dujjhvw9kyQfaAzLca1dlJkdrsq6qW9r4qAGW77/EgH98+mV9P +E+bxzVnD/zgkOdqEngPQz6ZLCeqwtcyE48iIolL1sK5QNeNZ/JeN5QTQfab4jJqhMkA hNRMCMze7eE2Aqn+vRMIOBIKPFVYQWJ07okubCqM348ePWm8TDFtOgFIex/QaCcDrciG uAHwKh6HqtKqbGzQDtPn4072Wx/zN/omKM4yfiTeiUKMR6vObQcSgZsyPix5Dp1jBt0S vWkmL/lzRMoCzfvd611ZCB9DMMeOj/MkD98MrC3hvd4STCfRuB9i7HMxi24HLJ0XyFVJ yo8w== X-Gm-Message-State: AOAM533AKTl06yizKzfjtc5KYDrZWEL/+Ig9Ut4IUGgfYuGadp4YiwAG GkyNcI3rW+LYcfh0sbIYY7axuxLqoLyIvcR2+5mc57JISAs= X-Google-Smtp-Source: ABdhPJyuDFhyQ+GbhnA4OQFAY37nDjQpdMYVg6p+y4y7bBsjhK1E5M9kcIyikgtmItlzzwCEiia6rBfNKcAADGsjtL8= X-Received: by 2002:a17:906:2319:b0:6c9:76c4:8ac6 with SMTP id l25-20020a170906231900b006c976c48ac6mr15707387eja.387.1645445034955; Mon, 21 Feb 2022 04:03:54 -0800 (PST) MIME-Version: 1.0 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> <7527ab0b-bed1-6788-a0ff-e75672054be7@bastelstu.be> In-Reply-To: Date: Mon, 21 Feb 2022 13:03:16 +0100 Message-ID: Cc: PHP Internals List Content-Type: multipart/alternative; boundary="000000000000ce579d05d8860633" Subject: Re: [PHP-DEV] RFC proposal to deprecate crypt() From: divinity76@gmail.com (Hans Henrik Bergan) --000000000000ce579d05d8860633 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable fwiw i recall a real-world script modifying a linux system's /etc/passwd / /etc/shadow using crypt() because password_hash() couldn't create passwd/shadow-compatible hashes while crypt() could On Mon, 21 Feb 2022 at 12:49, Marco Pivetta wrote: > On Mon, Feb 21, 2022 at 12:39 PM Tim D=C3=BCsterhus wr= ote: > > > Hi > > > > On 2/21/22 12:12, Marco Pivetta wrote: > > >>>> If it's not going to be removed, what's the point of annoying peop= le > > >>>> with deprecation warnings (that they would patch out/silence > anyway)? > > >>>> > > >>> > > >>> Probably to be removed in `9.0` or `10.0`? Yes, it should be remove= d > at > > >>> some point. > > >> > > >> In contrast to other deprecations (e.g. the utf8_encode/decode > currently > > >> discussed), deprecating and ultimately removing crypt() results in a= n > > >> actual loss of functionality. > > >> > > > > > > ...yes? That's the point? > > > > > > > I understand that that's the point. However I agree with Stas that this > > would be a BC break with no practical gain and I articulated the reason= s > > why I believe that: If crypt() is what you need, then crypt() is what > > you need and being told that your use-case is invalid is not helping > > you. The function already exists and I assume that it does not require > > (relevant) maintenance effort for PHP maintainers keeping it. > > > > Not a maintenance effort exercise, but a user education exercise. > Users need to stop using `crypt()`, because it just has to stop, period. > They have a period of time to migrate away from it, and then they will ge= t > a hard crash when it's gone-gone-gone, which is **OK**. > > In addition to that, end-users of PHP-SRC are not paying customers to the > php foundation, and their systems will keep rotting until they will final= ly > have to touch them: it would be a different story if there was a LTS > contract in place, but that's not how OSS works. > > They can also polyfill it with whatever crazy and broken contraption work= s > for them, as long as they take the irresponsible security decision upon > themselves. > > Calibrated code and feature removal is part of the software maintenance > process, and it has more effects than just code size increase. > > > > > With the same arguments one could deprecate and remove md5() (and > > possibly sha1() as well). It should not be used for passwords, it shoul= d > > not be used for signatures and any new use should require *careful* > > review. Nonetheless there are cases where you still need an > > implementation of md5() and then not having md5() is an issue. > > > > If someone proposed the removal of md5() I'd disagree the same. > > > > As mentioned elsewhere in the mail thread, `crypt()` is not designed for > fast hashing, and is in fact slow by design. > MD5 and SHA1 still have a place, compared to that, as they are not design= ed > solely for password hashing. > > This is part of "calibrated code and feature removal" from above. > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.io/ > --000000000000ce579d05d8860633--