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
>> 720586cb0a2f410720e26719d97f3
>>
Hi fsb,
On Tue, Jan 17, 2017 at 3:47 AM, fsb wrote:
>
> - when salt is ''(empty string), use default static known random salt
>> value.
>>Note: hkdf's salt could be known, yet provide stronger result as RFC
>> states.
>>
>
> This change renders the implementation nonstandard. And it's useles
Hi Nikita,
On Mon, Jan 16, 2017 at 8:08 PM, Nikita Popov wrote:
> Making the salt required makes no sense to me.
>
It does not make sense to me too if API requires a "salt value" always.
"salt" should be able to be omitted.
My proposal is to "make salt parameter required" and "let programmers
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 instead of (or in addition to) mt
Hi!
> Discussion is open for following rfc https://wiki.php.net/rfc/immutability
The RFC says:
> Safe for concurrency.
I'm not sure - what concurrency are you talking about?
> Value objects, DTO's etc. can be easily created.
Value objects can be easily created right now if you follow generic
Hi!
> - Allow array additional_parameter and soft deprecate (document
> deprecation) string one.
> - Use key as "option name" and validate chars
> - Use value as "option value" and validate some control chars then apply
> escapeshellarg()
Making array sounds good, but I'm not sure what is mean
Hi!
> A lot of the time a feature request is just not enough; it requires at
> least a good discussion, if not an RFC.
True, but some people can not write an RFC, or not ready to do it,
however they still can request and discuss features.
> That there were feature requests open on bugsnet for mo
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 instead of (or in addition to) mt_rand.
On 2017-01-16 09:16, Yasuo Ohgaki wrote:
Comments are appreciated.
Hi,
> Even if you leave the interface as is and just pass the parameter
> additionally, it could have been extended by users just like in your example
> and pass a
> wrong value then.
Yes, it might. I don't come up an idea why, but maybe someone has had a reason,
as the json_encode calling won
>
> >> What BC break are you talking about? There is no need for using the
> parameter in old codes. Even if we pass that depth to jsonSerialize
> >> doing something like: "public function jsonSerialize() {...}" will
> still work without any problems.
> > That BC break: https://3v4l.org/L1u7q
>
> A
Results for project PHP master, build date 2017-01-15 20:29:01-08:00
commit: 4eb4057
previous commit:c4e0ba0
revision date: 2017-01-15 18:42:48-08:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
Hi.
>> What BC break are you talking about? There is no need for using the
>> parameter in old codes. Even if we pass that depth to jsonSerialize
>> doing something like: "public function jsonSerialize() {...}" will still
>> work without any problems.
> That BC break: https://3v4l.org/L1u7q
And
On Mon, Jan 16, 2017 at 8:19 AM, Jani Ollikainen
wrote:
> Hi,
>
> > I don't really like this. The reason is that you don't actually modify
> JsonSerializable interface for the obvious BC break that it would cause it.
> It means that the > function just gets this parameter and it kind of raises
>
On Wed, Jan 11, 2017 at 2:24 PM, Andrey Andreev wrote:
> Hi all,
>
> There's a pending GitHub pull request of mine to include a HKDF
> implementation into ext/hash.
> Mostly anybody who saw it agreed that it probably doesn't require an RFC
> vote, but I hadn't originally announced it here on the
Hi,
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
> 720586cb0a2f410720e26719d97f3
>
> I have 2 improvement ideas.
>
>
>
> 1) Make salt parameter required.
>
>
On Mon, Jan 16, 2017 at 2:47 AM, Yasuo Ohgaki wrote:
> Hi all,
>
> On Wed, Jan 11, 2017 at 11:24 PM, Andrey Andreev wrote:
>
> > Hi all,
> >
> > There's a pending GitHub pull request of mine to include a HKDF
> > implementation into ext/hash.
> > Mostly anybody who saw it agreed that it probably
2017-01-16 9:19 GMT+01:00 Jani Ollikainen :
> Hi,
>
> > I don't really like this. The reason is that you don't actually modify
> JsonSerializable interface for the obvious BC break that it would cause it.
> It means that the > function just gets this parameter and it kind of raises
> a question ho
Hi Michał,
On Mon, Jan 16, 2017 at 10:30 AM, Michał Brzuchalski wrote:
> As I am familiar with those interceptions, I tend to point out some dirty
> hacks
> when reflection tells you property exists while getting notice on set, see
> https://3v4l.org/VDMHm
>
>
> class Foo
> {
> public $bar
As I am familiar with those interceptions, I tend to point out some dirty
hacks
when reflection tells you property exists while getting notice on set, see
https://3v4l.org/VDMHm
bar);
}
}
$foo = new FooHack(new Foo);
$reflectionFooBar = new \ReflectionProperty(Foo::class, 'bar');
var_dump((n
On Mon, Jan 16, 2017 at 9:49 AM, Michał Brzuchalski
wrote:
> Hi Marco,
>
> 2017-01-16 0:27 GMT+01:00 Marco Pivetta :
>
>> Hi Wes,
>>
>> This has been discussed before, and it's currently used to intercept
>> access
>> to properties. Since we don't have property accessors (sigh), the code
>> (simp
2017-01-16 9:49 GMT+01:00 Michał Brzuchalski :
> Hi Marco,
>
> 2017-01-16 0:27 GMT+01:00 Marco Pivetta :
>
>> Hi Wes,
>>
>> This has been discussed before, and it's currently used to intercept
>> access
>> to properties. Since we don't have property accessors (sigh), the code
>> (simplified versio
Hi Marco,
2017-01-16 0:27 GMT+01:00 Marco Pivetta :
> Hi Wes,
>
> This has been discussed before, and it's currently used to intercept access
> to properties. Since we don't have property accessors (sigh), the code
> (simplified version) would look like following:
>
> class Foo
> {
> public $
Hi,
> This looks like a hack covering for deficient design. Having objects that
> look differently depending on hidden parameters without anybody explicitly
> modifying them is a recipe for very hard to track bugs. I don't think we
> should encourage this.
>
> There are ways to present serialize
Hi,
> I don't really like this. The reason is that you don't actually modify
> JsonSerializable interface for the obvious BC break that it would cause it.
> It means that the > function just gets this parameter and it kind of raises a
> question how we should document it? The solution would be
24 matches
Mail list logo
