On 08.07.2024 at 05:04, Juliette Reinders Folmer wrote: > On 2-7-2024 20:05, Gina P. Banyard wrote: > >> On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer >> <php-internals_nos...@adviesenzo.nl> wrote: >> >>> Other than that, I join the previously voiced objections to the >>> deprecation of `uniqid()`, `md5()`, `sha1()`, `md5_file()`, >>> `sha1_file()`. >>> While I acknowledge that these functions _can_ be used >>> inappropriately for security-sensitive code, which should use >>> alternative methods, these functions have perfectly valid use-cases >>> for non-security-sensitive code and the impact of the BC-break of >>> deprecating and eventually removing these methods can, IMO, not be >>> justified. >>> Keep in mind that while "we" know and understand that deprecations >>> are not errors, end-users often don't and particularly for open >>> source projects, this means that in practice these deprecations will >>> need to be addressed anyway to reduce the noise of users opening >>> issues about them, which without a clear path to removal of the >>> functions, will, in a lot of cases, mean adding the `@` operator to >>> all uses. >> >> If I may be a bit cheeky, if we consider that userland does not >> understand that deprecations are not errors, how can we trust them to >> use the 5 aforementioned functions correctly? >> Especially as there are more appropriate replacements available. > > There is a difference between "userland" (dev-users) and end-users. I > was talking about end-users, while based on your remark, you are talking > about dev-users.
To clarify, by end-users you are referring to users who install and "operate" (open-source) software on (shared) hosting. If so, indeed they may stumble upon deprecation notices, and from my (limited) experience, they will report that as issue, unless the software developers release a new version which does not trigger these deprecation notices. This is unfortunate, but I really do hope that these developers only use the shut-up operator when all else fails, and that they remove it as soon as possible. Yeah, even more work, but that is what you are sometimes not paid for. ;) > I also don't agree that there are "more appropriate replacements > available". > The suggested `hash()` replacements for the md5/sha1* functions have > the exact same functionality, which the RFC considers "incorrect use", > so what are we actually solving by this deprecation ? Devs not having > enough to do already ? > The problem (for open source) with "force-replacing" the uses of > `md5/sha1*` functions with the `hash` function calls, is that the hash > extension was not part of PHP core until PHP 7.4, which means that for a > significant number of open source projects, the replacement is not a > one-on-one function call replacement, but needs guard code for PHP < 7.4 > in case the hash extension is not available. Well, I don't think it's hard to deal with deprecations for which alternatives are easily available. Just replace all e.g. md5() calls with something namespaced, and define that function depending on the PHP version. With regard to md5() and sha1() my first though was that we easily could keep them as aliases. However, the RFC explains that it might be a good idea to *reconsider* the use cases, and that is a good idea, in my opinion. I do not, however, agree with the reasoning that a function (like uniqid()) is often used in a unsafe way (i.e. for purposes it has not been designed), and therefore should be deprecated/removed. There are likely a couple of developers who are easily rolling their own implementation which can be way worse. I've seen "encryption" code which was basically a Caesar cipher, spiced with some obsure function calls to make it "even more safe". And I've seen obscure HTML escaping code with an not so obvious back-door, that was once available as user note on php.net. That doesn't mean that I'm against the uniqid() deprecation, especially if the deprecation message is clear on what to use instead. Cheers, Christoph
