Re: [PHP-DEV] Allowing NULL for some internal functions

[Alexandru Pătrănescu]

On Mon, Feb 21, 2022 at 5:32 PM Craig Francis 
wrote:

> On Mon, 21 Feb 2022 at 09:04, Christoph M. Becker 
> wrote:
>
> > That "inconsistency" had been introduced with PHP 7.0.0, i.e. right when
> > scalar type declarations have been introduced.  Passing a null to a
> > non-nullable parameter of a *userland* function throws a TypeError
> >
>
>
> Thanks Christoph, that's a good way of looking at it.
>
> Considering NULL has been passed to these internal function parameters for
> years, for a variety of reasons, and PHP has coerced it into an empty
> string, integer 0, float 0, or boolean false... I'm wondering if my RFC
> should focus on matching that expectation, so anyone not using
> `strict_types=1` does not need to make loads of hard-to-find/unnecessary
> edits; that way NULL would be treated the same as the other variable types
> (I appreciate arrays and objects don't get coerced, but I don't think
> anyone expects them to).
>

Yes, exactly that.
A few weeks ago when the issue was mentioned again I had to remember by
trying on 3v4l myself that using null for a string parameter wasn't an
automatically coerced case when strict_types = 0.

In my view, false would have the same problem for those internal functions.
Why should it be coerced to an empty string?
https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg#proposal is
all about removing the automatic coercion that was happening for null in
the internal functions
Planning that in PHP 9 the type interpretation for internal function will
be done the same as for user defined functions. Consistency.

Right now, if a parameter type is defined as string in an user function, no
matter what strict_type is configured, it would still result in a TypeError
when passing null.
For internal functions, even if the parameter type is defined as string,
null would be passed and a coercion would happen.

As I mentioned, coercing false to int would be for me almost as bad as
coercing null to int.
But when types are not considered important I think it's worth pursuing
extending the coercion from null to the 4 other types where it's happening
right now:
- int as 0,
- float as 0.0,
- string as an empty string
- bool as false.

I don't like it and I have no good idea how that would work as it would be
a pretty big BC break.

Maybe it would be easier to change strict_types to default to 1 in PHP 9
along with adding the null coercion for null when strict_types is 0 rather
than inventing a new strict_types value like -1 that would allow null
coercion as well.
Starting with a notice in PHP 8.2 when the directive is not present might
be an interesting starting point. And no more warning for implicit coercion
when strict_types=0 directive is explicitly defined as it would not change
anymore in PHP 9.

Regards,
Alex

Re: [PHP-DEV] [RFC] Deprecate and Remove utf8_encode and utf8_decode

[Christoph M. Becker]

On 21.02.2022 at 18:35, Rowan Tommins wrote:

> On 21/02/2022 16:29, Alain D D Williams wrote:
>
>> Looking at the description of grapheme_strlen() I note that it can
>> return null.
>> However it does not say why>
> Huh, that feels like a bug to me, since it can also return false, which
> is the more standard way of indicating failure.

This is not the only function which returns null or false for different
kinds of failures.

> The obvious failure case is an input string that's not valid UTF-8, e.g.
> grapheme_strlen("\xFF"). It appears that currently returns null; so I'm
> not actually sure how you'd trigger the false case.

false is returned, if the internal function
grapheme_get_break_iterator() fails.  I'm not sure under which
circumstances that function may fail, but from looking at the code and
the ICU documentation[1], it seems we're relying on functionality which
is deprecated as of ICU 52; it's probably a good idea to adjust the
code, and to possibly bump the ICU version requirements (currently, ICU
>= 50.1 is required).

[1]


--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC proposal to deprecate crypt()

[Tim Düsterhus]

Hi Steve,

I wanted to stay away from this thread, as I believe I've made my 
opinion clear and there's not much more signal for me to add, but as 
you've replied to me directly:


On 2/21/22 17:43, st...@tobtu.com wrote:

If crypt() is removed, you can still use password_verify() to verify all the 
password hashes created by crypt().


Yes, this is true. It also appears to be tested by 
ext/standard/tests/password/password_verify.phpt for the DES style hashes.


