Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:100431 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 13320 invoked from network); 7 Sep 2017 05:39:23 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Sep 2017 05:39:23 -0000 Authentication-Results: pb1.pair.com header.from=yohgaki@ohgaki.net; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=yohgaki@ohgaki.net; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender) X-PHP-List-Original-Sender: yohgaki@ohgaki.net X-Host-Fingerprint: 180.42.98.130 ns1.es-i.jp Received: from [180.42.98.130] ([180.42.98.130:58958] helo=es-i.jp) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 9D/AC-10715-88BD0B95 for ; Thu, 07 Sep 2017 01:39:22 -0400 Received: (qmail 24782 invoked by uid 89); 7 Sep 2017 05:39:17 -0000 Received: from unknown (HELO mail-it0-f52.google.com) (yohgaki@ohgaki.net@209.85.214.52) by 0 with ESMTPA; 7 Sep 2017 05:39:17 -0000 Received: by mail-it0-f52.google.com with SMTP id y65so2097344itc.1 for ; Wed, 06 Sep 2017 22:39:16 -0700 (PDT) X-Gm-Message-State: AHPjjUiXjzu0vLI8KaQ9JKou4xjMyq+TsiHsQq/o2vwKmQPOQ0Bqwm8i YR4/J2JY5HAhH45lfGvrOuGxFaFokg== X-Google-Smtp-Source: ADKCNb5EBk1aeW/imMiCiEd+Ca27TBmWbQNBFkVdJz2YaiIzIfQ8Wi/SLBQpppC/lXkjOJQUXGgebXAiT8AOAKPFhZQ= X-Received: by 10.36.77.83 with SMTP id l80mr2663700itb.148.1504762751235; Wed, 06 Sep 2017 22:39:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.72.5 with HTTP; Wed, 6 Sep 2017 22:38:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 7 Sep 2017 14:38:30 +0900 X-Gmail-Original-Message-ID: Message-ID: To: Dan Ackroyd Cc: "internals@lists.php.net" , Nikita Popov Content-Type: multipart/alternative; boundary="001a11445aee4251a4055892e174" Subject: Re: [PHP-DEV] hash_hkdf() signature and return value From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a11445aee4251a4055892e174 Content-Type: text/plain; charset="UTF-8" Hi Dan, I appreciate your feedback, regardless of your opinion towards this issue. On Wed, Sep 6, 2017 at 8:04 PM, Dan Ackroyd wrote: > On 6 September 2017 at 02:15, Yasuo Ohgaki wrote: > > What should we do for this? > > Not us, you. > OK. It is recorded that you think current API is totally valid. I'm not sure who is "us". Please reply and record your opinion. > > You should start listening to other people's feedback. > > You continually refuse to accept any feedback that doesn't agree with > your world-view, not only on the subject of hkdf, but on validation > and other things you think are "MANDATORY" > Well, my thoughts are not totally my inventions. For HKDF, it came from the RFC 5689 basically. For input validations, it is originated in Defensive Programming. Defensive Programming is referred in early 90's AFAIK, it is called secure programming or secure coding now. I believe the basic idea was developed 60's computer scientists who researched program execution correctness verification methods. You should respect RFC votes and stop bringing up the same discussions > over and over again. This is incredibly tedious. > Did you really read the RFC 5689? Please mention what is wrong with my statements if you think my statements are totally wrong. It should be easy to point it out, since I provided many points. This is technical list, not political list nor religious list after all. I should note that no valid code example was presented that justifies current API. Not a single valid code example, yet. This fact infers what you say "us" have concrete reason(s) that supports current API validity. Please provide undisclosed valid code example that would be more common than CSRF token and API token derivations. There are even more URL singing, etc in my PHP RFC. > In particular your suggestion about hash_hkdf was rejected > unanimously, apart from your own vote > https://wiki.php.net/rfc/improve_hash_hkdf_parameter and so probably > shouldn't be brought up for discussion, except if you can bring new > facts for discussion. > If any one of you provided example usages that would be common, valid (and optimal, it should be optimal since HKDF is designed for the best possible derived key with HMAC), I would not raise this issue again. > > "Not liking the result of the vote" is not a new fact to discuss. > Sorry but, I'm not liking the vote result. I'm frustrating the fact there is no code example(s) justifies current API design that is insecure and inconsistent. Additionally though, your ideas about adding validation/filter > functions as a C extension, rather than implementing them in PHP have > also been resoundingly rejected, > https://wiki.php.net/rfc/add_validate_functions_to_filter and yet you > continue to promote the idea. This is also tedious. > It's totally new module. I already replied to your comments in other thread. Apparently, you are ignoring single responsibility principle. Please take into the principle into your thoughts. This pattern of behaviour, continually refusing to accept that other > people have opinions that don't align with yours, and continually > bringing up the same topics for discussion over, and over, and over > again is not productive. It does not make people want to engage you in > discussion, as it is a waste of their time. This is not something > other people can fix for you. > As I wrote _MANY_ times in past mails. I would have stopped discussion, if there are example codes that justify the API. Sorry for repeating requests, but this is technical list and no evidence is provided. If you really think my statements are wrong. Please comment each line by replying "wrong" so that your idea becomes more clear. I shouldn't difficult. I provided more than handful valid use cases in my PHP RFC. The technical evidence should not be difficult. It's just example(s). I'm waiting. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --001a11445aee4251a4055892e174--