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
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
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
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
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
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
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
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
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.
>>
>
>
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
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,
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
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()
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.
>
> 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
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
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
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
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
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
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
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
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
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
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];
>
25 matches
Mail list logo
