Re: [PHP-DEV] Constant arrays

[jpauli]

Okay, but those effectively don't exist in PHP ;)

Julien

On Tue, Dec 20, 2011 at 11:43 PM, David Muir  wrote:

> On 12/21/2011 03:37 AM, jpauli wrote:
> > I guess constant array would mean that all the variables inside the array
> > dimensions should not change.
> > Just saying that, is a nonsense.
> >
> > If a constant could be an array, then that array could not contain
> > variables, if not it wouldn't be constant any more as a change to one
> > variable inside it would change its own meaning value.
> >
> > Julien.P
> >
> >
>
> A constant can only contain static values. There was no mention of
> variables.
>
> Isn't a "constant" array basically the same as an Enum?
>
> David
>

[PHP-DEV] Debugging internal array corruption

[Steve Hanselman]

Hi all,



Looking for a pointer on internals layout.



I've an issue whereby php is seg faulting during a print_r, I can see
that the corruption has already occurred in the hash at the start of the
print_r, so now I want to set a breakpoint at the point that an entry is
added to an array (so I can then add a watch on the correct address).



Any pointers as to the file/function that I'd be looking for?





The information contained in this email is intended for the personal and 
confidential use
of the addressee only. It may also be privileged information. If you are not 
the intended
recipient then you are hereby notified that you have received this document in 
error and
that any review, distribution or copying of this document is strictly 
prohibited. If you have
received  this communication in error, please notify Brendata immediately on:

+44 (0)1268 466100, or email 'techni...@brendata.co.uk'

Brendata (UK) Ltd
Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX  UK
Registered Office as above. Registered in England No. 2764339

See our current vacancies at www.brendata.co.uk

Re: [PHP-DEV] Fixing string offsets of strings.

[Alan Knowles]

The fix for the warning is to use 0, rather than -1 as the last argument 
for is_numeric_string(), only in the zend_vm - isset code - it's a 
usefull warning when not used with isset.


I'm just testing a patch and the related tests and will upload it to the 
bug soon.


Regards
Alan

On Monday, December 19, 2011 09:19 AM, Stas Malyshev wrote:

Hi!


This should implement the isset() return false, and accessing producing
a warning (but 'less'  BC by returning the first character)

https://bugs.php.net/patch-display.php?bug_id=60362&patch=isset_changed_warning_only_on_access.patch&revision=latest 

 



I did end up changing most of the error messages in the affected tests
to  "%s on line %d" is that the prefered way of doing it?


One note about this: conversion behavior is non-obvious there, e.g.:

'foo' - gets converted to 0 and produces: Illegal string offset 'foo'
'12.34' - gets converted to 12 and produces: Illegal string offset 
'12.34'
but '56 and foo' - gets converted to 56 and produces: A non well 
formed numeric value encountered


I guess it's ok but error messages are different.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Fixing string offsets of strings.

[Alan Knowles]

Done

https://bugs.php.net/patch-display.php?bug_id=60362&patch=fix_to_prevent_warning_on_isset_empty_for_55_and_a_half.patch&revision=latest 



BTW these are failing in head at present - I guess somebody is working 
on them...

globals in global scope [Zend/tests/globals_001.phpt]
globals in local scope [Zend/tests/globals_002.phpt]
globals in local scope - 2 [Zend/tests/globals_003.phpt]
globals in local scope - 3 [Zend/tests/globals_004.phpt]
unset() CV 7 (indirect unset() of global variable in 
import_request_variables()) [Zend/tests/unset_cv07.phpt]


Regards
Alan

On Wednesday, December 21, 2011 10:23 PM, Alan Knowles wrote:
The fix for the warning is to use 0, rather than -1 as the last 
argument for is_numeric_string(), only in the zend_vm - isset code - 
it's a usefull warning when not used with isset.


I'm just testing a patch and the related tests and will upload it to 
the bug soon.


Regards
Alan

On Monday, December 19, 2011 09:19 AM, Stas Malyshev wrote:

Hi!


This should implement the isset() return false, and accessing producing
a warning (but 'less'  BC by returning the first character)

https://bugs.php.net/patch-display.php?bug_id=60362&patch=isset_changed_warning_only_on_access.patch&revision=latest 

 



I did end up changing most of the error messages in the affected tests
to  "%s on line %d" is that the prefered way of doing it?


One note about this: conversion behavior is non-obvious there, e.g.:

'foo' - gets converted to 0 and produces: Illegal string offset 'foo'
'12.34' - gets converted to 12 and produces: Illegal string offset 
'12.34'
but '56 and foo' - gets converted to 56 and produces: A non well 
formed numeric value encountered


