Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:63627 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 12726 invoked from network); 25 Oct 2012 15:24:38 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Oct 2012 15:24:38 -0000 Authentication-Results: pb1.pair.com header.from=kris.craig@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=kris.craig@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender) X-PHP-List-Original-Sender: kris.craig@gmail.com X-Host-Fingerprint: 209.85.215.42 mail-la0-f42.google.com Received: from [209.85.215.42] ([209.85.215.42:39223] helo=mail-la0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AF/98-59506-5B959805 for ; Thu, 25 Oct 2012 11:24:38 -0400 Received: by mail-la0-f42.google.com with SMTP id e6so1769850lah.29 for ; Thu, 25 Oct 2012 08:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tZokKjscH09yPxZgkMmY1Aa56C/NFGjcF1SiaDIypIA=; b=AHbQjSe/yn3mlPYnS4QRLC1iyKzmzhNQho2P4JeOLtljcX9zdJhMsh8yLjn0pkG4vw s9mdJOPwTi7bFAUHQJeNpHicyJavn8p2QrmaTCrO8iURMqLPlNDRVAqHl5S2S6U3W5N1 M8uHQLDCNwj4dXfXe74Iv12NOxf4n42xp5tGlFndrvdRCX6YX3FeysCn9xjq5GyH3HbD foyXhYp9Rp1xGHNHRPv3MtgpL8sdC6BGp+r7rCDu1rij9bcoczR1ttewPhniIlzUQXw/ ueBGbcZdIrCMumzAEY03enHk3hXfF2l1/hk4w36IymXKyaYOAWj7zbayTtuXNWuKosE4 4loA== MIME-Version: 1.0 Received: by 10.152.162.97 with SMTP id xz1mr17974967lab.38.1351178673724; Thu, 25 Oct 2012 08:24:33 -0700 (PDT) Received: by 10.152.114.2 with HTTP; Thu, 25 Oct 2012 08:24:33 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Oct 2012 08:24:33 -0700 Message-ID: To: Anthony Ferrara Cc: Guillaume Rossolini , Sherif Ramadan , JJ , internals@lists.php.net Content-Type: multipart/alternative; boundary=f46d043bdabae01c5404cce3cc16 Subject: Re: [PHP-DEV] Changing the default value of "true" for CURLOPT_SSL_VERIFYHOST From: kris.craig@gmail.com (Kris Craig) --f46d043bdabae01c5404cce3cc16 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 25, 2012 at 7:26 AM, Anthony Ferrara wrote: > All, > > > On Thu, Oct 25, 2012 at 3:14 AM, Guillaume Rossolini < > g.rossolini@gmail.com> wrote: > >> On Thu, Oct 25, 2012 at 8:36 AM, Kris Craig wrote: >> > >> > What if, instead of changing the behavior, we have it throw a notice or >> > warning if a boolean value is passed here? Because this is such a >> common >> > error, I think it could be really beneficial in helping developers catch >> > this early. Thoughts? >> > >> > >> Yes please. My thoughts exactly. A notice or a warning really would be >> best >> in this case. >> Regards, >> > > I completely agree here. > > Right now, the current behavior LOOKS like it should verify the peer when > given a boolean. But in reality it doesn't. The boolean triggers insecure > behavior. Which is exactly the opposite of VERIFY_PEER (which accepts a > boolean parameter). > > Since this case does have fairly significant security implications, I > would suggest raising either a notice or a warning when a boolean true is > passed in. > > This should be pretty easy to do, by simply altering > http://lxr.php.net/xref/PHP_5_4/ext/curl/interface.c#1681 to put > VERIFYHOST as the first case statement, and checking if Z_TYPE_PP(zvalue) > == IS_BOOL, and then handling that case (letting it fall through > afterwards)... > > I would strongly support this. As using boolean true and expecting the > cast to go to 1 would be... well... rather an edge case. I'd believe that > most people don't realize that it takes an integer parameter. And if you're > relying on a cast, well, you're doing it wrong. It's like the people > relying on the string cast from an array producing "array". Sure, it may > cause a few minor issues for a few users. But the vast majority of the red > flags that it raises will be completely valid. And considering this has > security impact, I strongly feel that we should implement the > notice/warning... > > Anthony > If there are no objections, I'll go ahead and draft an RFC for the notice/docs idea later today. If anyone would like to co-author it with me, please drop me an email and I'll send you the wiki link once I've created the page. --Kris --f46d043bdabae01c5404cce3cc16--