hi,
On Thu, Jun 28, 2012 at 12:03 AM, Ángel González wrote:
> Precisely the point of such constant is to allow the applications to
> magically
Right, but not a default argument, which is bad in this case, for the
reasons explained earlier.
> Obviously, any such bump -which I would expect to ha
On 06/27/2012 08:45 PM, Yasuo Ohgaki wrote:
> Hi,
>
> I forgot to mention MySQL's query cache.
> This change may have negative performance impact, since prepared
> query is not cached and native prepared query may not be used by
> other requests.
That's not really true anymore. There are some lim
Hi,
I forgot to mention MySQL's query cache.
This change may have negative performance impact, since prepared
query is not cached and native prepared query may not be used by
other requests.
It would be nice to have an option keeping prepared statement
when PDOStatement destroyed.
Regards,
--
Y
Pierre,
> No, it is exactly one example out of many where changing values are a
> real pain to deal with over the years. We should not have one.
While I completely see your point (and don't disagree with it in
isolation), I also see the counter point of making it easy for people
to use. Knowing a
> So that next time this code changes any breakage is obvious.
Next time?
I had reported breakage for PHP 5.4.4 RC, but it "wont fix" and PHP
5.4.4 was released.
https://bugs.php.net/bug.php?id=62097
I think the breakage exists in current version (PHP 5.4.4).
> Any test you create for PHP 5.4
Johannes,
> Some comments on the "error behavior" part:
>
> E_WARNING - When CRYPT is not included in core (was disabled
> compile-time, or is listed in disabled_functions declaration)
>
> Disabling a different function should have no effect. This is not
> intuitive. If crypt is a dependency
Arvids,
On Wed, Jun 27, 2012 at 12:32 PM, Arvids Godjuks
wrote:
> On that note I have only one request - please point me to the good article
> that describes how this thing works (I would prefer one that at least tries
> to explain in simple words) because at the moment i do not understand how
>
On 27/06/12 18:13, Pierre Joye wrote:
> Changing default value forces code change if you have to keep a given
> hash, for one obvious side effect.
>
> If you disagree or does not like the idea, that's all fine, but you
> can't really say that it is not an argument (nothing to justify, this
> is a d
On Wed, Jun 27, 2012 at 11:37 AM, Galen Wright-Watson wrote:
>
> On Wed, Jun 27, 2012 at 6:07 AM, Solar Designer wrote:
>
>> [...]
>>
>> BTW, what version of PHP introduced the === comparison operator?
>> I guess this should become the minimum version for phpass since this is
>> highly desirable t
On Wed, Jun 27, 2012 at 6:07 AM, Solar Designer wrote:
> [...]
>
> BTW, what version of PHP introduced the === comparison operator?
> I guess this should become the minimum version for phpass since this is
> highly desirable to use.
>
=== was added on Oct 19, 1999. php_version.h gives the versio
On 06/26/2012 09:06 PM, OISHI Kazuo wrote:
Does this need an architecture specific SKIPIF? See the mention of
PHP_INT_SIZE on http://qa.php.net/write-test.php
Like this?
===
--SKIPIF--
==
On Wed, Jun 27, 2012 at 11:06 AM, Michael Morris wrote:
> PHP has a braceless syntax stretching back to its roots as a template
> language. Frameworks which make use of php templating use these tags
> quite frequently since it's harder to overlook an endif statement in a
> sea of HTML tags than a
PHP has a braceless syntax stretching back to its roots as a template
language. Frameworks which make use of php templating use these tags
quite frequently since it's harder to overlook an endif statement in a
sea of HTML tags than a brace. But what of endfunction?
I did some look ups and found
Hi,
On Tue, 2012-06-26 at 11:25 -0400, Anthony Ferrara wrote:
> https://wiki.php.net/rfc/password_hash
Some comments on the "error behavior" part:
E_WARNING - When CRYPT is not included in core (was disabled
compile-time, or is listed in disabled_functions declaration)
Disabling a diffe
On that note I have only one request - please point me to the good article
that describes how this thing works (I would prefer one that at least tries
to explain in simple words) because at the moment i do not understand how
salt stored in the hash itself makes hash more secure than an unsalted one
hi,
On Wed, Jun 27, 2012 at 2:59 PM, Gustavo Lopes wrote:
> You described why people *may* have to, depending on the circumstances --
> for instance, when interoperability in mixed environments is required. No
> one is saying that relying on a default value is appropriate in those
> circumstance
Arvids,
On Wed, Jun 27, 2012 at 9:23 AM, Arvids Godjuks
wrote:
> Hello.
>
> I personally think that using PASSWORD_DEFAULT for algorythm by default is a
> bad idea. This should be defined by user in the code. Even worse if it is
> defined by .ini setting - deploy to a remote server and realize th
Hello.
I personally think that using PASSWORD_DEFAULT for algorythm by default is
a bad idea. This should be defined by user in the code. Even worse if it is
defined by .ini setting - deploy to a remote server and realize that there
is a different .ini default that messes up everything. Lessons le
Alexander,
> BTW, what version of PHP introduced the === comparison operator?
> I guess this should become the minimum version for phpass since this is
> highly desirable to use.
>
> http://www.php.net/manual/en/language.operators.comparison.php does not
> say anything about that.
>
That's been i
Pierre,
> Back then MD5 alone was all nice and shiny. So no, it is not possible
> to be forward compatible.
By forward compatible, if you mean able to support any new algo, I
think this is forward compatible. The options array allows for new
implementations to implement whatever options they need
On Wed, Jun 27, 2012 at 07:51:38AM -0400, Anthony Ferrara wrote:
>
> > Note: _if_ you ask for a portable hash. What else should it do if you
> > ask it for just that?
>
> That's a fair point. I guess since the adoption of 5.3, and the fact
> that 5.2 is dead (yet alone php4), has me thinking tha
Em Wed, 27 Jun 2012 14:43:35 +0200, Pierre Joye
escreveu:
On Wed, Jun 27, 2012 at 2:32 PM, Gustavo Lopes
wrote:
Em Wed, 27 Jun 2012 14:24:39 +0200, Anthony Ferrara
escreveu:
I don't see any advantage in adding complexity through another level of
indirection. If people want control ove
hi,
On Wed, Jun 27, 2012 at 2:32 PM, Gustavo Lopes wrote:
> Em Wed, 27 Jun 2012 14:24:39 +0200, Anthony Ferrara
> escreveu:
>
>
>> Actually, now that I'm talking that out, perhaps the way to do it
>> would be to specify the default algorithm in a php.ini parameter
>> instead of the constant? Tha
Em Wed, 27 Jun 2012 14:24:39 +0200, Anthony Ferrara
escreveu:
Actually, now that I'm talking that out, perhaps the way to do it
would be to specify the default algorithm in a php.ini parameter
instead of the constant? That way the API can stay the same, but gives
people more control over the
Pierre,
>> As I understand, hashes computed with the old default method could still be
>> checked without any modification as the hash itself stores information about
>> the method.
>
> That's only about one relatively simple use case where only PHP would
> be involved or crypt-like implemenation.
On Wed, Jun 27, 2012 at 1:40 PM, Pierre Joye wrote:
> hi,
>
> On Wed, Jun 27, 2012 at 1:30 PM, Nikita Popov
> wrote:
>
>>> Why not in the spirit of others have a new function json_last_error_msg() or
>>> something similar?
>>
>> I implemented it with json_last_error(true) returning just a string
hi,
On Wed, Jun 27, 2012 at 1:49 PM, Gustavo Lopes wrote:
> Em Wed, 27 Jun 2012 13:37:50 +0200, Pierre Joye
> escreveu:
>
>
>> That's exactly what I meant, having a changing default in this may
>> force code change during php updates. I'm not in favour of having such
>> default.
>>
>
> This woul
Alex,
> Thank you for the chance to comment, and sorry that I did not do so yet.
> I am busy with lots of other stuff. I'd appreciate it if you don't
> hurry to implement this stuff too much, and I likely will comment on it
> (that is, on the actual proposed API and implementation). Please keep
Em Wed, 27 Jun 2012 13:37:50 +0200, Pierre Joye
escreveu:
That's exactly what I meant, having a changing default in this may
force code change during php updates. I'm not in favour of having such
default.
This would not require any code changes after updates.
As I understand, hashes compu
hi,
On Wed, Jun 27, 2012 at 1:30 PM, Nikita Popov wrote:
>> Why not in the spirit of others have a new function json_last_error_msg() or
>> something similar?
>
> I implemented it with json_last_error(true) returning just a string,
> not an array. You can get the array using array(json_last_erro
hi,
On Wed, Jun 27, 2012 at 1:24 PM, Anthony Ferrara wrote:
> Simon,
>
>> * Will the value of the constant PASSWORD_DEFAULT remain unchanged forever?
>> Otherwise this lib, in my opinion, can cause big problems when trying to
>> port an existing system to a newer PHP-version.
>
> the default is
Session Handler enhancement (create_sid)
I would like to propose a new feature to the current custom session
handling; the ability for a user defined function to be used when
generating the session id.
The reasons are as follows:
The Session Handler doesn't know when session_regenerate_id is us
On Wed, Jun 27, 2012 at 1:27 PM, Benjamin Eberlei wrote:
>
> On Wed, Jun 27, 2012 at 1:41 AM, Stas Malyshev
> wrote:
>>
>> Hi!
>>
>> > Makes sense to me. So should I do this? Remove warnings + add string
>> > parameter for json_last_error?
>
>
> I think its weird that the parameter is called $err
On Wed, Jun 27, 2012 at 1:41 AM, Stas Malyshev wrote:
> Hi!
>
> > Makes sense to me. So should I do this? Remove warnings + add string
> > parameter for json_last_error?
>
I think its weird that the parameter is called $error_string and setting it
to true means returning an array.
Why not in the
Simon,
> * Will the value of the constant PASSWORD_DEFAULT remain unchanged forever?
> Otherwise this lib, in my opinion, can cause big problems when trying to
> port an existing system to a newer PHP-version.
No. That's why it's a separate constant. As newer, stronger hashing
options become avai
On 2012-06-26 07:22, Ben Ramsey wrote:
However, in Prototype.js and Underscore.js, pluck seems behave more like
array_map() in PHP:
http://api.prototypejs.org/language/Enumerable/prototype/pluck/
http://documentcloud.github.com/underscore/#pluck
Nevertheless, it would technically have the same
hi!
On Wed, Jun 27, 2012 at 12:13 PM, Simon Schick wrote:
> Hi, Anthony
>
> Some questions coming up in my mind by reading this RFC:
>
> * Will the value of the constant *PASSWORD_DEFAULT* remain unchanged
> forever? Otherwise this lib, in my opinion, can cause big problems when
> trying to port
Hi, Anthony
Some questions coming up in my mind by reading this RFC:
* Will the value of the constant *PASSWORD_DEFAULT* remain unchanged
forever? Otherwise this lib, in my opinion, can cause big problems when
trying to port an existing system to a newer PHP-version.
* Is this a native version of
On Wed, Jun 27, 2012 at 11:18 AM, Johannes Schlüter
wrote:
> On Tue, 2012-06-26 at 23:44 -0700, Stas Malyshev wrote:
>> Hi!
>>
>> > I would like to merge the patch from #61421 to all active branches (RMs as
>> > CC).
>> >
>> > It is not a new function nor does it add new features but new
>> > con
Hi all,
On Sat, Jun 16, 2012 at 03:39:35PM +0200, Pierre Joye wrote:
> Adding Alex to the loop as his insight will be unvaluable in this thread.
Thank you for the chance to comment, and sorry that I did not do so yet.
I am busy with lots of other stuff. I'd appreciate it if you don't
hurry to im
On Tue, 2012-06-26 at 23:44 -0700, Stas Malyshev wrote:
> Hi!
>
> > I would like to merge the patch from #61421 to all active branches (RMs as
> > CC).
> >
> > It is not a new function nor does it add new features but new
> > constants to support more algorithms for the signature verification.
>
41 matches
Mail list logo