I guess it's ok but error messages are different.

[PHP-DEV] CS random values

[Tom Worster]

Hi, I'm new to this list so please tolerate my unfamiliarity with
protocol.

PHP does not in general allow access to the underlying system¹s
entropy source. I think it would be a good idea if it did.

It is routine for web developers to write code in PHP that stores
passwords in database tables or other persistent stores. In these
cases a one-way hash is generally used (and PHP¹s crypt() is very
good here). In such schemes, the password must be salted to
protect against known hash lookups. But the salt must be a
**cryptographically secure** random value. (This is just one
example of when a CS random value is needed, but a very common
one.)

I recently attempted to write a function in PHP that would return
CS random bytes from the system¹s entropy source. I was unable to
do it.

1. /dev/random and /dev/urandom are unavailable on Windows and
cannot be fopen()¹ed in safe mode on *nix/nux

2. openssl_random_pseudo_bytes() requires openssl extension
installed and enabled. Most of the popular AMP packages for
Windows fail on this count. Many shared web hosts don¹t have it
either.

3. mcrypt_create_iv() depends on mcrypt extension and so suffers
similar problems as openssl

4. Another method is to set runtime config param
session.entropy_length followed by @session_start();
session_regenerate_id(); after which session_id() will return a
CS random string, but this is also foiled by safe mode.

5. On Windows you could try COM('CAPICOM.Utilities.1')->GetRandom
but that API is obsolescent and not in many default Windows
installs.

6. Last chance is new DOTNET('mscorlib',
'System.Security.Cryptography.RNGCryptoServiceProvider') etc
requires a working and compatible .NET framework.

At this point the best bet is probably to hash some bytes from
mt_rand() with microtime() and return that but trigger a warning
about security. This is a very poor substitute.

And given the routine need for CS random numbers in PHP
applications, it is, in my view, not satisfactory.

My proposal is to put a new function into basic_functions along
side mt_rand(). I suggest naming it cs_rand(), cs being mnemonic
for crypto secure. It should appear in the same sections of the
manual as mt_rand() and rand() and both of those manual entries
should call out the fact that they are not crypto secure and refer
to cs_rand().

I propose an implementation broadly similar to mcrypt_create_iv(),
see php-5.3.8/ext/mcrypt/mcrypt.c lines 1373 thru 1434. (Even
though I haven¹t programmed in C since the 1980s, this doesn¹t
look hard.)

But I suggest a different signature. openssl_random_pseudo_bytes()
is a better model. mcrypt_create_iv()¹s $source argument should be
avoided, it just confuses the user.
openssl_random_pseudo_bytes()¹s &$crypto_strong response is
valuable. I would also consider triggering a PHP warning when a
non-crypto strong value is returned.

I would be happy to help with the work. I¹m not sure I¹d do a good
job with the implementation because I haven¹t programmed inside
PHP before while an experienced internist could do it very
quickly. But I may be able to help with test cases and
documentation.

Warm regards
Tom



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CS random values

[Anthony Ferrara]

Tom,

First off, very detailed post!  However, there are a few things I'd
disagree with.

1. Salts for crypt() purposes need to be cryptographically secure
random numbers.

