Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:70440 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 53572 invoked from network); 27 Nov 2013 11:33:34 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Nov 2013 11:33:34 -0000 Authentication-Results: pb1.pair.com smtp.mail=ab@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=ab@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.73.107 as permitted sender) X-PHP-List-Original-Sender: ab@php.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:52907] helo=klapt.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D0/B4-24795-C88D5925 for ; Wed, 27 Nov 2013 06:33:33 -0500 Received: by klapt.com (Postfix, from userid 33) id 08F3323D609E; Wed, 27 Nov 2013 12:33:28 +0100 (CET) Received: from 178.7.235.222 (SquirrelMail authenticated user anatol@belski.net) by webmail.klapt.com with HTTP; Wed, 27 Nov 2013 12:33:28 +0100 Message-ID: In-Reply-To: References: Date: Wed, 27 Nov 2013 12:33:28 +0100 To: "Jakub Zelenka" Cc: "PHP internals" Reply-To: "Anatol Belski" User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] size_t and 64 bit integer branch From: ab@php.net ("Anatol Belski") On Wed, November 27, 2013 11:24, Jakub Zelenka wrote: > Hi Anatol > > > > On Wed, Nov 27, 2013 at 8:37 AM, Anatol Belski wrote: > > >> >> your patch looks fine. Unfortunately I've overseen your mail in the >> daily flood and made some changes to openssl too. Why didn't you update >> the wiki page by going on? It's exactly for the purpose of knowing >> what's currently going on :) In any case, could you please merge with >> the current state and do a PR? I'll merge it then. >> >> One thing though about openssl and issues you mention in the gist - the >> 'int' vs. php_int_t overflows on 64 bit should be fixed on run time >> checking against INT_MAX. Maybe that's what you could extend for the >> openssl ext. That's an issue in many other libs too. >> >> Thanks for you work >> >> >> Anatol >> >> >> > I quickly looked on your commit and think that we mostly did the same > stuff :). Sorry for not updating the wiki, thought that will be better if > I email > you first. > > However there few extra fixes in my commit and some extra fixes in your > commits so I will merge them. > > php_int_t vs int fixes will be quite easy. I'll do that. The bigger task > is int vs size_t (zend_str_size...) - signed vs unsigned. For some cases > (encryption, digest and other ctx updates) this can be fixed by splitting > the processing into more ctx updates. I think this could be useful on > 32bit > when someone tries to encrypt more than 1 << 32 string. In that case, > using one update (as it is now) would fail. Other cases should probably > generate an error as there are not useful anyway. There few other case > that I need to look at as well (bio_buf_st->length, ASN_STRING length > retval...). > > I can assign it to myself in the wiki and set status "in progress" and > when it's done, I will update it and send PR. Is that ok? > > Jakub > Jakub, the ctx update issue might be interesting for the current codebase as well, I think. A simpler way were the range check for INT_MAX as it's always possible to pass a smaller chunk from the userland. The size_t vs. signed might can get an issue of course, that's the common thread of course so should be fixed where applicable. I could only welcome you to update the wiki with the task you can take on, whether nicer or simpler solution :) Thanks Anatol