However it does not appear to be documented at password_verify() 
(https://www.php.net/manual/en/function.password-verify.php), so that 
likely should be adjusted first.



The only thing you lose is creating those bad password hashes. Which can be 
done in userland because most people aren't changing their passwords daily. So 
it will run that slow userland code infrequently. This will not help the nested 
bcrypt example. Well besides the last bcrypt call can be password_verify():



Please ignore that "nested BCrypt" example for a moment, that wasn't my 
main point, it's a legacy implementation (for good reason), any new 
hashes in that software are regular BCrypt hashes based on 
password_hash() and any old passwords are rehashed on login. If that 
legacy hashing breaks, then so-be-it [1].


The larger point I've attempted to make is that crypt() is the lowest 
common denominator for interoperability with other programming languages 
and software (specifically libc), as also acknowledged by the Rowan and 
Jakub.


Yes, in the ideal world everyone would use just BCrypt (or Argon2 [2]), 
but unfortunately that isn't a reality. Removing the functionality from 
PHP is not likely to achieve this goal faster, as users will either not 
upgrade PHP or defer to a userland implementation.


While the latter certainly is an option, implementing a hashing 
algorithm definitely is something that is highly non-trivial to do in 
userland. If the deprecation of crypt() leads to a dozen (semi-)broken 
and insecure userland implementations to keep compatibility with 
whatever software that uses crypt() then I consider that a net-negative 
as well.


So:

- Improving the docs page for crypt(): Yes please.
- Deprecating CRYPT_STD_DES which is easy to accidentally use by not 
passing a valid algorithm indicator: That's also a yes.
- Rejecting long inputs (e.g. > 512 Bytes) for CRYPT_SHA256 / 
CRYPT_SHA512: Sure, that also makes sense.
- Completely removing support for crypt(): I'd rather not, because see 
above.


Best regards
Tim Düsterhus

[1] Even if I'd prefer it didn't as users sometimes come back to their 
account after several years. They still know their passwords, but in 
many cases their email address no longer is valid, thus they can't reset 
their password.


[2] Which incidentally might not be more secure that BCrypt for common 
configurations: https://twitter.com/TerahashCorp/status/1155129705034653698


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC proposal to deprecate crypt()

[Rowan Tommins]

On 21/02/2022 16:43, st...@tobtu.com wrote:

If crypt() is removed, you can still use password_verify() to verify all the 
password hashes created by crypt(). The only thing you lose is creating those 
bad password hashes. Which can be done in userland because most people aren't 
changing their passwords daily. So it will run that slow userland code 
infrequently.



What "slow userland code"? Is there an implementation of the legacy 
crypt hashing function in pure PHP out there somewhere? I certainly 
wouldn't be confident writing one.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC proposal to deprecate crypt()

[Craig Francis]

On Mon, 21 Feb 2022 at 16:44,  wrote:

> If crypt() is removed [...] The only thing you lose is creating those bad
> password hashes.



That's not exactly fair, as noted by Tim, `crypt()` can be used for other
software (e.g. Dovecot); and by Hans for modifying `/etc/shadow`.

While I would warn most developers away from using crypt(), because it is
dangerous, it can still be useful (dare I say it, md5, terrible idea, but
sometimes you need it when integrating with other systems).

Craig


On Mon, 21 Feb 2022 at 10:11, Tim Düsterhus  wrote:

> 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.


On Mon, 21 Feb 2022 at 12:04, Hans Henrik Bergan 
wrote:

> 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

Re: [PHP-DEV] [RFC] Deprecate and Remove utf8_encode and utf8_decode

[Rowan Tommins]

On 21/02/2022 16:29, Alain D D Williams wrote:

Looking at the description of grapheme_strlen() I note that it can return null.
However it does not say why.



Huh, that feels like a bug to me, since it can also return false, which 
is the more standard way of indicating failure.


The obvious failure case is an input string that's not valid UTF-8, e.g. 
grapheme_strlen("\xFF"). It appears that currently returns null; so I'm 
not actually sure how you'd trigger the false case.



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC proposal to deprecate crypt()

[steve]

If crypt() is removed, you can still use password_verify() to verify all the 
password hashes created by crypt(). The only thing you lose is creating those 
bad password hashes. Which can be done in userland because most people aren't 
changing their passwords daily. So it will run that slow userland code 
infrequently. This will not help the nested bcrypt example. Well besides the 
last bcrypt call can be password_verify():

password_verify(crypt($password, $hash), $hash);


> On 02/21/2022 4:10 AM Tim Düsterhus  wrote:
> 
>  
> 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
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecate and Remove utf8_encode and utf8_decode

[Alain D D Williams]

On Mon, Feb 21, 2022 at 03:52:57PM +, Craig Francis wrote:

> I would personally encourage everyone to have ext/intl installed and use
> > grapheme_strlen() instead of mb_strlen(), because knowing whether a
> > particular instance of the string "Nguyễn" is written with 6, 7, or 8
> > code points is not nearly as useful as knowing that it looks like 6
> > "characters" to a user either way.

Looking at the description of grapheme_strlen() I note that it can return null.
However it does not say why.

https://www.php.net/manual/en/function.grapheme-strlen.php

Digging in the code I see that it will return null if
intl_convert_utf8_to_utf16() fails. I think because of one of:

U_BUFFER_OVERFLOW_ERROR means that *target buffer is not large enough

U_STRING_NOT_TERMINATED_WARNING usually means that the input string is empty

u_strFromUTF8() failing.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
https://www.phcomp.co.uk/Contact.html
#include 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecate and Remove utf8_encode and utf8_decode

[Christoph M. Becker]

On 21.02.2022 at 16:52, Craig Francis wrote:

> On Mon, 21 Feb 2022 at 09:09, Rowan Tommins  wrote:
>
>> Making the extension always available (impossible to compile without it)
>> is a potential option, and I think has been suggested before; I'm not
>> sure of the exact pros and cons.
>>
>
> [...]
>
> I would personally encourage everyone to have ext/intl installed and use
>> grapheme_strlen() instead of mb_strlen(), because knowing whether a
>> particular instance of the string "Nguyễn" is written with 6, 7, or 8
>> code points is not nearly as useful as knowing that it looks like 6
>> "characters" to a user either way.
>
> Good point.
>
> I would like something that can be relied on to convert a strings character
> encoding... I assume it's a question of ext/mbstring having all of its
> dependencies already present (easier to compile?), vs ext/intl potentially
> being more useful (if a little bigger?).

We cannot make any extension with external dependencies mandatory.  If
we would require ext/intl, we had to bundle ICU, which is highly
unlikely to happen.  Making ext/mbstring (without ext/mbregex) mandatory
would be an option, but there should be a separate RFC about that.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecate and Remove utf8_encode and utf8_decode

[Craig Francis]

On Mon, 21 Feb 2022 at 09:09, Rowan Tommins  wrote:

> Making the extension always available (impossible to compile without it)
> is a potential option, and I think has been suggested before; I'm not
> sure of the exact pros and cons.
>

[...]

I would personally encourage everyone to have ext/intl installed and use
> grapheme_strlen() instead of mb_strlen(), because knowing whether a
> particular instance of the string "Nguyễn" is written with 6, 7, or 8
> code points is not nearly as useful as knowing that it looks like 6
> "characters" to a user either way.
>


Good point.

I would like something that can be relied on to convert a strings character
encoding... I assume it's a question of ext/mbstring having all of its
dependencies already present (easier to compile?), vs ext/intl potentially
being more useful (if a little bigger?).

Craig

Re: [PHP-DEV] Allowing NULL for some internal functions

[Craig Francis]

On Mon, 21 Feb 2022 at 09:04, Christoph M. Becker  wrote:

> That "inconsistency" had been introduced with PHP 7.0.0, i.e. right when
> scalar type declarations have been introduced.  Passing a null to a
> non-nullable parameter of a *userland* function throws a TypeError
>


Thanks Christoph, that's a good way of looking at it.

Considering NULL has been passed to these internal function parameters for
years, for a variety of reasons, and PHP has coerced it into an empty
string, integer 0, float 0, or boolean false... I'm wondering if my RFC
should focus on matching that expectation, so anyone not using
`strict_types=1` does not need to make loads of hard-to-find/unnecessary
edits; that way NULL would be treated the same as the other variable types
(I appreciate arrays and objects don't get coerced, but I don't think
anyone expects them to).

Craig

[PHP-DEV] Re: PHP 7.4.28 Released!

[Christoph M. Becker]

On 19.02.2022 at 14:33, Jan Ehrhardt wrote:

> "Christoph M. Becker" in php.internals (Fri, 18 Feb 2022 16:26:20 +0100):
>> On 18.02.2022 at 16:02, Jan Ehrhardt wrote:
>>
>>> Derick Rethans in php.internals (Thu, 17 Feb 2022 14:42:47 + (GMT)):
 The PHP development team announces the immediate availability of PHP
 7.4.28. This is a security release.
>>>
 Windows downloads:
>>>
>>> 7.4.28 is not there. 7.4.27 is there. And even 7.3.33 is still there.
>>
>> We're having some issues with the PHP 7.4 build VM.  I'm confident that
>> the PHP 7.4.28 builds are available soonish.
>>
>> I'm going to remove the 7.3 downloads right away.
>
> Please also move the 7.3.33 files to
> https://windows.php.net/downloads/releases/archives/

Ah, right!  Done.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC proposal to deprecate crypt()

[Rowan Tommins]

On 21/02/2022 12:28, Jakub Zelenka wrote:

We can see
that there are some valid use case for using crypt directly and we can also
see that it's offered by other languages as well - e.g. Python:
https://docs.python.org/3/library/crypt.html  .



I think this is quite an important point: if crypt() worked with some 
wacky homebrew format that only PHP understood, then planning to remove 
it would make sense. But since we don't have control over applications 
*outside* PHP, providing the low-level function that interoperates with 
them, and is hard to implement in userland, seems useful.


If updating the manual isn't enough, we could make more aggressive 
changes short of removal, such as renaming "CRYPT_MD5" to 
"CRYPT_INSECURE_MD5" and so on.


Incidentally, does the function now support Argon hashes, or are they 
implemented separately in the password functions?


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Under Discussion] Random Extension 4.0