This is not true.  The only requirement is that a salt be reasonably
unique (meaning that the chance of using the same one is pretty low
for the scale of the application.  See this:

http://security.stackexchange.com/a/7195

CS random salts are needed for certain signing algorithms.  But not
for password storage.

Now, there is a need for CS Random numbers in general.  Things like
key generation (which shouldn't be done in PHP to begin with), Nonces
and One-Time Pads require secure random numbers.  But in general, most
uses in PHP would suffice with a normal quality PRN.

2. I was unable to do it.

I did it fine.

https://github.com/ircmaxell/PHP-CryptLib/tree/master/lib/CryptLib/Random

It's an RFC4086 compliant CSPRNG
(http://tools.ietf.org/html/rfc4086#section-5.2).  It uses multiple
sources to generate the final number, and mixes them together using
cryptographically secure methods.  Sure, in a perfect storm situation
(Linux, Safe Mode, without OpenSSL, without MCrypt, etc) it would only
use mt_rand() + rand() + uniqid() + microtime(), which is still pretty
secure (in the sense that both bias and predictability are both
virtually non-existent due to the mixing step).

3. My proposal is to put a new function into basic_functions along
side mt_rand(). I suggest naming it cs_rand()

I would be against this proposal.  CS random numbers are something
that shouldn't be over used.  Otherwise you can wind up either running
out of entropy on the system (causing blocking while more is
"gathered") or reducing the quality of the random numbers.  I don't
think normal developers understand the difference and when each is
required.

I would be for a proposal to add a salt generation function though
(similar to BCrypt.gensalt()).

Thanks,

Anthony

On Wed, Dec 21, 2011 at 10:31 AM, Tom Worster  wrote:
> Hi, I'm new to this list so please tolerate my unfamiliarity with
> protocol.
>
> PHP does not in general allow access to the underlying system¹s
> entropy source. I think it would be a good idea if it did.
>
> It is routine for web developers to write code in PHP that stores
> passwords in database tables or other persistent stores. In these
> cases a one-way hash is generally used (and PHP¹s crypt() is very
> good here). In such schemes, the password must be salted to
> protect against known hash lookups. But the salt must be a
> **cryptographically secure** random value. (This is just one
> example of when a CS random value is needed, but a very common
> one.)
>
> I recently attempted to write a function in PHP that would return
> CS random bytes from the system¹s entropy source. I was unable to
> do it.
>
> 1. /dev/random and /dev/urandom are unavailable on Windows and
> cannot be fopen()¹ed in safe mode on *nix/nux
>
> 2. openssl_random_pseudo_bytes() requires openssl extension
> installed and enabled. Most of the popular AMP packages for
> Windows fail on this count. Many shared web hosts don¹t have it
> either.
>
> 3. mcrypt_create_iv() depends on mcrypt extension and so suffers
> similar problems as openssl
>
> 4. Another method is to set runtime config param
> session.entropy_length followed by @session_start();
> session_regenerate_id(); after which session_id() will return a
> CS random string, but this is also foiled by safe mode.
>
> 5. On Windows you could try COM('CAPICOM.Utilities.1')->GetRandom
> but that API is obsolescent and not in many default Windows
> installs.
>
> 6. Last chance is new DOTNET('mscorlib',
> 'System.Security.Cryptography.RNGCryptoServiceProvider') etc
> requires a working and compatible .NET framework.
>
> At this point the best bet is probably to hash some bytes from
> mt_rand() with microtime() and return that but trigger a warning
> about security. This is a very poor substitute.
>
> And given the routine need for CS random numbers in PHP
> applications, it is, in my view, not satisfactory.
>
> My proposal is to put a new function into basic_functions along
> side mt_rand(). I suggest naming it cs_rand(), cs being mnemonic
> for crypto secure. It should appear in the same sections of the
> manual as mt_rand() and rand() and both of those manual entries
> should call out the fact that they are not crypto secure and refer
> to cs_rand().
>
> I propose an implementation broadly similar to mcrypt_create_iv(),
> see php-5.3.8/ext/mcrypt/mcrypt.c lines 1373 thru 1434. (Even
> though I haven¹t programmed in C since the 1980s, this doesn¹t
> look hard.)
>
> But I suggest a different signature. openssl_random_pseudo_bytes()
> is a better model. mcrypt_create_iv()¹s $source argument should be
> avoided, it just confuses the user.
> openssl_random_pseudo_bytes()¹s &$crypto_strong response is
> valuable. I would also consider triggering a PHP warning when a
> non-crypto strong value is returned.
>
> I would be happy to 

Re: [PHP-DEV] CS random values

[Kiall Mac Innes]

On Wed, Dec 21, 2011 at 3:31 PM, Tom Worster  wrote:
>
> 1. /dev/random and /dev/urandom are unavailable on Windows and
> cannot be fopen()¹ed in safe mode on *nix/nux

Safe mode has been deprecated for two and a half years.. Adding features to
work around its limitations is (IMO) a bad idea..
Can't argue with it being unavailable on windows..

>
>
> 2. openssl_random_pseudo_bytes() requires openssl extension
> installed and enabled. Most of the popular AMP packages for
> Windows fail on this count. Many shared web hosts don¹t have it
> either.

As far as I remember, WAMP Server (Arguably the most popular AMP package
for windows) does include openssl support. Its simply disabled by default
like everything else! Some quick googling seems to confirm this..

Some more googling confirms XAMPP also includes OpenSSL out of the box..

>
>
> 3. mcrypt_create_iv() depends on mcrypt extension and so suffers
> similar problems as openssl

mcrypt again comes with both WAMP and XAMPP servers, but disabled by
default.


> 4. Another method is to set runtime config param
> session.entropy_length followed by @session_start();
> session_regenerate_id(); after which session_id() will return a
> CS random string, but this is also foiled by safe mode.

This is obviously not a solution, even if it worked... ;)

>
>
> 5. On Windows you could try COM('CAPICOM.Utilities.1')->GetRandom
> but that API is obsolescent and not in many default Windows
> installs.

I can't speak for windows specific APIs So I'm going to ignore the rest!

It seems that the two preferable cross platform options (openssl and
mcrypt) are already both widely available on all platforms, I'm not sure I
see the need to be honest.

Kiall

Re: [PHP-DEV] Return Type Hinting for Methods RFC

[Nikita Popov]

Hi Will!

One random thought I had while reading the RFC is: What about the
newly introduced callable typehint? Is this missing by intention? I
could well imagine so (because it's hard to check what scope
callability should be checked on), but wanted to be sure on that.

Nikita

On Wed, Dec 21, 2011 at 3:09 AM, Will Fitch  wrote:
> Hello All,
>
> I would like to submit https://wiki.php.net/rfc/returntypehint2 into 
> discussion.  A link to the patch for this is provided and can be ran against 
> the current HEAD.
>
> There is an older entry still in existence, but this patch is syntactically 
> different.  The older entry is located at 
> https://wiki.php.net/rfc/typechecking and is bundled with parameter, scalars, 
> etc.
>
> If possible, can someone promote this to the "Under Discussion" category 
> within https://wiki.php.net/rfc?
>
> -- Will
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CS random values

[Tom Worster]

Hi Anthony,

Thank your for your reply. I inserted some comments below.

On 12/21/11 11:19 AM, "Anthony Ferrara"  wrote:

>2. I was unable to do it.
>
>I did it fine.
>
>https://github.com/ircmaxell/PHP-CryptLib/tree/master/lib/CryptLib/Random

I think it nicely demonstrates a degree of sophistication that should
not be expected from typical PHP usrs.


>It's an RFC4086 compliant CSPRNG
>(http://tools.ietf.org/html/rfc4086#section-5.2).  It uses multiple
>sources to generate the final number, and mixes them together using
>cryptographically secure methods.  Sure, in a perfect storm situation
>(Linux, Safe Mode, without OpenSSL, without MCrypt, etc) it would only
>use mt_rand() + rand() + uniqid() + microtime(), which is still pretty
>secure (in the sense that both bias and predictability are both
>virtually non-existent due to the mixing step).

Right here you explain how your lib fails in exactly the same way that
my attempt did. I was surprised how common it is that PHP has safe mode,
and no mcrypt or openssl. The very first user of my function (other than
myself) reported this situation on two different platforms! So I don't
think it's right to call it a "perfect storm" because that implies that
it is very uncommon.

[I don't think mixing mt_rand() + rand() + uniqid() + microtime() is
really much better than mixing only mt_rand() + microtime().]


>3. My proposal is to put a new function into basic_functions along
>side mt_rand(). I suggest naming it cs_rand()
>
>I would be against this proposal.  CS random numbers are something
>that shouldn't be over used.  Otherwise you can wind up either running
>out of entropy on the system (causing blocking while more is
>"gathered") or reducing the quality of the random numbers.  I don't
>think normal developers understand the difference and when each is
>required.

This argument is based on two premises that I don't accept

1. PHP users cannot be trusted with access to the system's entropy
pool lest they dangerously deplete it.

2. Keeping things as they are protects the entropy pool from overuse.

The first is too presumptuous. Moreover, I don't think inhibiting
access through the PHP API design is the right way to mitigate against
such problems, it is too blunt a tool.

The second is simply false in the case that one of PHP's 4 existing
APIs to the system CSPRNG is available.


>I would be for a proposal to add a salt generation function though
>(similar to BCrypt.gensalt()).

This is a good proposal. But it's not an alternative, in my view.



>
>Thanks,
>
>Anthony
>
>On Wed, Dec 21, 2011 at 10:31 AM, Tom Worster  wrote:
>> Hi, I'm new to this list so please tolerate my unfamiliarity with
>> protocol.
>>
>> PHP does not in general allow access to the underlying system¹s
>> entropy source. I think it would be a good idea if it did.
>>
>> It is routine for web developers to write code in PHP that stores
>> passwords in database tables or other persistent stores. In these
>> cases a one-way hash is generally used (and PHP¹s crypt() is very
>> good here). In such schemes, the password must be salted to
>> protect against known hash lookups. But the salt must be a
>> **cryptographically secure** random value. (This is just one
>> example of when a CS random value is needed, but a very common
>> one.)
>>
>> I recently attempted to write a function in PHP that would return
>> CS random bytes from the system¹s entropy source. I was unable to
>> do it.
>>
>> 1. /dev/random and /dev/urandom are unavailable on Windows and
>> cannot be fopen()¹ed in safe mode on *nix/nux
>>
>> 2. openssl_random_pseudo_bytes() requires openssl extension
>> installed and enabled. Most of the popular AMP packages for
>> Windows fail on this count. Many shared web hosts don¹t have it
>> either.
>>
>> 3. mcrypt_create_iv() depends on mcrypt extension and so suffers
>> similar problems as openssl
>>
>> 4. Another method is to set runtime config param
>> session.entropy_length followed by @session_start();
>> session_regenerate_id(); after which session_id() will return a
>> CS random string, but this is also foiled by safe mode.
>>
>> 5. On Windows you could try COM('CAPICOM.Utilities.1')->GetRandom
>> but that API is obsolescent and not in many default Windows
>> installs.
>>
>> 6. Last chance is new DOTNET('mscorlib',
>> 'System.Security.Cryptography.RNGCryptoServiceProvider') etc
>> requires a working and compatible .NET framework.
>>
>> At this point the best bet is probably to hash some bytes from
>> mt_rand() with microtime() and return that but trigger a warning
>> about security. This is a very poor substitute.
>>
>> And given the routine need for CS random numbers in PHP
>> applications, it is, in my view, not satisfactory.
>>
>> My proposal is to put a new function into basic_functions along
>> side mt_rand(). I suggest naming it cs_rand(), cs being mnemonic
>> for crypto secure. It should appear in the same sections of the
>> manual as mt_rand() and rand() and both of those manual e

Re: [PHP-DEV] Return Type Hinting for Methods RFC

[Will Fitch]

Hi Nikita,

I didn't add that as it's not yet in production.  As soon as things are 
finalized and 5.4 is GA, I will gladly add the callable type hint.  The change 
wouldn't be different from parameter type hinting, and can easily be added.

On Dec 21, 2011, at 12:17 PM, Nikita Popov wrote:

> Hi Will!
> 
> One random thought I had while reading the RFC is: What about the
> newly introduced callable typehint? Is this missing by intention? I
> could well imagine so (because it's hard to check what scope
> callability should be checked on), but wanted to be sure on that.
> 
> Nikita
> 
> On Wed, Dec 21, 2011 at 3:09 AM, Will Fitch  wrote:
>> Hello All,
>> 
>> I would like to submit https://wiki.php.net/rfc/returntypehint2 into 
>> discussion.  A link to the patch for this is provided and can be ran against 
>> the current HEAD.
>> 
>> There is an older entry still in existence, but this patch is syntactically 
>> different.  The older entry is located at 
>> https://wiki.php.net/rfc/typechecking and is bundled with parameter, 
>> scalars, etc.
>> 
>> If possible, can someone promote this to the "Under Discussion" category 
>> within https://wiki.php.net/rfc?
>> 
>> -- Will
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CS random values

[Tom Worster]

On 12/21/11 12:07 PM, "Kiall Mac Innes"  wrote:

>On Wed, Dec 21, 2011 at 3:31 PM, Tom Worster  wrote:
>>
>> 1. /dev/random and /dev/urandom are unavailable on Windows and
>> cannot be fopen()¹ed in safe mode on *nix/nux
>
>Safe mode has been deprecated for two and a half years.. Adding features
>to work around its limitations is (IMO) a bad idea..

Why do you think so?


>>
>> 2. openssl_random_pseudo_bytes() requires openssl extension
>> installed and enabled. Most of the popular AMP packages for
>> Windows fail on this count. Many shared web hosts don¹t have it
>> either.
>
>As far as I remember, WAMP Server (Arguably the most popular AMP package
>for windows) does include openssl support. Its simply disabled by default
>like everything else! Some quick googling seems to confirm this..
>Some more googling confirms XAMPP also includes OpenSSL out of the box..

Default configs are a big issue. It's hard to overestimate this.

Then, once the user knows to do so, configuring openssl on wamp is
reasonably straight forward. Much less so on xampp.

But all this is often moot since the app developer often has no
way to reconfigure the host other than to switch hosting provider
and often that is not a decision the developer makes.


> 
>>3. mcrypt_create_iv() depends on mcrypt extension and so suffers
>> similar problems as openssl
>
>mcrypt again comes with both WAMP and XAMPP servers, but disabled by
>default.

See my responses above.


> 
>> 4. Another method is to set runtime config param
>> session.entropy_length followed by @session_start();
>> session_regenerate_id(); after which session_id() will return a
>> CS random string, but this is also foiled by safe mode.
>
>This is obviously not a solution, even if it worked... ;)

It covers the case when mcrypt and openssl are not available but
safe mode is off.

What's wrong with it otherwise?


>  5. On Windows you could try COM('CAPICOM.Utilities.1')->GetRandom
>> but that API is obsolescent and not in many default Windows
>> installs.
>
>I can't speak for windows specific APIs So I'm going to ignore the rest!
>It seems that the two preferable cross platform options (openssl and
>mcrypt) are already both widely available on all platforms, I'm not sure
>I see the need to be honest.

I couldn't find a machine or VM on which I could make these Windows
APIs work.

I disagree with your assessment about availability. In my
experience, safe mode combined with an absence of both mcrypt and
openssl is quite common.

For the sake of argument, assume that the availability problem
is not trivial and someone was hired to write an app for a
customer and you don't know what it will be run on. Your best bet
would be to use something like what Anthony Ferrara wrote that
tries everything and falls back on a non-CS source. 1. this is
way too sophisticated for most people; 2. it's really hard to
test; 3. you don't know if your client is secure or not; 4. it
just seems a bit much for PHP to say "No, you can't have access
to the system's CSPRNG, instead you can do this:
https://github.com/ircmaxell/PHP-CryptLib/tree/master/lib/CryptLib/Random

"

Tom



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Fixing string offsets of strings.

[Stas Malyshev]

Hi!


BTW these are failing in head at present - I guess somebody is working
on them...
globals in global scope [Zend/tests/globals_001.phpt]
globals in local scope [Zend/tests/globals_002.phpt]
globals in local scope - 2 [Zend/tests/globals_003.phpt]
globals in local scope - 3 [Zend/tests/globals_004.phpt]
unset() CV 7 (indirect unset() of global variable in
import_request_variables()) [Zend/tests/unset_cv07.phpt]


You mean in trunk? Because in 5.4 no tests are failing for me.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CS random values

[Pierre Joye]

hi,

Some short comments:

On Wed, Dec 21, 2011 at 4:31 PM, Tom Worster  wrote:

> PHP does not in general allow access to the underlying system¹s
> entropy source. I think it would be a good idea if it did.

It does on unix using the almost generally available random and
urandom. On Windows you can use the openssl_random_pseudo_bytes
function which does not rely on the OpenSSL API but the Windows native
Crypto APIs.



> 1. /dev/random and /dev/urandom are unavailable on Windows and
> cannot be fopen()¹ed in safe mode on *nix/nux

Well, bad admins forgot to allow access to these files. Maybe we
should add that to the documentations.

> 2. openssl_random_pseudo_bytes() requires openssl extension
> installed and enabled. Most of the popular AMP packages for
> Windows fail on this count. Many shared web hosts don¹t have it
> either.

See my previous comment about windows.

For shared hosts not providing openssl, I would suggest (strongly) to
look for better hosting solutions.

> 3. mcrypt_create_iv() depends on mcrypt extension and so suffers
> similar problems as openssl

How so? The entropy source on windows is the same than the one in
openssl and uses the windows crypto API.

> 4. Another method is to set runtime config param
> session.entropy_length followed by @session_start();
> session_regenerate_id(); after which session_id() will return a
> CS random string, but this is also foiled by safe mode.

Btw, entropy src on windows benefits from the same implementation than
mcrypt and openssl.

> 5. On Windows you could try COM('CAPICOM.Utilities.1')->GetRandom
> but that API is obsolescent and not in many default Windows
> installs.

That's what the random bytes function uses. Or to be more exact,
CAPICOM uses the same same underlying API.


> 6. Last chance is new DOTNET('mscorlib',
> 'System.Security.Cryptography.RNGCryptoServiceProvider') etc
> requires a working and compatible .NET framework.

Same comment as in pt. 5


> At this point the best bet is probably to hash some bytes from
> mt_rand() with microtime() and return that but trigger a warning
> about security. This is a very poor substitute.

They are by no way crypto safe. Openssl's random function on unix can
fail to be crypto safe as well. On windows, it is always crypto safe.


Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Return Type Hinting for Methods RFC

[Pierre Joye]

hi Will,

You should add it now, while 5.4 final is not released yet, this
feature exists already and should be part of the RFC, to be complete.

Cheers,

On Wed, Dec 21, 2011 at 6:22 PM, Will Fitch  wrote:
> Hi Nikita,
>
> I didn't add that as it's not yet in production.  As soon as things are 
> finalized and 5.4 is GA, I will gladly add the callable type hint.  The 
> change wouldn't be different from parameter type hinting, and can easily be 
> added.
>
> On Dec 21, 2011, at 12:17 PM, Nikita Popov wrote:
>
>> Hi Will!
>>
>> One random thought I had while reading the RFC is: What about the
>> newly introduced callable typehint? Is this missing by intention? I
>> could well imagine so (because it's hard to check what scope
>> callability should be checked on), but wanted to be sure on that.
>>
>> Nikita
>>
>> On Wed, Dec 21, 2011 at 3:09 AM, Will Fitch  wrote:
>>> Hello All,
>>>
>>> I would like to submit https://wiki.php.net/rfc/returntypehint2 into 
>>> discussion.  A link to the patch for this is provided and can be ran 
>>> against the current HEAD.
>>>
>>> There is an older entry still in existence, but this patch is syntactically 
>>> different.  The older entry is located at 
>>> https://wiki.php.net/rfc/typechecking and is bundled with parameter, 
>>> scalars, etc.
>>>
>>> If possible, can someone promote this to the "Under Discussion" category 
>>> within https://wiki.php.net/rfc?
>>>
>>> -- Will
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Return Type Hinting for Methods RFC

[Will Fitch]

Will add tonight and generate a new patch.  


On Dec 21, 2011, at 2:33 PM, Pierre Joye wrote:

> hi Will,
> 
> You should add it now, while 5.4 final is not released yet, this
> feature exists already and should be part of the RFC, to be complete.
> 
> Cheers,
> 
> On Wed, Dec 21, 2011 at 6:22 PM, Will Fitch  wrote:
>> Hi Nikita,
>> 
>> I didn't add that as it's not yet in production.  As soon as things are 
>> finalized and 5.4 is GA, I will gladly add the callable type hint.  The 
>> change wouldn't be different from parameter type hinting, and can easily be 
>> added.
>> 
>> On Dec 21, 2011, at 12:17 PM, Nikita Popov wrote:
>> 
>>> Hi Will!
>>> 
>>> One random thought I had while reading the RFC is: What about the
>>> newly introduced callable typehint? Is this missing by intention? I
>>> could well imagine so (because it's hard to check what scope
>>> callability should be checked on), but wanted to be sure on that.
>>> 
>>> Nikita
>>> 
>>> On Wed, Dec 21, 2011 at 3:09 AM, Will Fitch  wrote:
 Hello All,
 
 I would like to submit https://wiki.php.net/rfc/returntypehint2 into 
 discussion.  A link to the patch for this is provided and can be ran 
 against the current HEAD.
 
 There is an older entry still in existence, but this patch is 
 syntactically different.  The older entry is located at 
 https://wiki.php.net/rfc/typechecking and is bundled with parameter, 
 scalars, etc.
 
 If possible, can someone promote this to the "Under Discussion" category 
 within https://wiki.php.net/rfc?
 
 -- Will
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
>> 
>> 
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
> 
> 
> 
> -- 
> Pierre
> 
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CS random values

[Anthony Ferrara]

Tom,

> I think it nicely demonstrates a degree of sophistication that should
> not be expected from typical PHP usrs.

Which is why it should be available in a library of some form.  Could
it be in core?  Absolutely.  Does it need to be?  Nope...

> [I don't think mixing mt_rand() + rand() + uniqid() + microtime() is
> really much better than mixing only mt_rand() + microtime().]

The key is not the sources, but how they are mixed.  The RFC quoted
shows how to mix in a way that as long as you have one non-compromised
source, the final output is always at least as random as the strongest
non-compromised source.  In practice it will be significantly stronger
since most compromises of sources are not total.

> 1. PHP users cannot be trusted with access to the system's entropy> pool lest 
> they dangerously deplete it.
Honestly, if you need to access the system's entropy pool, then go for
it.  But creating a new _rand() function will give easy access without
any warning or frankly need.  I'll explain later...

> 2. Keeping things as they are protects the entropy pool from overuse.

No, it makes it so that it's hard to *accidentally* use the entropy
pool just because you saw the function somewhere.  If you need it,
it's there...

With respect to the cs_rand() proposal, there is another argument
against it.  In PHP, there's *very* little use for a Cryptographically
Secure random integers.  There are significant uses for random
strings, but not numbers.  Sure, you can convert an integer to a
string fairly easily.  But it's actually pretty hard to do so in a
manner that maintains the cryptographic security of the values...  So
why add a function that has little direct use, but can be
significantly abused?  Especially when using them for generating
random strings can be difficult to the point where it's easy to
generate non-secure strings from a secure source.

If you want to add a cryptographically secure PRNG to PHP, add it so
that it returns a string of the specified length.  But again, I'm
concerned about adding it since it will be abused.  Even your original
point about salts would abuse such a function.  CSPRNs do have
important uses.  But they should NOT be used for cases where you don't
truly need cryptographic security (as each use reduces the available
entropy in the system, and can under certain circumstances make other
secure applications less secure).

2011/12/21 Tom Worster :
> Hi Anthony,
>
> Thank your for your reply. I inserted some comments below.
>
> On 12/21/11 11:19 AM, "Anthony Ferrara"  wrote:
>
>>2. I was unable to do it.
>>
>>I did it fine.
>>
>>https://github.com/ircmaxell/PHP-CryptLib/tree/master/lib/CryptLib/Random
>
> I think it nicely demonstrates a degree of sophistication that should
> not be expected from typical PHP usrs.
>
>
>>It's an RFC4086 compliant CSPRNG
>>(http://tools.ietf.org/html/rfc4086#section-5.2).  It uses multiple
>>sources to generate the final number, and mixes them together using
>>cryptographically secure methods.  Sure, in a perfect storm situation
>>(Linux, Safe Mode, without OpenSSL, without MCrypt, etc) it would only
>>use mt_rand() + rand() + uniqid() + microtime(), which is still pretty
>>secure (in the sense that both bias and predictability are both
>>virtually non-existent due to the mixing step).
>
> Right here you explain how your lib fails in exactly the same way that
> my attempt did. I was surprised how common it is that PHP has safe mode,
> and no mcrypt or openssl. The very first user of my function (other than
> myself) reported this situation on two different platforms! So I don't
> think it's right to call it a "perfect storm" because that implies that
> it is very uncommon.
>
> [I don't think mixing mt_rand() + rand() + uniqid() + microtime() is
> really much better than mixing only mt_rand() + microtime().]
>
>
>>3. My proposal is to put a new function into basic_functions along
>>side mt_rand(). I suggest naming it cs_rand()
>>
>>I would be against this proposal.  CS random numbers are something
>>that shouldn't be over used.  Otherwise you can wind up either running
>>out of entropy on the system (causing blocking while more is
>>"gathered") or reducing the quality of the random numbers.  I don't
>>think normal developers understand the difference and when each is
>>required.
>
> This argument is based on two premises that I don't accept
>
> 1. PHP users cannot be trusted with access to the system's entropy
> pool lest they dangerously deplete it.
>
> 2. Keeping things as they are protects the entropy pool from overuse.
>
> The first is too presumptuous. Moreover, I don't think inhibiting
> access through the PHP API design is the right way to mitigate against
> such problems, it is too blunt a tool.
>
> The second is simply false in the case that one of PHP's 4 existing
> APIs to the system CSPRNG is available.
>
>
>>I would be for a proposal to add a salt generation function though
>>(similar to BCrypt.gensalt()).
>
> This is a good prop

Re: [PHP-DEV] Return Type Hinting for Methods RFC

[Will Fitch]

Hi Pierre and Nikita,

I have added callable to the patch and updated the RFC entry to reflect the 
changes. Please verify and let me know if you have any issues.

On Dec 21, 2011, at 2:33 PM, Pierre Joye wrote:

> hi Will,
> 
> You should add it now, while 5.4 final is not released yet, this
> feature exists already and should be part of the RFC, to be complete.
> 
> Cheers,
> 
> On Wed, Dec 21, 2011 at 6:22 PM, Will Fitch  wrote:
>> Hi Nikita,
>> 
>> I didn't add that as it's not yet in production.  As soon as things are 
>> finalized and 5.4 is GA, I will gladly add the callable type hint.  The 
>> change wouldn't be different from parameter type hinting, and can easily be 
>> added.
>> 
>> On Dec 21, 2011, at 12:17 PM, Nikita Popov wrote:
>> 
>>> Hi Will!
>>> 
>>> One random thought I had while reading the RFC is: What about the
>>> newly introduced callable typehint? Is this missing by intention? I
>>> could well imagine so (because it's hard to check what scope
>>> callability should be checked on), but wanted to be sure on that.
>>> 
>>> Nikita
>>> 
>>> On Wed, Dec 21, 2011 at 3:09 AM, Will Fitch  wrote:
 Hello All,
 
 I would like to submit https://wiki.php.net/rfc/returntypehint2 into 
 discussion.  A link to the patch for this is provided and can be ran 
 against the current HEAD.
 
 There is an older entry still in existence, but this patch is 
 syntactically different.  The older entry is located at 
 https://wiki.php.net/rfc/typechecking and is bundled with parameter, 
 scalars, etc.
 
 If possible, can someone promote this to the "Under Discussion" category 
 within https://wiki.php.net/rfc?
 
 -- Will
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
>> 
>> 
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
> 
> 
> 
> -- 
> Pierre
> 
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php