Hi Nikita,
OK I understand you are with Andrey.
On Sun, Feb 5, 2017 at 7:21 AM, Nikita Popov wrote:
> Suggesting to drop the length parameter from HKDF... Okay, that's where I
> draw the line. I've had enough of this farce. I've configured gmail to
> blackhole your mails and recommend anyone wh
On Sat, Feb 4, 2017 at 10:37 PM, Yasuo Ohgaki wrote:
> 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 anythin
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?
>>>
>>> The reason why its authors have to recomm
> And then there's the extra typing and visual space taken up, which is not
> something to dismiss entirely. Also, as someone else mentioned this syntax
> *seems* like it would support nesting. Compare the following:
>
> $x = function($a) => function($b) => function($c) => $a * $b * $c;
> $y = fn(
Hi again,
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?
>>
>> The reason why its authors have to recommend salt usage is because it is
>> *otherwise the only optional par
2017-02-04 21:49 GMT+01:00 Larry Garfield :
> On 02/03/2017 11:53 AM, Levi Morrison wrote:
>
>>
>> Thanks to everyone who has participated in the discussion thus far.
>>> Primarily the feedback has been directed at the `fn` keyword. Let me
>>> provide two benefits and drawbacks of using `fn` as a
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 management server and com
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 you ignoring everybody else's arguments, but also be
On 02/03/2017 11:53 AM, Levi Morrison wrote:
Thanks to everyone who has participated in the discussion thus far.
Primarily the feedback has been directed at the `fn` keyword. Let me
provide two benefits and drawbacks of using `fn` as a keyword:
1. `fn` is searchable in search engines and in
Hi Andrey,
On Sun, Feb 5, 2017 at 3:21 AM, Andrey Andreev wrote:
> Have *you* read anything else in the RFC?
>
> The reason why its authors have to recommend salt usage is because it is
> *otherwise the only optional part of the algorithm*.
>
Nonsense. You misread the RFC and my mail.
Who store
Hi,
On Sat, Feb 4, 2017 at 7:49 PM, Yasuo Ohgaki wrote:
>
> On Sun, Feb 5, 2017 at 1:20 AM, Tom Worster wrote:
>
>> On 3 Feb 2017, at 18:56, internals-digest-h...@lists.php.net wrote:
>>
>> HKDF w/o salt is OK, but with salt, it's much stronger than w/o it.
>>>
>>
>> That's not correct.
>>
>> T
> I personally don’t see a huge use for this in my own work actually, I’m just
> trying to make sure that something I will likely have to live with from
> *other* developers isn’t impossible to read, that’s all. But I agree that
> most people seem focussed on the actual syntax.
Well, I do. We u
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 uniqid()'s entropy is extremely w
Hi,
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 you ignoring everybody else's arguments, but also behaving
like PHP is your own personal project.
Please stop.
Ch
Hi,
On Sat, Feb 4, 2017 at 1:01 AM, Yasuo Ohgaki wrote:
> Did everyone understand why I propose salt as required parameter and
> specify optional salt explicitly?
>
>
I did, and I disagreed.
> HKDF w/o salt is OK, but with salt, it's much stronger than w/o it.
> In addition, most use case with
On Sun, Feb 5, 2017 at 1:20 AM, Tom Worster wrote:
> On 3 Feb 2017, at 18:56, internals-digest-h...@lists.php.net wrote:
>
> HKDF w/o salt is OK, but with salt, it's much stronger than w/o it.
>>
>
> That's not correct.
>
> The salt defends against certain attacks on predictable input key
> mater
Hi Ilija,
> On 4 Feb 2017, at 23:19, ilija.tov...@me.com wrote:
>
> Hey Stephen
>
>> You’re really starting to lose me now. You want types but don’t want to
>> define them, and you’re somehow mixing phpdoc into this.
>
> Because we use PHPDoc to provide type hints to the IDE where PHP doesn
On Sat, Feb 4, 2017 at 11:16 AM, Nikita Popov wrote:
> On Fri, Feb 3, 2017 at 9:44 PM, Scott Arciszewski
> wrote:
>>
>> I've opened the vote for the libsodium RFC.
>>
>> https://wiki.php.net/rfc/libsodium
>>
>> See https://externals.io/thread/626 for the previous discussion topics.
>>
>> The vote
Hey Stephen
> You’re really starting to lose me now. You want types but don’t want to
> define them, and you’re somehow mixing phpdoc into this.
Because we use PHPDoc to provide type hints to the IDE where PHP doesn’t
support them yet (variables and properties).
> Currently PHP has zero suppor
On 3 Feb 2017, at 18:56, internals-digest-h...@lists.php.net wrote:
HKDF w/o salt is OK, but with salt, it's much stronger than w/o it.
That's not correct.
The salt defends against certain attacks on predictable input key
material, i.e. weak passwords. But HKDF should not normally be used fo
On Fri, Feb 3, 2017 at 9:44 PM, Scott Arciszewski
wrote:
> I've opened the vote for the libsodium RFC.
>
> https://wiki.php.net/rfc/libsodium
>
> See https://externals.io/thread/626 for the previous discussion topics.
>
> The vote closes at 21:00 UTC (4 PM Eastern Time) next Friday.
>
I just too
Hi Scott,
(Sorry for re-send)
> On 4 Feb 2017, at 22:20, Scott Arciszewski wrote:
>
> On Sat, Feb 4, 2017 at 5:37 AM, Fleshgrinder wrote:
>>
>> On 2/4/2017 12:54 AM, Scott Arciszewski wrote:
>>> I like \Sodium\foo instead of sodium_foo, but it deviates from the norm.
>>> If we're going to bre
Hi Ilija,
For some reason I don’t see your original reply yet. Anyway…
> On 4 Feb 2017, at 22:48, ilija.tov...@me.com wrote:
>
> Ah, my example was of course wrong again -.-
>
> The caller should’ve looked like this (although I think you get the point):
>
> ```Swift
> fetchUsers { users in
>
On 2/4/2017 4:20 PM, Scott Arciszewski wrote:
> Hi,
>
> This is a separate choice that people can vote for. It's not exactly
> hidden; nor is it bundled into a single "Yes/No".
>
> The vote option concerns "permit an exception to the coding style" not
> "change the coding style for everything". I
Ah, my example was of course wrong again -.-
The caller should’ve looked like this (although I think you get the point):
```Swift
fetchUsers { users in
// `users` is inferred to be an array of `User`s
}
```
Regards
On 4 Feb 2017, 16:41 +0100, ilija.tov...@me.com, wrote:
> Hey Stephen
>
> >
Hey Stephen
> You don't *have to* specify types at all. If you want to use PHP without
> verifying/requiring types, thats your prerogative, but given the recent
> improvements to allow scalar type hinting, I think it’s a mistake to say that
> *any* use of type hints is “not recommended”.
Sure
On Sat, Feb 4, 2017 at 5:37 AM, Fleshgrinder wrote:
>
> On 2/4/2017 12:54 AM, Scott Arciszewski wrote:
> > I like \Sodium\foo instead of sodium_foo, but it deviates from the norm.
> > If we're going to break the norm, we should do so on a stronger majority
> > than 50%+1.
> >
>
> I see another pro
Hi Ilija
> On 4 Feb 2017, at 17:09, ilija.tov...@me.com wrote:
>
> Hi Stephen
>
>> Using type hints is a part of the language. It even has benefits that I can
>> absolutely see being used here:
>>
>> array_map(function(Foo $x) => $x->bar());
>>
>> If Foo is a class/interface with a method of
On 2/4/2017 12:54 AM, Scott Arciszewski wrote:
> I like \Sodium\foo instead of sodium_foo, but it deviates from the norm.
> If we're going to break the norm, we should do so on a stronger majority
> than 50%+1.
>
I see another problem besides the issue that a namespaced core elements
are being
Hi Stephen
> Using type hints is a part of the language. It even has benefits that I can
> absolutely see being used here:
>
> array_map(function(Foo $x) => $x->bar());
>
> If Foo is a class/interface with a method of bar, your IDE can know that it's
> a valid method to call.
>
> That of course
>
> Would it not be possible for _both_ to be supported? It would be just an
> alias
>
What's the benefit? I can just see bloat and confusion.
31 matches
Mail list logo
