>
> I'm missing a thing here when we talk about "your code". I mean on our
> site we have third party libraries. They can typically have a release
> schedule on a couple of releases each year. So all code is not up to
> us to change. So how does this proposal adress that scenario when it's
> not up
On 27/01/2021 16:26, Benjamin Morel wrote:
Shouldn't it throw an exception, or a least trigger a warning, when the
algorithm is unknown, or the hash is malformed? Returning false IMO, should
mean "I recognize this hash, but it doesn't match your password". "I don't
recognize this hash" is an appl
On Wed, 30 Dec 2020 at 18:33, Kamil Tekiela wrote:
> [...] I have written an RFC which explains all my ideas.
> https://wiki.php.net/rfc/improve_mysqli
Hi Kamil,
As there is a discussion about MySQLi raising exceptions, and you're
looking at the general mysqli API...
When using mysqli_stmt:
On Wed, Jan 27, 2021 at 10:27 AM Benjamin Morel
wrote:
> I just spent some time debugging an authentication issue after upgrading
> PHP, and realized that it was due to ext-sodium not being installed, so
> password_verify() would always return false for argon2i hashes.
>
> Digging a bit more, I r
Den 2021-01-27 kl. 17:13, skrev Björn Larsson:
Den 2021-01-27 kl. 16:07, skrev Kamil Tekiela:
Wouldn't this mean everybody would add mysqli_report() to their code?
That is the idea. That is what everyone should already have in their
codebase.
And wouldn't this render the default of mysqli
Hi internals,
I just spent some time debugging an authentication issue after upgrading
PHP, and realized that it was due to ext-sodium not being installed, so
password_verify() would always return false for argon2i hashes.
Digging a bit more, I realized that password_verify() does not complain if
Den 2021-01-27 kl. 16:07, skrev Kamil Tekiela:
Wouldn't this mean everybody would add mysqli_report() to their code?
That is the idea. That is what everyone should already have in their
codebase.
And wouldn't this render the default of mysqli_report() entirely useless?
I'm sorry, but I do
>
> Wouldn't this mean everybody would add mysqli_report() to their code?
That is the idea. That is what everyone should already have in their
codebase.
And wouldn't this render the default of mysqli_report() entirely useless?
I'm sorry, but I don't follow the train of thought? Why would it ma
On Wed, Jan 27, 2021 at 3:35 PM Christian Schneider
wrote:
> Am 27.01.2021 um 14:34 schrieb Nikita Popov :
> > I think if you wanted to introduce an additional diagnostic step, the
> way to go about it would be to issue a deprecation warning when creating a
> connection without mysqli_report() ha
Am 27.01.2021 um 14:34 schrieb Nikita Popov :
> I think if you wanted to introduce an additional diagnostic step, the way to
> go about it would be to issue a deprecation warning when creating a
> connection without mysqli_report() having been explicitly called beforehand.
Wouldn't this mean eve
Am 25.01.2021 um 11:03 schrieb Nikita Popov:
Fully support this proposal. Throwing exceptions is the right default, it
matches what PDO does, and restoring the old behavior is one line of code.
I second that emotion.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
On Tue, Jan 26, 2021 at 8:42 AM Christian Schneider
wrote:
> Am 26.01.2021 um 07:57 schrieb Alexandru Pătrănescu :
> > There will be other parts that will require testing, whatever you do.
> Trying to optimize this to reduce the 1 line quick fix that could be easily
> read in the documentation at
On Tue, Jan 26, 2021 at 8:06 PM Go Kudo wrote:
> RFCs have been reorganized and radically rewritten.
> https://wiki.php.net/rfc/object_scope_prng
>
> The implementation is unchanged, but the background has been explained in
> more detail and the execution speed has been re-verified with PHP 8.1-d
13 matches
Mail list logo
