>> I know this was discussed a number of times here, but just to bring it
>> to a conclusion - I intend to apply patch in the bug report - which
>> removes conversion for strings that do not convert to integers - to 5.4.
>> If anybody sees anything that breaks because of this please tell.
>
> "1234
On Fri, Jun 15, 2012 at 8:56 AM, Hartmut Holzgraefe
wrote:
> Too late to raise this now anyway, but ...
>
> On 13.05.2012 04:39, Stas Malyshev wrote:
>> I know this was discussed a number of times here, but just to bring it
>> to a conclusion - I intend to apply patch in the bug report - which
>>
On 2012-06-15 04:00, Ángel González wrote:
On 13/06/12 05:26, Morgan L. Owens wrote:
After reading the performance improvements RFC about interned strings,
and its passing mention of a "special data structure (e.g.
zend_string) instead of char*", I've been thinking a little bit about
this and wh
Hello all,
I raised this topic on list over a year ago (
http://marc.info/?l=php-internals&m=130417646507744&w=2 ). It was
determined that it wasn't time yet to disable prepared statement
emulation for MySQL yet. However, Rasmus did mention that it was a
possibility for 5.4 (
http://marc.info/?l=p
Too late to raise this now anyway, but ...
On 13.05.2012 04:39, Stas Malyshev wrote:
> I know this was discussed a number of times here, but just to bring it
> to a conclusion - I intend to apply patch in the bug report - which
> removes conversion for strings that do not convert to integers - to
On Wed, Jun 13, 2012 at 2:31 PM, Nikita Popov wrote:
> Hi internals!
>
> Recent incidents have shown that even very large websites still don't
> get how to do password hashing properly. The sha1 hashes used by
> Linkedin et al can be easily cracked even by amateurs without special
> hardware.
>
L
Now getting a lot of these messages:
"/data/prj/php-5.3.13/Zend/zend.h", line 179.10: 1506-358 (I)
"__restrict__" is defined on line 186 of /usr/include/standards.h.
line 179...
#if defined(__GNUC__) && ZEND_GCC_VERSION >= 3004
#else
# define
__restrict__
#endif
#define restrict __restrict__
AIX
On Thu, 2012-06-14 at 18:26 +0200, Ángel González wrote:
> What do you have at those lines? As it mentions "Undeclared identifier
> or.",
> perhaps it's (wrongly) taking the slash at "and/or " as a "*/" ??
> That would be very broken of a compiler...
No, that's invalid C89 code and a quite standar
messages crossed - thanks. I was thinking of copying the sqlite, or at
least doing a diff when I saw the same error in both 5.3.14 and 5.4.4
On Thu, Jun 14, 2012 at 6:33 PM, Michael Felt wrote:
> Well, I am wondering if I posted this wrong - where are all the [PHP-DEV]
> brackets coming from.
>
On 14 June 2012 17:50, Ángel González wrote:
*snip*
> May I ask how would you end up at the situation where the attackers have
> the password hashes but not the salt?
>
> Any process which needs to read the password hashes will also need
> knowledge of the salt. Thus an attacker would most likel
Well, I am wondering if I posted this wrong - where are all the [PHP-DEV]
brackets coming from.
But, i believe I found the "syntax" error - by default AIX compiler does
not support // comments, the CFLAG
-qlangval=extc99 (or extc89) needs to be added.
Testing further with 5.3.14 and 5.4.4
Michae
On 14/06/12 00:58, Michael Felt wrote:
> Hi.
>
> I am trying to compile php against httpd 2.4.2 - but before it gets
> interesting I think I am having a different problem.
>
> The sqlite3 embedded in ./ext/sqlite3 returns a syntax error against vac.C
> v11 compiler.
>
> data/prj/php-5.3.13/ext/sqli
On 13/06/12 05:26, Morgan L. Owens wrote:
> After reading the performance improvements RFC about interned strings,
> and its passing mention of a "special data structure (e.g.
> zend_string) instead of char*", I've been thinking a little bit about
> this and what such a structure could be.
>
> But
On 14/06/12 16:26, Peter Lind wrote:
> I would say it really depends upon the project. The salt can not only
> protect against rainbow tables and password hash collisions, if it is
> unknown to an attacker then it essentially acts to further strengthen
> the hash by vastly expanding the keyspace. S
Peter,
> I would say it really depends upon the project. The salt can not only
> protect against rainbow tables and password hash collisions, if it is
> unknown to an attacker then it essentially acts to further strengthen
> the hash by vastly expanding the keyspace.
That's not true. There are tw
Thomas,
> This:
>
> http://barebonescms.com/documentation/csprng/
>
> Takes a different approach. Generate one or more stored root seeds and then
> use those seeds to generate as much data as is needed without risking loss
> of entropy. It also accepts extra entropy sources as input - even weak
On 14 June 2012 15:35, Anthony Ferrara wrote:
> Peter,
>
>> Whether or not a CSPRNG is needed depends on what you're doing, your
>> needed level of security. Perhaps add a parameter to control this, so
>> it would be possible to make use of this function even if you need the
>> maximum level of se
On 6/14/2012 6:11 AM, Anthony Ferrara wrote:
Daniel,
Stas has the right approach, not only should the methods be simplified and
platform/algorithm agnostic but have a proper salt built in (there are a
few CSPRNG implementations around), I've seen salts used from numbers to
md5's to just being s
Peter,
> Whether or not a CSPRNG is needed depends on what you're doing, your
> needed level of security. Perhaps add a parameter to control this, so
> it would be possible to make use of this function even if you need the
> maximum level of security? If it's not available, the function should
> f
Hello!
The PHP Development Team announces the immediate availability of PHP 5.4.4
and PHP 5.3.14. The releases two security related issues and over 30 bugs.
The release fixes two security issues: A weakness in the DES
implementation of crypt() and a heap overflow issue in the phar extension.
Al
* snip*
>> Stas has the right approach, not only should the methods be simplified and
>> platform/algorithm agnostic but have a proper salt built in (there are a
>> few CSPRNG implementations around), I've seen salts used from numbers to
>> md5's to just being skipped altogether.
>
> Well, just to
Daniel,
> However, I'd like to throw in scrypt as well. Thoughts?
Yes, that's something to include for sure. I've actually been working
on the side on an implementation of scrypt to sit next to my pbkdf2
proposal as hash_scrypt (as the native function, so that it can be
used natively (without the
Hi Nikita,
I think you might just get everyone behind this; easily!
However, I'd like to throw in scrypt as well. Thoughts?
Stas has the right approach, not only should the methods be simplified and
platform/algorithm agnostic but have a proper salt built in (there are a
few CSPRNG implementatio
Simon,
> I personally would rename the 2nd parameter to $data as this function is not
> only meant for creating secure hashes from passwords.
Well, I understand your sentiment. But PBKDF stands for Password Based
Key Derivation Function. Even the spec calls that parameter password:
PBKDF2 (P, S
Am Mi, 13.06.2012, 00:06 schrieb Nikita Popov:
> That's how it is currently implemented. The generator backs up the
> current execution context (execute_data, CVs, Ts), pushed stack
> arguments and several executor globals. When the generator is resumed
> everything is restored and it continues to
Hi, Anthony
I personally would rename the 2nd parameter to $data as this function is
not only meant for creating secure hashes from passwords.
Bye
Simon
On Thu, Jun 14, 2012 at 4:00 AM, Anthony Ferrara wrote:
> Hello all,
>
> I've written up a quick draft version of an RFC for pull request 105
26 matches
Mail list logo
