# [RFC] [VOTE] Deprecations for PHP 8.4 - Thread: https://externals.io/message/124506 - Original archive: https://news-web.php.net/php.internals/124506 - Started by Gina P. Banyard on 2024-07-19T17:39:55+00:00 - Messages: 97 - RFC: Deprecations for PHP 8.4 (Accepted) — https://externals.io/rfc/deprecations_php_8_4.md - Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/124506.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #124506 — Gina P. Banyard — 2024-07-19T17:39:55+00:00 URL: https://externals.io/message/124506#124506 Hello internals, I have opened the vote for the mega deprecation RFC: https://wiki.php.net/rfc/deprecations_php_8_4 Reminder, each vote must be submitted individually. Best regards, Gina P. Banyard --- ## #124544 — Jakub Zelenka — 2024-07-22T10:59:53+00:00 URL: https://externals.io/message/124506#124544 · In reply to: #124506 Hi, > Hello internals, > > I have opened the vote for the mega deprecation RFC: > https://wiki.php.net/rfc/deprecations_php_8_4 > > Reminder, each vote must be submitted individually. > > > Just wanted to send some reasoning of my no votes. I voted no on those output handlers as there might be potentially better solutions. The whole output stuff needs a closer look so I think we should wait on this until the review is done. Otherwise I also voted no for the mysqli_kill and mysqli_refresh functions as I feel that it's not a big deal to keep them (zero maintenance basically) and there will be likely users to use them. I think it would make sense to not add them but if there are already there I don't see a point to remove them. I think we should also keep file_put_contents array argument as it might actually be used with iovec in the future which could be a significant optimization - need to check details if that would work but if it does, it could be a pretty good optimization. The CSV one is also a bit weird because the default is non empty parameter so I'm not sure what this actually brings except some inconsistency. People that explicitly set it, do that probably for some reason. I would really prefer not to try to change this functionality as the BC breaks will cause more issues. All my other no are mainly about the BC concerns that I have. Regards Jakub --- ## #124545 — Jakub Zelenka — 2024-07-22T11:39:24+00:00 URL: https://externals.io/message/124506#124545 · In reply to: #124544 > I think we should also keep file_put_contents array argument as it might > actually be used with iovec in the future which could be a significant > optimization - need to check details if that would work but if it does, it > could be a pretty good optimization. > I had a bit closer look on this one and it should be possible to optimize it for some cases. We could basically introduce something like php_stream_writev. It would need to have logic to do the same sort concatenation if filters used or for stream wrappers not supporting iovec. But for plain wrapper, we should be able to support it and it could be a good optimization for some users and a way how to cleanly expose it. So I would suggest to remove this from this list as there seems to be a good use case for this functionality. Regards Jakub --- ## #124548 — Derick Rethans — 2024-07-22T16:04:23+00:00 URL: https://externals.io/message/124506#124548 · In reply to: #124506 > Hello internals, > > I have opened the vote for the mega deprecation RFC: > https://wiki.php.net/rfc/deprecations_php_8_4 > > Reminder, each vote must be submitted individually. I have voted no for a few, as they had no impact assesment at all: - Deprecate returning non-string values from a user output handler - Deprecate `lcg_value()` - Deprecate `md5()`, `sha1()`, `md5_file()`, and `sha1_file()` (just says "large impact") - Deprecate SOAP_FUNCTIONS_ALL constant and passing it to SoapServer::addFunction() And no on a few others: - Deprecate using a single underscore ''_'' as a class name (it breaks some of my ... old slides — but I also don't really the problem with this. - Remove the `E_STRICT` Error Level and Deprecate the `E_STRICT` constant? (Because I added it :-) ) cheers, Derick --- ## #124556 — Matthew Weier O'Phinney — 2024-07-23T13:42:06+00:00 URL: https://externals.io/message/124506#124556 · In reply to: #124506 > Hello internals, > > I have opened the vote for the mega deprecation RFC: > https://wiki.php.net/rfc/deprecations_php_8_4 > > Reminder, each vote must be submitted individually. > > > Best regards, > > > Gina P. Banyard > The section "Deprecate using a single underscore ''_'' as a class name" indicates that probably the primary reason to deprecate it is a potential future conflict in the pattern matching RFC, where it can be used as a wildcard. However, I see no mention of this character as a wildcard anywhere in that RFC. Can somebody clarify? -- Matthew Weier O'Phinney mweierophinney@gmail.com https://mwop.net/ he/him --- ## #124557 — Larry Garfield — 2024-07-23T14:04:18+00:00 URL: https://externals.io/message/124506#124557 · In reply to: #124556 > > > […] > > > The section "Deprecate using a single underscore ''_'' as a class name" > indicates that probably the primary reason to deprecate it is a > potential future conflict in the pattern matching RFC, where it can be > used as a wildcard. > > However, I see no mention of this character as a wildcard anywhere in that RFC. > > Can somebody clarify? The pattern matching RFC previously listed _ as a wildcard character. In the discussion a month ago, someone pointed out that `mixed` already serves that exact purpose, so having an extra wildcard was removed. However, a few people indicated a desire to have an explicit wildcard _ anyway, even if it's redundant, as it's a more common and standard approach in other languages. We've indicated that we are open to making that an optional secondary vote in the pattern matching RFC if there's enough interest (it would be trivial), though I haven't bothered to add it to the RFC text yet. Having _ available could also be used in other "wildcard" or "ignore this" cases, like exploding into a list assignment or similar, though I don't believe that has been fully explored. That's the context/background here. Whether that encourages you to vote for or against that section I leave as an exercise for the reader. --Larry Garfield --- ## #124558 — Christoph M. Becker — 2024-07-23T14:32:47+00:00 URL: https://externals.io/message/124506#124558 · In reply to: #124544 Hi Jakub! > > > > […] > > Just wanted to send some reasoning of my no votes. > > The CSV one is also a bit weird because the default is non empty parameter > so I'm not sure what this actually brings except some inconsistency. People > that explicitly set it, do that probably for some reason. I would really > prefer not to try to change this functionality as the BC breaks will cause > more issues. The default "\\" likely causes more harm than good for almost anybody. It basically enables a proprietary extension to CSV (something like DSV), but there are a couple of issues where it is totally unclear what should happen, and there still might be unresolved (because unresolvable) tickets lying around about that. I do have to agree, though, that this deprecation is somewhat unfortunate, since an empty string is only accepted as of PHP 7.4.0, so there is likely some code around which passes e.g. "\0" which also disables the proprietary extension if there are no NUL bytes in the CSV file (or to be written to a CSV file). For that reason I didn't vote on that deprecation, although I would not like to keep that proprietary extension forever. Cheers, Christoph --- ## #124559 — Christoph M. Becker — 2024-07-23T14:41:27+00:00 URL: https://externals.io/message/124506#124559 · In reply to: #124557 > > > > […] > > The pattern matching RFC previously listed _ as a wildcard character. > > In the discussion a month ago, someone pointed out that `mixed` already serves that exact purpose, so having an extra wildcard was removed. > > However, a few people indicated a desire to have an explicit wildcard _ anyway, even if it's redundant, as it's a more common and standard approach in other languages. We've indicated that we are open to making that an optional secondary vote in the pattern matching RFC if there's enough interest (it would be trivial), though I haven't bothered to add it to the RFC text yet. > > Having _ available could also be used in other "wildcard" or "ignore this" cases, like exploding into a list assignment or similar, though I don't believe that has been fully explored. > > That's the context/background here. Whether that encourages you to vote for or against that section I leave as an exercise for the reader. Well, I wonder how that is supposed to work. Assuming the underscore would be used as wildcard in a class name context, that could only be done after using that character as class name is no longer allowed. So that would have to wait for the next major PHP version (at least). Note that I'm not worried about no longer being able to use an underscore as class name, but rather that this introduces another inconsistency to our indentifiers. Disallowing an underscore as function name is obviously off the table, thanks to gettext. Christoph --- ## #124560 — Larry Garfield — 2024-07-23T14:54:30+00:00 URL: https://externals.io/message/124506#124560 · In reply to: #124559 > > > > […] > > Well, I wonder how that is supposed to work. Assuming the underscore > would be used as wildcard in a class name context, that could only be > done after using that character as class name is no longer allowed. So > that would have to wait for the next major PHP version (at least). > > Note that I'm not worried about no longer being able to use an > underscore as class name, but rather that this introduces another > inconsistency to our indentifiers. Disallowing an underscore as > function name is obviously off the table, thanks to gettext. > > Christoph I think someone checked and found no examples of someone using _ as a class name, so the impact of removing it and/or using it for something else would be nearly nil. That may still push _ as a wildcard out to a future version, but I leave that up to others. As I said, I don't have strong feelings either way. --Larry Garfield --- ## #124561 — Matthew Weier O'Phinney — 2024-07-23T16:00:40+00:00 URL: https://externals.io/message/124506#124561 · In reply to: #124557 On Tue, Jul 23, 2024 at 9:06 AM Larry Garfield wrote: > > > […] > wrote: > > […] > that RFC. > > […] > > The pattern matching RFC previously listed _ as a wildcard character. > > In the discussion a month ago, someone pointed out that `mixed` already > serves that exact purpose, so having an extra wildcard was removed. > > However, a few people indicated a desire to have an explicit wildcard _ > anyway, even if it's redundant, as it's a more common and standard approach > in other languages. We've indicated that we are open to making that an > optional secondary vote in the pattern matching RFC if there's enough > interest (it would be trivial), though I haven't bothered to add it to the > RFC text yet. > > Having _ available could also be used in other "wildcard" or "ignore this" > cases, like exploding into a list assignment or similar, though I don't > believe that has been fully explored. > Can you provide examples of what that usage would look like? And the question I have really is, does this actually _require_ using "_", or could another token be used for such matches? -- Matthew Weier O'Phinney mweierophinney@gmail.com https://mwop.net/ he/him --- ## #124562 — Larry Garfield — 2024-07-23T16:26:59+00:00 URL: https://externals.io/message/124506#124562 · In reply to: #124561 > > […] > > Can you provide examples of what that usage would look like? And the > question I have really is, does this actually _require_ using "_", or > could another token be used for such matches? Hypothetical pattern matching example: $foo is ['a' => int, 'b' => $b, 'c' => mixed]; That would assert that there's 3 keys. "a" may be any integer (but only an integer), "b" can be anything and will be captured to a variable, and "c" must be defined but we don't care what it is. The suggestion is to basically alias _ to "mixed" for pattern purposes: $foo is ['a' => int, 'b' => $b, 'c' => _]; As "there's a var here but I don't care what it is, ignore it" is a common meaning of _ in other languages. But that would need to be disambiguated from a pattern saying "c must be an instance of the class _". Technically any symbol/set of symbols could be used there (as it's just an alias to mixed, which has the exact same effect), but _ is a common choice in other languages. In theory, that could be expanded in the future to something like (note: this hasn't been seriously discussed that I know of, I'm just spitballing randomly): [$a, $b, _] = explode(':', 'foo:bar:baz'); To assign $a = "foo", $b to "bar", and just ignore "baz". Which might cause parser issues if _ is a legal class name, I'm not sure. There's probably other "ignore this" cases we could come up with, but I haven't actually thought about it. Again, whether any of the above is a compelling argument or not I leave as an exercise for the reader. --Larry Garfield --- ## #124564 — Peter Stalman — 2024-07-24T03:58:56+00:00 URL: https://externals.io/message/124506#124564 · In reply to: #124548 > - Deprecate `md5()`, `sha1()`, `md5_file()`, and `sha1_file()` (just says "large > impact") About 1.2 million. https://github.com/search?q=%28md5+OR+md5_file+OR+sha1+OR+sha1_file%29+language%3APHP+&type=code The proposed deprecation of these functions in PHP due to their cryptographic insecurities seems to overlook their valid non-cryptographic applications. If we consider the context, the scope of cryptographic usage is already quite specific. We're talking about end users who are rolling their own security implementations and are unaware of the security risks but somehow know how to use these functions without reading the documentation and warnings. The number of people who fall into this specific category is quite small. Yet, this change is being proposed for their sake. It's important to note that these same users could/will easily make other security mistakes regardless of this deprecation. On the other hand, who will be impacted by these deprecations? Potentially everyone, as these are included in many projects and in many vendor packages. It's busy work for the people who aren't affected. Sure, eventually, it will all be sorted out as CI warnings slowly subside because of this. Reasons such as GIT and most cloud storages using these functions should be enough to spare them. Example: https://rclone.org/overview/ The point is that there are several reasons in 2024 to use md5 and sha1. Granted hashing passwords isn't one, but we're past that as a community already. And for the few that aren't, I'd argue there is no saving. Thanks, Peter --- ## #124567 — Mike Schinkel — 2024-07-24T09:47:54+00:00 URL: https://externals.io/message/124506#124567 · In reply to: #124562 > > > Hypothetical pattern matching example: > > $foo is ['a' => int, 'b' => $b, 'c' => mixed]; > > That would assert that there's 3 keys. "a" may be any integer (but only an integer), "b" can be anything and will be captured to a variable, and "c" must be defined but we don't care what it is. > > The suggestion is to basically alias _ to "mixed" for pattern purposes: > > $foo is ['a' => int, 'b' => $b, 'c' => _]; > > As "there's a var here but I don't care what it is, ignore it" is a common meaning of _ in other languages. But that would need to be disambiguated from a pattern saying "c must be an instance of the class _". Technically any symbol/set of symbols could be used there (as it's just an alias to mixed, which has the exact same effect), but _ is a common choice in other languages. I do not see this use-case as compelling. `mixed` is perfectly sufficient and using `_` for a data types just gives two ways to do the same. Not that multiple ways to do the same thing is necessarily wrong, but I think it needs a better justification than just to save characters. Besides, it has the potential to confuse people as to its exact meaning whereas `mixed` does not. OTOH, if you really want to say characters — albeit not as many — then choose `any`, which is certainly less likely to be confusing and has an analog in Go, TypeScript, and Python, at least. Also, AFAIK, few (no?) other languages actually allow for using `_` for types, they only allow using them for variables. I know that to be the case for Go, and if I understand the docs correctly it is also true for Rust, Zig, Haskell and Swift, with caveats for Rust. - Rust allows underscore for type inference, e.g.: let x: _ = "Hello, world!"; - Also for a Generics' type placeholder, e.g.: let vec: Vec<_> = vec![1, 2, 3]; - But as for Rust pattern matching, the underscore is only used for values, not types. For any other languages, I cannot say. > In theory, that could be expanded in the future to something like (note: this hasn't been seriously discussed that I know of, I'm just spitballing randomly): > > [$a, $b, _] = explode(':', 'foo:bar:baz'); This is actually where a "blank" variable represented by `_` actually makes a lot of sense. It is also how Go and Zig use them and effectively also how Rust, Haskell, and Swift use them. Unlike for types where we have `mixed`, there is no current globally consistent alternate to using a blank variable in PHP. The only option is to use an arbitrary name that other developers won't know the intention of unless the developer adds comments to the effect. In summary, although I don't have strong feelings about deprecating classes named `_`, I do not think the arguments made for disallowing them actually have any analog in any other languages so I question if there is valid justification for the deprecation. #jmtcw #fwiw -Mike --- ## #124584 — Morgan — 2024-07-24T22:01:15+00:00 URL: https://externals.io/message/124506#124584 · In reply to: #124564 > On Mon, Jul 22, 2024 at 9:06 AM Derick Rethans > wrote: > > - Deprecate `md5()`, `sha1()`, `md5_file()`, and `sha1_file()` (just says > "large >   impact") > > > About 1.2 million. > https://github.com/search?q=%28md5+OR+md5_file+OR+sha1+OR+sha1_file%29+language%3APHP+&type=code > > > On the other hand, who will be impacted by these deprecations? > Potentially everyone, as these are included in many projects and in many > vendor packages.  It's busy work for the people who aren't affected. > Sure, eventually, it will all be sorted out as CI warnings slowly > subside because of this. > > Reasons such as GIT and most cloud storages using these functions should > be enough to spare them. Example: https://rclone.org/overview/ > > > The point is that there are several reasons in 2024 to use md5 and sha1. > Granted hashing passwords isn't one, but we're past that as a community > already. And for the few that aren't, I'd argue there is no saving. > And they would still be available as hash("md5") and hash("sha1"); the only reason they're called out as their own distinct functions today is historical inertia. --- ## #124586 — Peter Stalman — 2024-07-25T05:33:28+00:00 URL: https://externals.io/message/124506#124586 · In reply to: #124584 > And they would still be available as hash("md5") and hash("sha1"); the > only reason they're called out as their own distinct functions today is > historical inertia. > Yes, I am aware of that, it's covered in the RFC and has been discussed. My issue is that I think the positive effect this will have is minimal, while the impact is very extensive. I also disagree with the notion that there is no longer a use for these algos in the present day, as there are many technologies and systems that still use these for basic checksumming. To make everyone go through and update these seems ridiculous to me, as it's basically just **renaming functions**. If it goes through, I foresee a composer package called md5-sha1-shim being a popular package. It won't stop the people this intends to save. Lots of effect with little gain. The warning in the documentation should be sufficient. Thanks, Peter --- ## #124588 — tim@bastelstu.be — 2024-07-25T15:33:16+00:00 URL: https://externals.io/message/124506#124588 · In reply to: #124564 Hi > is already quite specific. We're talking about end users who are rolling > their own security implementations and are unaware of the security risks > but somehow know how to use these functions without reading the > documentation and warnings. No, we are talking about end users who are following tutorials that were written when PHP 4 was the most recent PHP version. We are also talking about end users who look at existing code bases for "inspiration", see `md5()` used, notice that the output looks random and use it, believing they know what they are doing, but in that process use it in a way that is insecure. As an example, using `md5_file()` to implement a cache buster is fine, but a less-experienced developer may believe that `md5_file()` uniquely identifies the file contents and use it in a way where strong collision-resistance against an adversary is required. > On the other hand, who will be impacted by these deprecations? Potentially > everyone, as these are included in many projects and in many vendor > packages. It's busy work for the people who aren't affected. Sure, > eventually, it will all be sorted out as CI warnings slowly subside because > of this. I'm positive that even existing projects written by experienced developers would benefit from re-checking if their use of MD5 and SHA-1 is actually safe instead of assuming that this is the case, when the specific functionality has been untouched for the last 10 years. Looking back at my own code, I'm seeing places where using SHA-1 is not strictly insecure, but where a stronger hash function nevertheless would have been more appropriate, if only to simplify code audits. I just used `sha1()`, because it was temptingly convenient compared to hash('sha256', …). Best regards Tim Düsterhus --- ## #124591 — Nick Lockheart — 2024-07-25T17:28:51+00:00 URL: https://externals.io/message/124506#124591 · In reply to: #124588 > > As an example, using `md5_file()` to implement a cache buster is fine, > but a less-experienced developer may believe that `md5_file()` uniquely > identifies the file contents and use it in a way where strong > collision-resistance against an adversary is required. > > I'm positive that even existing projects written by experienced > developers would benefit from re-checking if their use of MD5 and > SHA-1 is actually safe instead of assuming that this is the case, > when the specific functionality has been untouched for the last 10 > years. Isn't the philosophy of open source software "tools, not policy"? I'm in the process of refactoring an old framework and I just found a use of `sha1()`. It's being used to generate a unique resource lock. It doesn't need to be secure, just a fast and random UID. --- ## #124592 — tim@bastelstu.be — 2024-07-25T18:35:38+00:00 URL: https://externals.io/message/124506#124592 · In reply to: #124591 Hi > I'm in the process of refactoring an old framework and I just found a > use of `sha1()`. It's being used to generate a unique resource lock. It > doesn't need to be secure, just a fast and random UID. SHA-1 is a deterministic algorithm, thus it is unable to generate a random UID. Whatever this code is doing can most likely be more reliably achieved in a different way. Best regards Tim Düsterhus --- ## #124593 — Rowan Tommins [IMSoP] — 2024-07-25T21:34:08+00:00 URL: https://externals.io/message/124506#124593 · In reply to: #124584 > And they would still be available as hash("md5") and hash("sha1"); the > only reason they're called out as their own distinct functions today > is historical inertia. I don't agree that the reasons for including standalone functions are "historical". The RFC itself gives a good reason for having such functions: > Unfortunately these cryptographically secure hash functions are only available by means of the generic `hash()` function ... making using them more verbose and thus seemingly more complicated Rather than force people to use functions that we acknowledge are hard to use, surely the logical thing is to make the "right" code *easy* to use? Which means if we want people to use SHA-256, let's add a sha256() function to make it easy. This is what `password_hash()` and `password_verify()` did right: the functionality was already there in `crypt()`, but it's hard to use, and harder to use correctly. Providing clearer functions, even though they do the same thing, helps new developers "fall into the pit of success". The `hash()` function isn't quite as confusing as `crypt()`, but according to the manual, it currently supports 60 different algorithms, most of which I have never heard of. I'm aware that "sha256" is better than "sha1", but should I be aiming higher, and using "sha384", or maybe one of the four flavours of "sha3"? Then there's the fun-sounding "whirlpool", the faintly rude-sounding "snefru", and a bewildering fifteen flavours of "haval". A new user being told "don't use `sha1()`, use `hash()` and pick from this list" is more likely to say "ah, there's sha1, jolly good" than spend an afternoon reading cryptography journals. There's no pit of success to fall into. Regards, -- Rowan Tommins [IMSoP] --- ## #124594 — Nick Lockheart — 2024-07-25T22:00:51+00:00 URL: https://externals.io/message/124506#124594 · In reply to: #124593 > > > […] > > > I don't agree that the reasons for including standalone functions are > "historical". The RFC itself gives a good reason for having such > functions: > >  > Unfortunately these cryptographically secure hash functions are > only > available by means of the generic `hash()` function ... making using > them > more verbose and thus seemingly more complicated > > > Rather than force people to use functions that we acknowledge are > hard > to use, surely the logical thing is to make the "right" code *easy* > to use? > > Which means if we want people to use SHA-256, let's add a sha256() > function to make it easy. > > > This is what `password_hash()` and `password_verify()` did right: the > functionality was already there in `crypt()`, but it's hard to use, and > harder to use correctly. Providing clearer functions, even though > they > do the same thing, helps new developers "fall into the pit of > success". > > The `hash()` function isn't quite as confusing as `crypt()`, but > according > to the manual, it currently supports 60 different algorithms, most of > which I have never heard of. I'm aware that "sha256" is better than > "sha1", but should I be aiming higher, and using "sha384", or maybe > one > of the four flavours of "sha3"? Then there's the fun-sounding > "whirlpool", the faintly rude-sounding "snefru", and a bewildering > fifteen flavours of "haval". > > A new user being told "don't use `sha1()`, use `hash()` and pick from > this > list" is more likely to say "ah, there's sha1, jolly good" than spend > an > afternoon reading cryptography journals. There's no pit of success to > fall into. > > > Regards, > That's a good point. What if there were crypto functions that worked like `password_hash()` in that they had one generic function name, but magically used the new/better "best practice" algorithms as time went by without the need to update any calling code? Maybe there should be three generic-named functions: fast_hash() // not secure, makes UIDs quickly secure_hash() // uses best practice one-way hash algo secure_crypt() // uses best practice reversible encryption. Then the developer signals their *intent* by choosing a function name, and the algorithm magically works underneath (perhaps with the option of an ini override to make those functions work in different environments). --- ## #124595 — Mike Schinkel — 2024-07-25T22:22:17+00:00 URL: https://externals.io/message/124506#124595 · In reply to: #124593 > > > Rather than force people to use functions that we acknowledge are hard > > > to use, surely the logical thing is to make the "right" code *easy* to use? Which means if we want people to use SHA-256, let's add a sha256() function to make it easy. This is what `password_hash()` and `password_verify()` did right: the functionality was already there in `crypt()`, but it's hard to use, and harder to use correctly. Providing clearer functions, even though they do the same thing, helps new developers "fall into the pit of success". > > Yes! 1000% *THIS*. -Mike > > > The `hash()` function isn't quite as confusing as `crypt()`, but according to the manual, it currently supports 60 different algorithms, most of which I have never heard of. I'm aware that "sha256" is better than "sha1", but should I be aiming higher, and using "sha384", or maybe one of the four flavours of "sha3"? Then there's the fun-sounding "whirlpool", the faintly rude-sounding "snefru", and a bewildering fifteen flavours of "haval". A new user being told "don't use `sha1()`, use `hash()` and pick from this list" is more likely to say "ah, there's sha1, jolly good" than spend an afternoon reading cryptography journals. There's no pit of success to fall into. Regards, -- Rowan Tommins [IMSoP] --- ## #124596 — Mike Schinkel — 2024-07-25T22:26:51+00:00 URL: https://externals.io/message/124506#124596 · In reply to: #124594 > > > That's a good point. What if there were crypto functions that worked > > > like `password_hash()` in that they had one generic function name, but magically used the new/better "best practice" algorithms as time went by without the need to update any calling code? Maybe there should be three generic-named functions: fast_hash() // not secure, makes UIDs quickly secure_hash() // uses best practice one-way hash algo secure_crypt() // uses best practice reversible encryption. Then the developer signals their *intent* by choosing a function name, and the algorithm magically works underneath (perhaps with the option of an ini override to make those functions work in different environments). > > If those _were_ added, I would bikeshed their names to make sure their intent was 100% clear: > insecure_hash() // not secure, makes UIDs quickly secure_oneway_hash() // uses best practice one-way hash algo secure_reversible_hash() // uses best practice reversible encryption. -Mike --- ## #124597 — Juliette Reinders Folmer — 2024-07-25T22:44:20+00:00 URL: https://externals.io/message/124506#124597 · In reply to: #124594 > > That's a good point. What if there were crypto functions that worked > like `password_hash()` in that they had one generic function name, but > magically used the new/better "best practice" algorithms as time went > by without the need to update any calling code? > > Maybe there should be three generic-named functions: > > fast_hash() // not secure, makes UIDs quickly > secure_hash() // uses best practice one-way hash algo > secure_crypt() // uses best practice reversible encryption. While I like the idea, this sounds like a huge nightmare in the waiting when data is stored somewhere and later compared. Example: * Let's say these functions get introduced in PHP 8.5. * `secure_hash()` is used in an application running on PHP 8.5 to secure some data before storing it in a database. This data is used in comparisons - stored vs user provided. * Now in PHP 9.1, the hash algorithm is changed. * The production environment gets updated to PHP 9.1 and suddenly the application breaks as the data verification will no longer work as the new algo is used on the user provided data, but the database stored version of the same data was created with the old algo.... --- ## #124598 — Nick Lockheart — 2024-07-25T22:54:53+00:00 URL: https://externals.io/message/124506#124598 · In reply to: #124597 > >   > > […] >   >  While I like the idea, this sounds like a huge nightmare in the > waiting when data is stored somewhere and later compared. >   >  Example: >  * Let's say these functions get introduced in PHP 8.5. >  * `secure_hash()` is used in an application running on PHP 8.5 to > secure some data before storing it in a database. This data is used > in comparisons - stored vs user provided. >  * Now in PHP 9.1, the hash algorithm is changed. >  * The production environment gets updated to PHP 9.1 and suddenly > the application breaks as the data verification will no longer work > as the new algo is used on the user provided data, but the database > stored version of the same data was created with the old algo.... >   Doesn't `password_hash()` handle this automatically? The result of the `password_hash()` function includes the hash and the algorithm used to hash it. That way `password_verify()` magically works with the string that came from `password_hash()`. --- ## #124599 — Peter Stalman — 2024-07-26T06:35:14+00:00 URL: https://externals.io/message/124506#124599 · In reply to: #124588 > No, we are talking about end users who are following tutorials that were > written when PHP 4 was the most recent PHP version. > > We are also talking about end users who look at existing code bases for > "inspiration", see `md5()` used, notice that the output looks random and > use it, believing they know what they are doing, but in that process use > it in a way that is insecure. > Hi Tim, How prevalent is this exactly? PHP 4 ended support in 2008. I think putting warning labels on these things in the docs is enough, but we can't go around locking up every kitchen knife just because there are some idiots out there who read a book from the 50s about the war. And like I said previously, this change isn't what is going to determine if those people will write good, reliable, secure code. If their learning insticast can't see past a blog tutorial from 20 years ago, not even to look up the function in the manual, they will not ever achieve that. > I'm positive that even existing projects written by experienced > developers would benefit from re-checking if their use of MD5 and SHA-1 > is actually safe instead of assuming that this is the case, when the > specific functionality has been untouched for the last 10 years. > You can say this about pretty much every software project in existence, regarding anything. I just don't think it's up to PHP to mandate these checks. If you want to create a fund for developers to go review their code on the clock, fine, but don't force it on them. Might as well deprecate everything each major version to force people to rewrite their projects to "current best practices". If I wanted to do that, I'd just use the JS framework of the month. > Looking back at my own code, I'm seeing places where using SHA-1 is not > strictly insecure, but where a stronger hash function nevertheless would > have been more appropriate, if only to simplify code audits. I just used > `sha1()`, because it was temptingly convenient compared to hash('sha256', …). > sha1 was the "proper" alternative to md5, until it wasn't. md5 superceeded crc32, which btw, why isn't that on the hit-list? You're using sha256? It's soooo outdated, use sha512 and key it with hmac, you casual /s SHA-1 is a deterministic algorithm, thus it is unable to generate a > random UID. Whatever this code is doing can most likely be more reliably > achieved in a different way. ALL hashing functions are deterministic. That's the whole point, and applies to sha256 just the same. You want to be able to hash the same content and get the same hash. Just the complexity and chance of collision changes. The reliability and security you are concerned with in this scenario really depends on what randomness you feed it. Thanks, Peter --- Next page: https://externals.io/message/124506.md?page=2