[Tim Düsterhus]

Hi

On 2/21/22 03:57, Go Kudo wrote:

  I am sorry for the delay in replying.


Don't worry, there was a weekend inbetween and I totally understand that 
one wants to take their weekend off.



Thank you for the clear explanation.
It is true that the RFC in its current form lacks explanation. I'll try to
fix this first.


Sounds good.


Also, as I look into other languages' implementations, I see the need to
add some RNGs such as PCG. I will update the RFC to include these.


I suggest you avoid "feature creep" within the RFC. Additional engines 
can be added easily later on if the need arises. But for now it's more 
important to get a reliable basis that one can build onto.


Having a choice of a multitude of different engine just distracts from 
that goal and can be confusing for the user. With xoshiro256** there's a 
very good choice that already is part of the RFC, no need to have 
something else that might or might not be slightly better in some case.


Best regards
Tim Düsterhus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC proposal to deprecate crypt()

[Jakub Zelenka]

>
> As mentioned elsewhere in the mail thread, `crypt()` is not designed for
> fast hashing, and is in fact slow by design.
>

What do you mean by slow? Are you aware that  password_hash
and password_verify for bcrypt are just wrappers around crypt? Just to note
that by removing that, we would still need to keep php_crypt in the core
and would just get rid of couple of lines for the actual function
definitions and arguments so there's absolutely no benefit in terms of
maintanance.

