Re: size_t and 64 bit integer branch
On Wed, November 27, 2013 11:24, Jakub Zelenka wrote:
> Hi Anatol
>
>
>
> On Wed, Nov 27, 2013 at 8:37 AM, Anatol Belski <ab@php.net> 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
Thread (8 messages)