Richard,
> There is also the case of an app that simple shouldn't run with the
> single default, but could pick and choose suitable algorithm from a
> list of defaults, while still honoring whatever is in the .ini file
> instead of going rogue with some other algorithm.
I disagree there. I think
On 03/07/12 18:21, Anthony Ferrara wrote:
>> 2) I'd like to be able to check wether a stored password uses an outdated
> algorithm and update the hash in that case. For that I'd need either a
> function to extract the salt from a hash to pass it to password_hash() and
> compare the result with the
Am 03.07.2012 um 18:21 schrieb Anthony Ferrara:
> >> know you didn't like PASSWORD_MOST_SECURE. So what about keeping
> >> PASSWORD_DEFAULT as a moving target, documented, and just making the
> >> second parameter (algo) to password_hash required? That way users
> >
> > To be honest I'm not sure of
Could be, xcache is definetly dummer in features and it is its feature. I
guess it helps it to keep up with releases. I will investigate this today,
maybe get some interesting results worth to share here.
03.07.2012 16:54 пользователь "Rasmus Lerdorf" написал:
> On 07/03/2012 09:49 AM, Arvids God
Just to be clear - all 3 major opcode cachers i know (zend optimizer
excluded - have no idea what he has) have that shared memory cache with
almost identical API. Some have extended functionality (xcache has
xcache_isset(), haven't seen that in others, but have to confess i haven't
been looking for
On 07/03/2012 09:49 AM, Arvids Godjuks wrote:
> One one side it's good to know i'm not wrong, on the other hand it's sad
> in this case.
> Sure about one thing - xcache is worth looking at and may be a better
> choise than APC and has better potential.
> One thing sure - I haven't heard anyone comp
One one side it's good to know i'm not wrong, on the other hand it's sad in
this case.
Sure about one thing - xcache is worth looking at and may be a better
choise than APC and has better potential.
One thing sure - I haven't heard anyone complaining about xcache. And
heard many complains about AP
On 07/03/2012 08:17 AM, Pierre Joye wrote:
> I for one would like to kill all the legacy features or too specific
> features which are really unusable by any common developers.
>
> Other developers may disagree but it makes very hard to maintain APC.
There are really just two big features in APC.
Christian,
> Hi Anthony,
> I tried sending this to intern...@php.net but it seems it didn't get
through...
Replying on list.
>> know you didn't like PASSWORD_MOST_SECURE. So what about keeping
>> PASSWORD_DEFAULT as a moving target, documented, and just making the
>> second parameter (algo) to p
The ability to store your own data in the APC cache is a feature that
does get used a lot in the Symfony framework world because of the
availability of the sfAPCCache and whatever its Symfony 2 equivalent
is. It's popular with folks who haven't felt the need to set up Redis
or some other external c
> > It is still the case.
> >
> > I for one would like to kill all the legacy features or too specific
> > features which are really unusable by any common developers.
> >
> > Other developers may disagree but it makes very hard to maintain APC.
>
> Perhaps that indicates it's time to pull the c
Pierre,
> It is still the case.
>
> I for one would like to kill all the legacy features or too specific
> features which are really unusable by any common developers.
>
> Other developers may disagree but it makes very hard to maintain APC.
Perhaps that indicates it's time to pull the core of AP
There are alternative opcode cachers besides APC. For example xcache, for
me, just works when APC is still catching up.
I remember someone writing about APC that it is overly compex internally
and due to that hard to keep up with the changes in the PHP, maybe that is
not the case now.
But looking a
hi,
On Tue, Jul 3, 2012 at 5:12 PM, Arvids Godjuks wrote:
> There are alternative opcode cachers besides APC. For example xcache, for
> me, just works when APC is still catching up.
> I remember someone writing about APC that it is overly compex internally
> and due to that hard to keep up with t
hi Tom,
On Tue, Jul 3, 2012 at 4:49 PM, Tom Boutell wrote:
> Given the impracticality of using PHP without APC, it would be nice if
> it were part of the main "if these fail, it's not ready" test suite.
> But I suppose that's just administering beatings until morale improves
> (:
That's why lat
Given the impracticality of using PHP without APC, it would be nice if
it were part of the main "if these fail, it's not ready" test suite.
But I suppose that's just administering beatings until morale improves
(:
On Tue, Jul 3, 2012 at 10:20 AM, Rasmus Lerdorf wrote:
> On 07/03/2012 07:13 AM, To
On 07/03/2012 07:13 AM, Tom Boutell wrote:
> This one:
>
> *** glibc detected *** /usr/local/bin/php-cgi: double free or
> corruption (out): 0x7f9d6ce2c080 ***
> === Backtrace: =
> /lib/libc.so.6(+0x77806)[0x7f9d679be806]
> /lib/libc.so.6(cfree+0x73)[0x7f9d679c50d3]
> /usr/local/bi
This one:
*** glibc detected *** /usr/local/bin/php-cgi: double free or
corruption (out): 0x7f9d6ce2c080 ***
=== Backtrace: =
/lib/libc.so.6(+0x77806)[0x7f9d679be806]
/lib/libc.so.6(cfree+0x73)[0x7f9d679c50d3]
/usr/local/bin/php-cgi(destroy_zend_class+0x23d)[0x749f5d]
/usr/local/bi
Pierre,
>> I know you didn't like PASSWORD_MOST_SECURE. So what about keeping
>> PASSWORD_DEFAULT as a moving target, documented, and just making the
>> second parameter (algo) to password_hash required? That way users
>> could choose between PASSWORD_BCRYPT and PASSWORD_DEFAULT.
>>
>> That way, ov
hi Anthony,
On Tue, Jul 3, 2012 at 1:53 PM, Anthony Ferrara wrote:
> Pierre,
>
> Getting back to the PASSWORD_DEFAULT discussion...
>
> I know you didn't like PASSWORD_MOST_SECURE. So what about keeping
> PASSWORD_DEFAULT as a moving target, documented, and just making the
> second parameter (alg
Pierre,
Getting back to the PASSWORD_DEFAULT discussion...
I know you didn't like PASSWORD_MOST_SECURE. So what about keeping
PASSWORD_DEFAULT as a moving target, documented, and just making the
second parameter (algo) to password_hash required? That way users
could choose between PASSWORD_BCRYPT
Pierre,
> Simply by not allowing to change it. If one does not like it, it can
> pass the option value as he wishes.
>
> An ini setting for that sounds wrong to me.
Alright. I've pulled the ini option from the fork, and have updated
the RFC to the same...
Anthony
--
PHP Internals - PHP Runtime
On Tue, Jul 3, 2012 at 10:42 AM, Pierre Joye wrote:
> hi!
>
> On Tue, Jul 3, 2012 at 1:23 AM, Anthony Ferrara wrote:
>
>> Well, if not for an ini parameter, what way would you suggest to alter
>> the default bcrypt cost? (seriously, I'm open to suggestions)...
>
> Simply by not allowing to change
hi!
On Tue, Jul 3, 2012 at 1:23 AM, Anthony Ferrara wrote:
> Well, if not for an ini parameter, what way would you suggest to alter
> the default bcrypt cost? (seriously, I'm open to suggestions)...
Simply by not allowing to change it. If one does not like it, it can
pass the option value as he
24 matches
Mail list logo