We have got plenty of functions that are quite low level but offer some
additional functionality that can be used by specialised libraries / apps.
I think that it's much better to educate users by documentation rather than
removing the actual functionality that has got some valid users. We can see
that there are some valid use case for using crypt directly and we can also
see that it's offered by other languages as well - e.g. Python:
https://docs.python.org/3/library/crypt.html .

Jakub

Re: [PHP-DEV] Setting to disable the "Undefined array index" warning

[Mark Randall]

On 21/02/2022 10:29, Nicolas BADIA wrote:

and I don’t find the code more readable. Here are some examples of changes:



The example changes you provide are what many people here would 
recommend as good practice to improve the context and safety your code 
provides.


Anyone looking at that code can immediately infer that there is an 
expectation that those keys may be missing, with a suitable default 
provided for if that is the case.


The engine can see this too, which avoids it emitting warnings.

It takes a little more code, yes. But that is because you're being more 
clear in your intent.


This is a good thing. You should keep at it.

You could probably have the majority of your codebase converted before 
you could even hold a vote. Even if the vote was passed, which seems 
most unlikely, you would still need to wait 10 months for 8.2 to come 
out to use it.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC proposal to deprecate crypt()

[Hans Henrik Bergan]

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üsterhus  wrote:
>
> > Hi
> >
> > On 2/21/22 12:12, 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.
> > >>
> > >
> > > ...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 reasons
> > 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 get
> 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 finally
> 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 works
> 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 should
> > 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 designed
> 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/
>

