Re: [PHP-DEV] Thoughts on C version supported for PHP-Next

[Christoph Becker]

Nikita Popov wrote:

> [...] What's our current minimum required vc version?

As of PHP 5.5 at least VC11 (Visual Studio 2012) is required for Windows
builds.  The currently available snapshots of master are also built with
VC11[1].

[1] 

-- 
Christoph M. Becker

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

Re: [PHP-DEV] Thoughts on C version supported for PHP-Next

[Levi Morrison]

On Thu, May 7, 2015 at 12:28 PM, Nikita Popov  wrote:
> On Mon, Jul 28, 2014 at 9:41 PM, Pierre Joye  wrote:
>
>>
>> On Jul 28, 2014 9:14 PM, "Dmitry Stogov"  wrote:
>> >
>> > I think opinions about readability are subjective.
>> >
>> > The real problem, that it'll break compatibility with old uncommon
>> > compilers.
>> > I'm not sure if new MSVC versions support it, but the one I use - does
>> not.
>>
>> We are working with the vc team to test the c99 (c++11/14 as well) with
>> many oss softwares, php included (non core ext).
>>
>> It could be possible to use c99 from a vc pov but not if we decide to
>> release php-next next year. However with the yearly vc release, we could
>> make it for Q4/2015.
>>
> Could you please provide an update on the current situation regarding C99
> support in MSVC? It seems that VS 2013 supports the most important C99
> features [1]. What's our current minimum required vc version?
>
> [1]: https://msdn.microsoft.com/en-us/library/hh409293.aspx

Today I explored what it would take to compile with -std=c90 and
-std=c99. We're actually very close to being valid C99 – we just need
to remove `uint` and `u_char` and define _XOPEN_SOURCE for glibc to
expose some POSIX/UNIX stuff. Those same things have to be done for
C90 compatibility and remove `//` style comments.c.

The function strtoll doesn't exist until C90 and we use it; this means
for C90 we have to use _XOPEN_SOURCE=600 for glibc to give it to us,
but I am unsure how portable this is.

Aside from strtoll we already use several features of C99 such as
`inline`, ``.

In summary: I think we should move to C99 and compile with the
-std=c99 flag. There are also features of C99 that would allow us to
use zend_string* in internal functions instead of char*; this would be
a big win for cleanup since user functions use zend_string* and there
is forked logic because of this.

This is, of course, dependent on the whether the compilers we intend
to support will work with C99. I know that gcc, clang, icc and MS VS
2013 will all work with the basic features of C99 that we use now and
expect to use in the future if we move to C99. Are there any other
known compilers out there that we should check?

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

Re: [PHP-DEV] Thoughts on C version supported for PHP-Next

[Nikita Popov]

On Mon, Jul 28, 2014 at 9:41 PM, Pierre Joye  wrote:

>
> On Jul 28, 2014 9:14 PM, "Dmitry Stogov"  wrote:
> >
> > I think opinions about readability are subjective.
> >
> > The real problem, that it'll break compatibility with old uncommon
> > compilers.
> > I'm not sure if new MSVC versions support it, but the one I use - does
> not.
>
> We are working with the vc team to test the c99 (c++11/14 as well) with
> many oss softwares, php included (non core ext).
>
> It could be possible to use c99 from a vc pov but not if we decide to
> release php-next next year. However with the yearly vc release, we could
> make it for Q4/2015.
>
Could you please provide an update on the current situation regarding C99
support in MSVC? It seems that VS 2013 supports the most important C99
features [1]. What's our current minimum required vc version?

[1]: https://msdn.microsoft.com/en-us/library/hh409293.aspx

Re: [PHP-DEV] password_hash() best practices

[Anthony Ferrara]

Leszek,

