Hi all,
On Sun, Mar 26, 2017 at 7:29 AM, Yasuo Ohgaki wrote:
> I suggest you to disclose the reason why against this change.
> Otherwise, you may be considered you don't understand crypto basic.
> i.e. HKDF(IKM) security depends on PRK being secure. To make PRK
> secure or m
e the reason why against this change.
Otherwise, you may be considered you don't understand crypto basic.
i.e. HKDF(IKM) security depends on PRK being secure. To make PRK
secure or more secure, "salt" parameter is required. "length" is irrelevant
for security.
Thank you for
ps? I
didn't see any practical examples in discussion so far.
Since hash_hkdf() only exists in PHP 7.1.2/7.1.3, if we are going to fix
"insecure" and "inconsistent" signature, now is the only chance.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
hkdf() is
> new function does not affect any.", but hash_hkdf has been released with
> PHP 7.1.2 and therefore is no longer a new (unreleased) function.
>
> The BC break and those misleading / wrong paragraphs are enough to vote
> against.
>
Thank you.
I missed to update RFC and fixed them now.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
other
new inconsistent and insecure function. It would be better to be
fixed ASAP, IMHO.
Vote start: 2017-03-25
Vote end: 2017-04-06 UTC 23:59:59
Thank you for voting.
<https://wiki.php.net/rfc/improve_hash_hkdf_parameter>
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Sat, Mar 25, 2017 at 6:04 AM, Yasuo Ohgaki wrote:
>
> This would be final RFC.
>
> https://wiki.php.net/rfc/improve_hash_hkdf_parameter
>
> Simpler is better.
> I made introduction simpler.
> If there aren't comments, I'll start vote in a few days.
>
I n
signature.
--
Yasuo Ohgaki
yohg...@ohgaki.net
o vote. See
https://wiki.php.net/rfc/voting#rfc_proposer
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Michael,
On Sun, Mar 12, 2017 at 7:33 PM, Yasuo Ohgaki wrote:
> IMO, C# like getter/setter is better though.
>
> http://stackoverflow.com/questions/11159438/looking-
> for-a-short-simple-example-of-getters-setters-in-c-sharp
>
I pasted wrong URL. This URL has better examp
something like __requrie()
is better name for the method.
IMO, C# like getter/setter is better though.
http://stackoverflow.com/questions/11159438/looking-for-a-short-simple-example-of-getters-setters-in-c-sharp
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
dn't have
issues. If you have, please report issue to bugs.php.net in detail.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
e mistaken)
If you find any wrong or unclear statement, please let me know. I'll fix
them
gladly. I appreciate any improvement suggestions. If you would like send
mail privately, I don't mind at all.
Thank you for reading long RFC.
TL;DR;
https://wiki.php.net/rfc/improve_hash_hkdf_p
ple hash_hmac() extension, why should not hash_hkdf() have
compatible signature with hash_hmac()? Aside from it, $salt is "key" in
many cases.
There is no reason "key" to be the last optional parameter.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
7;s really good about HKDF is it can add additional non secret optional
context(domain) safely, as you mentioned.
// Make CSRF token only valid to 'Admin' features.
$csrf_token = bin2hex(hash_hkdf('sha256', $_SESSION['CSRF_TOKEN_SEED'], 0,
'Admin', $expire));
// Should be OK, but this is risky compare to above.
$csrf_token = hash_hmac('sha256', $_SESSION['CSRF_TOKEN_SEED'], $expire.
'-Admin'));
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
ey as combined key.
Does 'length' and/or 'info' achieve or designed for aboves? I don't think
so.
BTW, I don't think of typical PHP application that requires
human typable short password with HKDF. What kind of
application would be?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
ion, though.
Most use cases would be AWS S3 pre-signed URL like
usage that users do not have to care long keys. With such
use cases, users are better to use key as is. i.e. Use default
hash output length.
There may be vote option for length, but I'm in favor of leave
it as optional. I do care about parameter order, but what to be
required is not too much concern to me.
Regards,
BTW, I don't think of typical PHP application that requires
human typable short password with HKDF. What kind of
application would be? Thank you.
--
Yasuo Ohgaki
yohg...@ohgaki.net
tance of the parameter
- likelihood to be used
Salt is the most important for both input and output key security.
Salt is mandatory and/or can be used for almost always with PHP.
Salt usage results in better design/security.
Salt is often used as final key as combined key.
Does 'length' and/or 'info' achieve or designed for aboves? I don't think
so.
hash_hkdf() is generic API. $ikm cannot be strong key always.
Assuming $ikm to be strong is simply wrong assumption.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Forgot to mention the most important.
On Wed, Feb 8, 2017 at 6:16 PM, Yasuo Ohgaki wrote:
> Is that enough of a downside to dismiss an argument for better security?
> Maybe
I suppose so.
It is very clear that "salt" is the most important for derived key security,
"info&q
d
be set
to "0" in many cases if not most. i.e. Just deriving new key from strong
$ikm would
not be typical.
Requiring "$salt = NULL" to omit salt would not hurt API use much compare
to
current signature that requires "$length = 0" for most cases, I suppose.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
t
holes already. I just don't want to see news, "Passwords are stolen from
PHP
app!". hash_hkdf() is could be misused easily like
hash_hkdf('sha256', $weak_ikm, 9); // We can generate strong key easily,
Nice!
hash_hkdf('sha256', $weak_ikm, 9, 'Super User Only'); // Safe key for super
user
hash_hkdf('sha256', $strong_ikm, 4); // Secure and nice password for super
secret
These are security disaster. If salt is required, users would always think
about it
at least. Length should not be shortened unless user is absolutely sure.
If there are unclear sentences, please let me know.
Thank you for reading long mail!
Regards,
P.S. I'll be more careful, but I become very sloppy mail reader sometimes.
I appreciate if you could let know via private email. Thank you!
--
Yasuo Ohgaki
yohg...@ohgaki.net
is very important for average PHP to develop PHP apps more secure way.
IMHO.
Otherwise, I don't insist this much.
Other discussions that I insisted before have good reasons to do, yet I
didn't get any
logical nor reasonable explanation. Please show me good one for this at
least.
Why you insist and recommend vulnerable usage so much?
Thanks,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Andrey,
On Sun, Feb 5, 2017 at 6:19 AM, Andrey Andreev wrote:
> On Sat, Feb 4, 2017 at 10:27 PM, Yasuo Ohgaki wrote:
>
>> Hi Andrey,
>>
>> On Sun, Feb 5, 2017 at 3:21 AM, Andrey Andreev wrote:
>>
>>> Have *you* read anything else in the RFC?
>
On Sun, Feb 5, 2017 at 5:27 AM, Yasuo Ohgaki wrote:
> 2) Use 1) as ikm and "salt" to generate key (NOTE: One of the best place
> for salt storage is $_ENV)
BTW, better place to keep these secret values is to set key management
server
and get key from it. Secure the key manag
On Sun, Feb 5, 2017 at 2:56 AM, Andrey Andreev wrote:
> On Sat, Feb 4, 2017 at 8:29 AM, Yasuo Ohgaki wrote:
>
>>
>>
>> I will change my mind if there is convincing logical
>> reason(s) not to do this. I suppose there isn't.
>>
>
> Not only are yo
F usages with PHP can set
salt.
What's the reason why you insist and recommend vulnerable usage?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Sun, Feb 5, 2017 at 2:49 AM, Yasuo Ohgaki wrote:
> There is something like a weird pattern to your attempts to help PHP
>> programmers use the wrong function for the job -- HKDF for passwords,
>> uniqid and mt_rand for unpredictable randoms.
>>
>
> Do you know uniq
e the wrong function for the job -- HKDF for passwords,
> uniqid and mt_rand for unpredictable randoms.
>
Do you know uniqid()'s entropy is extremely weak?
Do you know current mt_rand()'s extropy is extremely weak?
Are you saying current implementation is the best way that it should be?
If you think so, please explain why these aren't weak and implementation is
optimal.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Sat, Feb 4, 2017 at 4:14 PM, Yasuo Ohgaki wrote:
>
>> fn(params) => expr
>> |params| => expr
>>
>> I look forward to more discussion!
>>
>
> It's unfortunate we cannot have HHVM/Hack syntax now
> https://docs.hhvm.com/hack/l
;s better to be compatible with other implementations if it is possible.
PHP may have HHVM/Hack syntax support in the future.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Sat, Feb 4, 2017 at 2:48 PM, Yasuo Ohgaki wrote:
> string hash_hkdf(string algo, string ikm [, int length = 0, string info =
> '', string salt = ''])
I copied and pasted this proto from the source.
It's wrong. Correct one is
string hash_hkdf(string alg
On Sat, Feb 4, 2017 at 2:37 PM, Yasuo Ohgaki wrote:
> On Sat, Feb 4, 2017 at 8:56 AM, Nikita Popov wrote:
>
>> You are free to prepare a patch, but your patch will not get merged.
>>
>> Your blatant disregard of any and all feedback you receive on your
>> propo
Moreover, it recommends salt
whenever
it is possible by emphasizing improved security by salt. Or am I
misunderstood the RFC?
There isn't any valid reason to have "salt" parameter as the last optional
parameter so far.
Why it should be the last optional parameter?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Sat, Feb 4, 2017 at 10:22 AM, Alex Bowers wrote:
> Would it not be possible for _both_ to be supported? It would be just an
> alias
I would vote for this!!
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
C (4 PM Eastern Time) next Friday.
>
I voted for "No, sodium_foo" syntax in order to be consistent with existing
procedural APIs.
2/3 majority wouldn't fit nicely. What it would be if vote result is 51%
vs 49%?
More than half is good enough for 2nd vote choice. IMO.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi all,
On Tue, Jan 17, 2017 at 4:01 PM, Yasuo Ohgaki wrote:
> On Mon, Jan 16, 2017 at 8:16 PM, Andrey Andreev wrote:
>
>>
>> On Mon, Jan 16, 2017 at 3:47 AM, Yasuo Ohgaki wrote:
>>
>>> Nice function, I like it.
>>> Modified patch is committed to mast
Hi all,
On Thu, Feb 2, 2017 at 12:47 PM, Yasuo Ohgaki wrote:
>
> Posting RFC draft before discussion
>
> https://wiki.php.net/rfc/improve_predictable_prng_random
>
> This RFC includes results of recent PRNG related discussions.
> I would like to keep it simple, but basic o
Hi Niklas,
On Thu, Feb 2, 2017 at 11:05 PM, Niklas Keller wrote:
> 2017-02-02 14:24 GMT+01:00 Christoph M. Becker :
>
>> On 02.02.2017 at 12:51, Yasuo Ohgaki wrote:
>>
>> > Although users must never do this, but there are codes that generate
>> random
&g
Hi Tom,
On Fri, Feb 3, 2017 at 2:53 AM, Tom Worster wrote:
>
> On 1 Feb 2017, at 22:47, Yasuo Ohgaki wrote:
>
> Posting RFC draft before discussion
>
> https://wiki.php.net/rfc/improve_predictable_prng_random
>
> This RFC includes results of recent PRNG related discus
On Thu, Feb 2, 2017 at 10:24 PM, Christoph M. Becker
wrote:
> On 02.02.2017 at 12:51, Yasuo Ohgaki wrote:
>
> > Although users must never do this, but there are codes that generate
> random
> > password/access key by mt_rand().
>
> There is also code that stores clear
7;m surprised and I'll change my
opinion.
How many mt_rand()/rand() calls are executed during PHP process
lifetime? With 32 bits seed, users will never use even 0.0001%
of MT rand potential. It's too much waste of the algorithm, isn't it?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi all,
On Mon, Jan 30, 2017 at 7:54 PM, Yasuo Ohgaki wrote:
> On Mon, Jan 30, 2017 at 7:47 PM, Yasuo Ohgaki wrote:
>
>> On Mon, Jan 30, 2017 at 7:41 PM, Lauri Kenttä
>> wrote:
>>
>>> On 2017-01-30 04:25, Yasuo Ohgaki wrote:
>>>
>
Hi all,
On Wed, Feb 1, 2017 at 5:48 AM, Andrea Faulds wrote:
> Yasuo Ohgaki wrote:
>
>> My current objective is to make existing API to work, so resource may be
>> used
>> to set/get PRNG state.
>>
>
> I would prefer it if we not introduce a new usage of
Hi Levi,
On Tue, Jan 31, 2017 at 8:38 PM, Yasuo Ohgaki wrote:
> On Tue, Jan 31, 2017 at 2:55 AM, Levi Morrison wrote:
>
>> This RFC proposes syntax and semantics to simplify this common usage to:
>>
>> fn($x) => $arr[$x]
>>
>
> Could you explain why
On Tue, Jan 31, 2017 at 9:06 PM, Nicolas Grekas <
nicolas.grekas+...@gmail.com> wrote:
> Or just drop any "fn" or "function" keyword, eg
>
> ($x, $y) => foo($x, $y);
>
> array_map(($x) => $x + 1);
>
> ?
>
I like your syntax if it cannot be like ES2015 syntax.
--
Yasuo Ohgaki
yohg...@ohgaki.net
annot be removed.
fn($x => $x * 2)
Or since many of us like "function", it could be
function($x => $x * 2)
I don't have strong preference, but some may have.
I suggest separate vote into 2 votes.
- Introduce arrow function
- Prefered syntax
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
s requires code modifications, but it isn't too bad.
Problem is this change would be master only and
other functions, e.g. shuffle(), have optional state resource
parameter or not.
Thoughts? Comments?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
to write one
but not now... I would like to make current API work better first.
If anyone could write OO based predictable PRNG, I appreciate a lot!
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
tion for released
versions at least.
Any better ideas are appreciated.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Mon, Jan 30, 2017 at 7:47 PM, Yasuo Ohgaki wrote:
> On Mon, Jan 30, 2017 at 7:41 PM, Lauri Kenttä
> wrote:
>
>> On 2017-01-30 04:25, Yasuo Ohgaki wrote:
>>
>>> I'll prepare patch that allows int array
>>> initialization for mt_srand() so that whole
Hi Lauri,
On Mon, Jan 30, 2017 at 7:41 PM, Lauri Kenttä
wrote:
> On 2017-01-30 04:25, Yasuo Ohgaki wrote:
>
>> I'll prepare patch that allows int array
>> initialization for mt_srand() so that whole state buffer can be
>> initialized as user specifies.
>>
Hi all,
On Mon, Jan 30, 2017 at 11:25 AM, Yasuo Ohgaki wrote:
> Our part could be fixed by us. Let's fix it now.
>
> Lauri made patch for unseeded mt_rand(). I'll prepare patch that allows
> int array
> initialization for mt_srand() so that whole state buffer can
om twitter) seems to want this
> (https://twitter.com/sammyk/status/824298464456691712) so here we go!
> :)
>
I would have voted yes, but I missed the vote.
Unless there is critical reason not to implement it that I don't know of, I
prefer to allow
trailing commas like array universally/consistently.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi all,
On Mon, Jan 30, 2017 at 10:08 AM, Yasuo Ohgaki wrote:
> Issues are
>> - Current mt_rand() is not fully exploited. It wastes more than 99% of its
>> random cycle.
>>
>> This was discussed in Aug last year and dropped.
>>
> I didn't notice the dis
Hi Tom,
On Mon, Jan 30, 2017 at 1:22 AM, Tom Worster wrote:
> On 1/28/17 4:32 PM, Yasuo Ohgaki wrote:
>
> Could you give some examples?
>
> I'm not sure what kind of IoT devices/OS that support PHP do not have
> CSPRNG.
>
> I'm sorry, my reply ended up with su
Hi Tom,
On Sun, Jan 22, 2017 at 1:26 AM, Tom Worster wrote:
> On 1/20/17 9:55 PM, Yasuo Ohgaki wrote:
>
>> CSPRNG failure is like BUS error, i.e. hardware error. CSPRNG shouldn't
>> fail with healthy hardware/OS.
>>
>
> One would like to think so but low entr
Hi all,
On Wed, Jan 18, 2017 at 3:04 PM, Yasuo Ohgaki wrote:
> The patch initializes the full MT state vector, approximately 2.5KB of
>> memory, from a CSPRNG. To put this into perspective, 16 bytes are generally
>> considered to be sufficient for cryptographic keying mate
Hi Tom,
On Sun, Jan 22, 2017 at 1:26 AM, Tom Worster wrote:
> On 1/20/17 9:55 PM, Yasuo Ohgaki wrote:
>
>> CSPRNG failure is like BUS error, i.e. hardware error. CSPRNG shouldn't
>> fail with healthy hardware/OS.
>>
>
> One would like to think so but low entr
usage
also.
i.e. PHP app runs short periods of time and only use beginning of MT rand
cycle.
More than 99% random cycle is wasted currently.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi,
On Sat, Jan 21, 2017 at 11:12 AM, Yasuo Ohgaki wrote:
> On Thu, Jan 19, 2017 at 10:37 PM, Lauri Kenttä
> wrote:
>
>> On 2017-01-19 13:46, Yasuo Ohgaki wrote:
>>
>>> However, PHP as a whole cannot work reliable way w/o CSPRNG and
>>> today's
>
BC is extremely unlikely. Basically, no BC on healthy hardware/OS.
2) Then things failed, programs should fail properly. i.e. Shouldn't
fallback to weaker/problematic code.
Broken CSPRNG is like BUS error, i.e. hardware error, why should we care so
much about it?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Lauri and Leigh,
On Thu, Jan 19, 2017 at 10:37 PM, Lauri Kenttä
wrote:
> On 2017-01-19 13:46, Yasuo Ohgaki wrote:
>
>> However, PHP as a whole cannot work reliable way w/o CSPRNG and
>> today's
>> standard requires working CSPRNG, doesn't it?
>>
>
implemented
https://wiki.php.net/security [1]
Thanks,
[1] https://wiki.php.net/rfc/security-classification
--
Yasuo Ohgaki
yohg...@ohgaki.net
in fatal way . Compare to these, very rarely raised
security concerned fatal exception is nothing. IMHO.
--
Yasuo Ohgaki
yohg...@ohgaki.net
%B7%E3%83%A5
http://qiita.com/kasei-san/items/3ce2249f0a1c1af1cbd2
They are written in Japanese. Please use google translate or similar.
Wrongly configured keyboard could be another problem. We may ignore such
environment.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Lauri,
On Thu, Jan 19, 2017 at 1:06 AM, Lauri Kenttä
wrote:
> On 2017-01-18 08:04, Yasuo Ohgaki wrote:
>
>> Lauri,
>> You wrote the patch. Could you make Pull Request to github's php-src
>> repo?If you prefer not to, I'll make the PR.
>>
>> I t
On Wed, Jan 18, 2017 at 10:22 AM, Nikita Popov wrote:
> On Wed, Jan 18, 2017 at 1:44 AM, Yasuo Ohgaki wrote:
>
>> Hi Lauri,
>>
>> On Tue, Jan 17, 2017 at 11:59 PM, Lauri Kenttä
>> wrote:
>>
>> > On 2017-01-17 16:18, Lauri Kenttä wrote:
>&
Hi Lauri,
On Tue, Jan 17, 2017 at 11:59 PM, Lauri Kenttä
wrote:
> On 2017-01-17 16:18, Lauri Kenttä wrote:
>
>> On 2017-01-17 02:34, Yasuo Ohgaki wrote:
>>
>>> Set state somewhere between MT rand's 2^19937−1 cycle.
>>>
>>
>> This is exactly
Hi Leigh,
On Tue, Jan 17, 2017 at 11:48 PM, Leigh wrote:
> mt_rand is not advertised as crypto-quality.
>
> Where do you think mt_rand is used in session id generation?
>
I don't mention session module uses mt_rand, but older versions used
php_combined_lcg() .
Regards,
--
;/' (Only under Windows) for
option names
What do you think?
If anyone know more chars should be allowed, please comment.
e.g. XYZ sendmail requires "sendmail -f='sender'" style.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Tue, Jan 17, 2017 at 6:20 PM, Yasuo Ohgaki wrote:
> I'm planning to use extra_parameters array like
>
> $opts = [
> '-f' => 's...@example.com', // Envelope sender
> '-4' => null, // Force IPv4
> '-au' => 'u...
f' => 's...@example.com', // Envelope sender
'-4' => null, // Force IPv4
'-au' => 'u...@example.com', // SMTP auth user
'-ap' => 'secret', // SMTP auth password
'-am' => 'CRAM-MD5', // SMTP auth m
It may be good to start from constant scalars.
ES6 has "let" and "const". PHP has "const", but PHP's constant does not
have scope other than class. It would be nice if const can be used like JS.
e.g. Following is syntax error.
It would be large enough chan
Hi Andrey,
On Mon, Jan 16, 2017 at 8:16 PM, Andrey Andreev wrote:
>
> On Mon, Jan 16, 2017 at 3:47 AM, Yasuo Ohgaki wrote:
>
>> Nice function, I like it.
>> Modified patch is committed to master
>> http://git.php.net/?p=php-src.git;a=commitdiff;h=4bf7ef08061
>&
attacker" are not the same.
This is very important.
I explained why I would like to make "salt parameter required" in reply for
Nikita's post.
IMO, most HKDF usage with PHP can have secret salt to improve security.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
to the digest size.
>
"md2" for HKDF does not make sense, but we may document that stronger hash
provide more security than weaker one.
Let's recommend SHA-3 in document. I prefer to warn weak/obsolete hash
usage to users, but documentation would work also.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Lauri,
On Tue, Jan 17, 2017 at 2:34 AM, Lauri Kenttä
wrote:
> On Mon, Jan 16, 2017 at 4:04 PM, Yasuo Ohgaki wrote:
>
>> We know this kind of seed is guessable. i.e. Our session id is compromised
>> by this kind of code.
>>
>
> Maybe you should fix session id
On Mon, Jan 16, 2017 at 4:04 PM, Yasuo Ohgaki wrote:
> Since I was about to improve uniqid()'s entropy by replacing
> php_combined_lcg() to php_random_int(), I spent time to check other places
> that could be a problem.
>
> mt_rand()'s is seeded as follows by default.
&g
is kind of code.
Although it would be rare that raw mt_rand() value is exposed, but
guessable value is guessable. I'm going to replace the seeding code by
simple php_random_int() call.
Any comments?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi all,
On Mon, Jan 16, 2017 at 10:47 AM, Yasuo Ohgaki wrote:
>
> Comments are appreciated.
> If there is no comment, I'll work on these improvements hopefully soon.
>
Forgot to mention one more thing.
I also would like to make HKDF a PHPAPI.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
telist mitigate it.
(We are better to have .phpt for it to notify problem to new hash
function author)
3. Raise E_RECOVEREABLE _ERROR for blacklisted hashes.
Note: Blacklisted hash usage results in returning FALSE. This may
result in very weak encryption/etc with @ operator, for example.
Comments are appreciated.
If there is no comment, I'll work on these improvements hopefully soon.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
prefix, sec, usec);
}
Notice that int values are less than a billion which is inside of signed 32
bit int range. This version is as fast as php_combined_lcg() version on my
system. Both versions executes a million uniqid() calls about 0.36 sec.
$ php -r '$s = microtime(TRUE);for($i=0;$i<100;$i++) uniqid("", TRUE);
echo microtime(TRUE) - $s;'
0.36102104187012
So above patch would be the final patch. I don't expect issues but if there
is performace issue on some systems, we may consider Lauri's integer
computation version.
I should have been disturbed by something when I wrote the silly patch.
Sorry for confusions.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Mon, Jan 9, 2017 at 7:56 AM, Yasuo Ohgaki wrote:
> it will help in most cases
I meant "arrayed 'addtional_parameters'" will help.
--
Yasuo Ohgaki
yohg...@ohgaki.net
Any comments on this?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi all,
On Sun, Jan 8, 2017 at 6:57 AM, Yasuo Ohgaki wrote:
> All of us knew details of PHPMailer and Swift Mailer issues with mail()'s
> 5th (additional_parameters) parameter by now, I suppose. Current behavior
> (applying php_escape_shell_cmd to addtional_parameters) is not nice
On Mon, Jan 9, 2017 at 5:07 AM, Yasuo Ohgaki wrote:
> On Mon, Jan 9, 2017 at 2:29 AM, Lauri Kenttä
> wrote:
>
>> On 2017-01-07 03:15, Yasuo Ohgaki wrote:
>>
>>> + php_random_int(10, 99, &rand, 1);
>>>
>>> Thi
On Mon, Jan 9, 2017 at 5:31 AM, Yasuo Ohgaki wrote:
> On Mon, Jan 9, 2017 at 3:15 AM, Kazuo Oishi wrote:
>
>> No. Lauri's version is better.
>>
>> Your php_random_bytes_throw() version is significantly slow. Lauri's
>> version is faster and
64s
> user0m0.260s
> sys 0m0.400s
>
Interesting result. AFAIK, I didn't get significant difference when I made
the patch.
What is your system? It seems your PRNG is significantly slow.
BTW, my patch is extension in mind. i.e. Use of non numeric chars
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Mon, Jan 9, 2017 at 2:29 AM, Lauri Kenttä wrote:
> On 2017-01-07 03:15, Yasuo Ohgaki wrote:
>
>> + php_random_int(10, 99, &rand, 1);
>>
>> This should be
>>
>> + php_random_int(0, 99, &rand, 1);
users need SMTP authentication (or any other
options) with sendmail command, mail.force_extra_parameters/sendmail_path
ini setting may be used.
We cannot remove parameter suddenly. We may document deprecation now, raise
warning with 7.2, remove it by 7.3 or 8.0.
Are there comments for removing 5
Hi Niklas,
On Sun, Jan 8, 2017 at 4:08 AM, Niklas Keller wrote:
> 2017-01-07 2:15 GMT+01:00 Yasuo Ohgaki :
>
>> Hi Lauri,
>>
>> On Wed, Jan 4, 2017 at 4:56 AM, Lauri Kenttä
>> wrote:
>>
>> > On 2016-12-31 01:20, Yasuo Ohgaki wro
Hi Kazuo,
On Sat, Jan 7, 2017 at 9:54 AM, Yasuo Ohgaki wrote:
> You misunderstand the mail.
> PHPMailer and uniqid() fix is unrelated, but uniqid() is misused proposed
> patch in obvious way.
>
>
>>
>> What's your intention?
>>
>
> The point we sho
Hi Lauri,
On Wed, Jan 4, 2017 at 4:56 AM, Lauri Kenttä wrote:
> On 2016-12-31 01:20, Yasuo Ohgaki wrote:
>
>> + zend_long rand;
>> + php_random_int(10, 99, &rand, 1);
>> + uniqid = strpprintf(0, "%s%0
t; proposed PHPMailer bug fix patch" is "FUD". Behavior of uniqid without
> $more_entropy=TRUE is not changed.
>
You misunderstand the mail.
PHPMailer and uniqid() fix is unrelated, but uniqid() is misused proposed
patch in obvious way.
>
> What's your intention?
>
The point we should learn from the code is, it is clear that users
misunderstand how uniqid() works. You'll find number of such usages if you
search net.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
= 'b3_' . $this->uniqueid;
Although I never recommend such code, the ID is good enough for this
specific usage. I think we should remove the goccha, "uniqid() is not
unique". This code explains why.
Related RFC:
Improve uniqid() uniqueness
https://wiki.php.net/rfc/uniqid
IMHO, we should enable more_entropy by default, with stronger entropy
prefered.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi all,
On Mon, Dec 5, 2016 at 10:44 AM, Yasuo Ohgaki wrote:
> This RFC exposes session serializer interface to user space. It works
> like user defined session save handler.
>
> Users are able to encrypt/validate session data transparently. e.g.
> You can save encrypted session d
Hi all,
On Mon, Dec 5, 2016 at 10:44 AM, Yasuo Ohgaki wrote:
> This RFC exposes session serializer interface to user space. It works
> like user defined session save handler.
>
> Users are able to encrypt/validate session data transparently. e.g.
> You can save encrypted session d
On Thu, Dec 8, 2016 at 10:34 AM, Yasuo Ohgaki wrote:
> What's the best practice of internal function and method data type
> validation, both parameter and return types?
>
> Although it seems it is possible to retrieve parameter/return types,
> there is no APIs defined in Z
ed session serializer RFC"
don't pass.
https://wiki.php.net/rfc/user_defined_session_serializer
If you would like to avoid this, please support the RFC. Thank you.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Dec 8, 2016 at 10:02 AM, Yasuo Ohgaki wrote:
> Please note that users cannot write clean/efficient user defined
> serializer without this RFC.
It may be better to explain real working code.
Since I added "php_serialize" to recent PHP, user defined
serialization with curr
On Thu, Dec 8, 2016 at 10:34 AM, Yasuo Ohgaki wrote:
>
> What's the best practice of internal function and method data type
> validation, both parameter and return types?
Sorry, question is confusing.
I'm trying to validate data types of callbacks which could be both
user d
101 - 200 of 1795 matches
Mail list logo
