Could we regard random_bytes() as a security patch rather than a new
feature and therefore port it to PHP 5?
Error handling would have to change but that should be feasible. Iirc,
earlier commits of random_bytes() had PHP 5-like behavior on error.
My motivation: it's easier to defend abandoning OpenSSL's RNG (e.g. in
paragonie/random_compat) if we could say to Windows users stuck with
nothing else: "Upgrade to the latest point release of PHP 5.x. It has a
proper fix."
Tom
Could we regard
random_bytes()as a security patch rather than a new
feature and therefore port it to PHP 5?Error handling would have to change but that should be feasible. Iirc,
earlier commits ofrandom_bytes()had PHP 5-like behavior on error.My motivation: it's easier to defend abandoning OpenSSL's RNG (e.g. in
paragonie/random_compat) if we could say to Windows users stuck with
nothing else: "Upgrade to the latest point release of PHP 5.x. It has a
proper fix."Tom
Since there's no 5.7 release planned, you're talking about adding it in
a 5.6.x? What's wrong with the random_compat library as a solution for
5.6 users?
--Larry Garfield
Could we regard
random_bytes()as a security patch rather than a new
feature and therefore port it to PHP 5?Error handling would have to change but that should be feasible. Iirc,
earlier commits ofrandom_bytes()had PHP 5-like behavior on error.My motivation: it's easier to defend abandoning OpenSSL's RNG (e.g. in
paragonie/random_compat) if we could say to Windows users stuck with
nothing else: "Upgrade to the latest point release of PHP 5.x. It has a
proper fix."Tom
Since there's no 5.7 release planned, you're talking about adding it in
a 5.6.x?
Yes, maybe even 5.5?
What's wrong with the random_compat library as a solution for
5.6 users?
Good question. Vexing answer. I try to be brief.
There are real situations that push random_compat into a corner with
only unpleasant options, namely recommending the user install the
unsavory mcrypt ext, which provides mcrypt_create_iv(), or resort to
OpenSSL's RNG, which is just scary.
There are recent discussion of this in a few places, I think you can
find them all starting here
https://github.com/paragonie/random_compat/issues/5
So I thought another option would be to say "patch your PHP". One
possibility to do that is what I proposed above.
[I hesitate to mention it but, another is to make mcrypt_create_iv()
independent of libmcrypt and present in standard builds of PHP. Maybe
the latter is better because existing scripts that test
function_exists('mcrypt_create_iv') become more secure.]
Tom
Tom,
Could we regard
random_bytes()as a security patch rather than a new
feature and therefore port it to PHP 5?Error handling would have to change but that should be feasible. Iirc,
earlier commits ofrandom_bytes()had PHP 5-like behavior on error.My motivation: it's easier to defend abandoning OpenSSL's RNG (e.g. in
paragonie/random_compat) if we could say to Windows users stuck with
nothing else: "Upgrade to the latest point release of PHP 5.x. It has a
proper fix."Tom
Since there's no 5.7 release planned, you're talking about adding it in
a 5.6.x?Yes, maybe even 5.5?
What's wrong with the random_compat library as a solution for
5.6 users?Good question. Vexing answer. I try to be brief.
There are real situations that push random_compat into a corner with only
unpleasant options, namely recommending the user install the unsavory mcrypt
ext, which provides mcrypt_create_iv(), or resort to OpenSSL's RNG, which is
just scary.There are recent discussion of this in a few places, I think you can find
them all starting here https://github.com/paragonie/random_compat/issues/5So I thought another option would be to say "patch your PHP". One
possibility to do that is what I proposed above.[I hesitate to mention it but, another is to make mcrypt_create_iv()
independent of libmcrypt and present in standard builds of PHP. Maybe the
latter is better because existing scripts that test
function_exists('mcrypt_create_iv') become more secure.]
Overall, I don't think this should be ported back to 5.x
First off, it's pretty late in both 5.5 and 5.6 lifetimes (5.6 is
already up to .14).
Introducing a feature this late would basically make it useless to the
vast majority of users of those versions (since many don't upgrade, or
use distro-pinned versions). I don't like it, but that's the truth.
random_compat serves this need quite nicely, but as always there are
non-trivial tradeoffs at play.
As far as making mcrypt_create_iv more standard, why? That's what
random_bytes() was meant to do (and does). Just encourage people to
move forward with it and upgrade to 7...
Anthony
Overall, I don't think this should be ported back to 5.x
First off, it's pretty late in both 5.5 and 5.6 lifetimes (5.6 is
already up to .14).Introducing a feature this late would basically make it useless to the
vast majority of users of those versions (since many don't upgrade, or
use distro-pinned versions). I don't like it, but that's the truth.random_compat serves this need quite nicely, but as always there are
non-trivial tradeoffs at play.As far as making mcrypt_create_iv more standard, why?
To reduce the motive to use OpenSSL (reduce objections to avoiding it) in
general and in random_compat in particular.
That's what
random_bytes() was meant to do (and does). Just encourage people to
move forward with it and upgrade to 7...
That's actually the stance I prefer. But I wanted to explore these options
among those who know more about updating PHP itself than me. I guess
you're right that adding this at the end of 5.5 and 5.6 won't accomplish
much.
The stance I prefer is that random_compat itself can educate users.
Imagine the user that tries it out and sees the exception 'There is no
suitable CSPRNG installed on your system'. That's a teachable moment.
If this user object's "But I've got OpenSSL" then random_compat's docs can
explain why it's not considered safe and what the user can do.
Tom
Overall, I don't think this should be ported back to 5.x
+1
Overall, I don't think this should be ported back to 5.x
+1
Same here.
There are working solutions already for 5.4+, for example openssl rng
functions and compat.
Cheers,
Pierre
Tom Worster wrote on 13/10/2015 01:29:
Could we regard
random_bytes()as a security patch rather than a new
feature and therefore port it to PHP 5?
Whether or not it's good for security, it's still a feature - you still
have to code your application to depend on this feature being present,
or provide some kind of polyfill.
Adding functions in patch versions is very messy, IMHO, because in
practice people will be using packaged binaries. Distros like
Debian/Ubuntu actually roll their own patch releases rather than using
the official release versions; other distros might simply lag behind;
applications need to support multiple environments which aren't equally
up to date, etc.
There may need to be a concerted campaign of "don't be scared to upgrade
to PHP 7", but ultimately having people want the features in it is a
Good Thing, and the more you backport, the more you fragment the ecosystem.
Regards,
Rowan Collins
[IMSoP]