On Thu, May 7, 2015 at 2:11 AM, Leszek Krupinski  wrote:
> On Wed, May 6, 2015 at 4:00 PM, Nikita Popov  wrote:
>
>> It should be further noted that there is no standardized crypt() format for
>> PBKDF2 and password_hash() is a crypt-compatible API. As such supporting
>> PBKDF2 there would be very problematic. We do already support it in the
>> form of hash_pbkdf2() and people who wish to use this method (e.g. due to
>> legal restrictions) can use it through this API - I don't see a reason to
>> have it in password_hash(), which should only support the recommended
>> default use case.
>> 
>>
>
> That's true that there's no support for pbkdf2 in crypt. On the other hand,
> the RFC for password_hash stated:
>
>> These hashing APIs will initially be thin wrappers around *crypt()* to
> allow for automatic salt generation and better error checking.
>
> It says "initially" - that's why I understood that in the future we can
> diverge from crypt in situations when there's a great new hash we would
> like to use, but it's not supported by crypt (yet or at all).

That was precisely the intention. For that exact reason.

*HOWEVER* (and this is a big however), I think we should avoid doing
that unless *absolutely* necessary. We should strive to build off
standardized crypto. This is good both from an interoperability
standpoint, and the standpoint of relying on cryptographers to set the
standard. We have few if any professional cryptographers on this
list/project, so we should avoid as much as possible inventing our own
(unless absolutely necessary, in which we can elicit the help of
professionals).

> Also, I'm pro-choice ;) We have an extensible API for password_hash(), and
> because people have different needs (like gpu strain in bcrypt or longer
> passwords in pbdkf2) we should provide an option for more experienced
> users, while having reasonable defaults. Yes, advanced users can use hash
> functions directly, but password_* are so nice :)

Well, I'm not sure I agree here. I think the point of password_hash()
is to raise the bottom barrier. I have said multiple times that it is
not a replacement for crypt(3) or other more complicated tools. It's
meant more as a way for non-experts to implement secure code.

If you need to make a different tradeoff, then you can always use a
different library or more advanced use case. I think that
password_hash() should remain simple, with as few choices as possible
(less for users to screw up).

As far as length protection, you can simply pre-hash with sha-512 and
base64_encode the result:

$prehash = base64_encode(hash('sha512', $password, true));
$hash = password_hash($prehash, PASSWORD_DEFAULT, []);

This is also "inventing" crypto, so I would be extremely wary of
recommending this as a project. If we can get the upstream providers
(specifically the OpenBSD project) to add a crypt(3) format for this
specific case, then we can integrate it into our crypt(3)
implementation, and hence password_hash(). But I would want the
upstream to do it first.

The only algorithm at present that I have seen that today could
replace bcrypt in password_hash is scrypt. However, there are 2
fundamental problems with it: 1) there's no crypt(3) binding or
format. 2) At similar cost settings to what most users use bcrypt at
(< 0.1 second runtime), it's been shown to be at best no stronger than
bcrypt, or at worst several times weaker.

There is currently a competition for a new password hashing algorithm:
https://password-hashing.net/ I've been watching it fairly closely,
but many of the algorithms suffer a similar "weaker than bcrypt at low
runtime" problem. The main reason for this is that they are mainly
targeting different use-cases than password_hash targets. Namely, they
are looking at key derivation and login where you can dedicate a login
server (and hence keep potentially GB of memory persistent for use in
hashing). While these techniques are far superior if you can dedicate
the hardware to them, they don't solve the same problem that we're
solving with password_hash.

We could use scrypt or yescrypt (or a few others) as a next-gen
algorithm, but we'd have to be careful with the settings parameters,
as there's more than just one. And it's really easy to screw up the
settings and make it easier for an attacker. Ideally, I wonder if it's
possible for us to simply "proxy" from a single setting (give users a
"cost" setting, and generate an pseudo-ideal set of settings given
that cost).

The bottom line is that I think password_hash needs to stay as simple
as possible. It's not designed to be a full fledged library or set of
primitives. It's designed to be an opinionated library that takes as
much decision away from the user as possible. If you need more
control, use a different library. But for the 98% use-case, that
additional complication simply makes it harder for users to get it
right: http://blog.ircm