Re: [PHP-DEV] RFC proposal to deprecate crypt()

[Marco Pivetta]

On Mon, Feb 21, 2022 at 12:39 PM Tim Düsterhus  wrote:

> Hi
>
> On 2/21/22 12:12, 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.
> >>
> >
> > ...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 reasons
> 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 get
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 finally
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 works
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 should
> 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 designed
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/

Re: [PHP-DEV] RFC proposal to deprecate crypt()

[Tim Düsterhus]

Hi

On 2/21/22 12:12, 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.



...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 reasons 
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.


With the same arguments one could deprecate and remove md5() (and 
possibly sha1() as well). It should not be used for passwords, it should 
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.

Best regards
Tim Düsterhus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC proposal to deprecate crypt()

[Marco Pivetta]

On Mon, Feb 21, 2022 at 11:10 AM Tim Düsterhus  wrote:

> 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.
>

...yes? That's the point?

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.io/

Re: [PHP-DEV] RFC proposal to deprecate crypt()

[Tim Düsterhus]

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC proposal to deprecate crypt()

[Marco Pivetta]

On Mon, Feb 21, 2022 at 10:06 AM Stanislav Malyshev 
wrote:

> Hi!
>
> > The RFC is about deprecation, not removal.
>
> 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.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.io/

Re: [PHP-DEV] [RFC] Deprecate and Remove utf8_encode and utf8_decode

[Rowan Tommins]

On 20/02/2022 23:54, Craig Francis wrote:
I'm just wondering, and this would not be necessary... considering how 
most systems need to deal with UTF-8 data today, could an argument be 
made for enabling etc/mbstring by default?


I'm fairly sure Ubuntu and CentOS need to install the package 
`php-mbstring` separately; whereas my limited experience with 
cheep/shared hosting, they tend to have it enabled.



Unfortunately, enabling by default in the distributed source files won't 
make any difference to that situation, as anything that can be built as 
a separate library file can (and seemingly will) be split into a 
separate package in a binary distribution.


Making the extension always available (impossible to compile without it) 
is a potential option, and I think has been suggested before; I'm not 
sure of the exact pros and cons.




everyone could trust functions like `mb_strlen()` are available as well.



I would personally encourage everyone to have ext/intl installed and use 
grapheme_strlen() instead of mb_strlen(), because knowing whether a 
particular instance of the string "Nguyễn" is written with 6, 7, or 8 
code points is not nearly as useful as knowing that it looks like 6 
"characters" to a user either way.



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC proposal to deprecate crypt()

[Stanislav Malyshev]

Hi!


The RFC is about deprecation, not removal.


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)?


If we want to document which functions are recommended to be used in 
which case, we have the manual for that. I don't think deprecation 
should be used for such things.

--
Stas Malyshev
smalys...@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Allowing NULL for some internal functions

[Christoph M. Becker]

On 20.02.2022 at 21:38, Craig Francis wrote:

> On Sat, 1 Jan 2022 at 23:17, Craig Francis  wrote:
>
>> Draft RFC:
>> https://wiki.php.net/rfc/allow_null
>>
>
>
> I've been over-complicating this... why should NULL be treated so
> differently?
>
>$values = ['a', 1, 2.3, false, NULL];
>   foreach ($values as $value) {
> echo urlencode($value);
>   }
> ?>
>
> It just struck me, this whole thing is about type coercion when not using
> `strict_types=1`; and the 8.1 change has introduced an inconstancy by
> deprecating the coercion of NULL, a frequently used value.

That "inconsistency" had been introduced with PHP 7.0.0, i.e. right when
scalar type declarations have been introduced.  Passing a null to a
non-nullable parameter of a *userland* function throws a TypeError:
.  As of PHP 8.1.0, internal functions behave
the same as userland function in this regard.


--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php