Re: [PHP-DEV] password_hash() best practices

[Rowan Collins]

Leszek Krupinski wrote on 07/05/2015 07:11:

On Wed, May 6, 2015 at 4:00 PM, Nikita Popov  wrote:


It should be further noted that there is no standardized crypt() format for
PBKDF2 and password_hash() is a crypt-compatible API. As such supporting
PBKDF2 there would be very problematic.

That's true that there's no support for pbkdf2 in crypt. On the other hand,
the RFC for password_hash stated:


These hashing APIs will initially be thin wrappers around *crypt()* to

allow for automatic salt generation and better error checking.

It says "initially" - that's why I understood that in the future we can
diverge from crypt in situations when there's a great new hash we would
like to use, but it's not supported by crypt (yet or at all).


Notwithstanding the merits of using it in this case, I wonder if there's 
a possibility to invent a syntax recognised by password_hash which is an 
explicit extension of what crypt uses, and is guaranteed not to collide, 
kind of like the "X-" header prefix in HTTP.


If a "standard" format for the same algorithm was added in future, 
password_needs_rehash could return true for the deprecated interim 
format, allowing a smooth transition. (If you explicitly chose PBKDF2, 
you would still need to call that function to allow for increases in the 
cost parameter.)


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] Add support $object::class

[S.A.N]

> $object is not guaranteed to be an object, it could be anything (int,
> string, etc) or nothing (null).  using ::class for a variable, I'd argue,
> makes for less consistency.  What would the replacement be for non-object
> variables?  An error, exception, or false, or string type? At least in
> "Bar::class", you'll always get a string representation of what the fully
> qualified class name resolves to.

$scalar::class === gettype($scalar)
$object::class ===  get_class($object)

> That said, the argument could be made that since static::class, self::class,
> and parent::class fall into the same category of potential runtime
> resolutions that $object::class too should be supported.

+1

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

Re: [PHP-DEV] Add support $object::class

[Marco Pivetta]

On 7 May 2015 at 16:04, Ralph Schindler  wrote:

>
>  2. Illogically - Bar::class valid syntax, $object::class invalid syntax.
>>>
>>>  I'll grant you the consistency argument.  I'm all for consistency, but
>> that's the ONLY valid reason you've stated.
>>
>
> Even then I think this part of the argument is fairly weak.  In
> Bar::class, the context of Bar is always a class name (either short due to
> do namespace or use statements, or long fully qualified).
>
> $object is not guaranteed to be an object, it could be anything (int,
> string, etc) or nothing (null).  using ::class for a variable, I'd argue,
> makes for less consistency.  What would the replacement be for non-object
> variables?  An error, exception, or false, or string type? At least in
> "Bar::class", you'll always get a string representation of what the fully
> qualified class name resolves to.
>

Hey Ralph,

Please refer to current behavior:

http://3v4l.org/3sgLa

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] Add support $object::class

[Ralph Schindler]

2. Illogically - Bar::class valid syntax, $object::class invalid syntax.


I'll grant you the consistency argument.  I'm all for consistency, but
that's the ONLY valid reason you've stated.


Even then I think this part of the argument is fairly weak.  In 
Bar::class, the context of Bar is always a class name (either short due 
to do namespace or use statements, or long fully qualified).


$object is not guaranteed to be an object, it could be anything (int, 
string, etc) or nothing (null).  using ::class for a variable, I'd 
argue, makes for less consistency.  What would the replacement be for 
non-object variables?  An error, exception, or false, or string type? 
At least in "Bar::class", you'll always get a string representation of 
what the fully qualified class name resolves to.


That said, the argument could be made that since static::class, 
self::class, and parent::class fall into the same category of potential 
runtime resolutions that $object::class too should be supported.


-ralph

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