|
View:
New views
12 Messages
—
Rating Filter:
Alert me
|
|
|
solution for UIDs bigger than 2^31Hi,
we're trying to fix squirrelmail's problem with UIDs bigger than 2^31. (sf#1855717 , rhbz#450780, ...) in short: IMAP server uses UIDs to identify emails which are 32 bit values. Some servers use lower values, but for example dovecot can gets to really high values. Squirrelmail handles these UIDs like integers, but PHP (on 32-bit system) has only 32 bit signed integer, so only first 31 bits are usable. If UID is bigger, squirrelmail can't communicate about this email with imap server. solution: In sf tracker (no change for 10 months) is recommended to "cast" input values to strings and change them to zero if input value is not numeric. I was finishing patch for this, but I've found squirrelmail uses also ++, -- and comparison operators for UIDs (in plugins/delete_move_next/setup.php: 152: delete_move_next_read(...) function). So strings can't be used for this. There is maybe another solution. Use not integers but floats. http://www.php.net/float says : "The size of a float is platform-dependent, although a maximum of ~1.8e308 with a precision of roughly 14 decimal digits is a common value (the 64 bit IEEE format)." I can confirm that php keeps number without exponent exactly up to 14 digits (tested on i386, x86_64 and ppc64). For 32 bit values 10 digits are needed. Also we have one squirrelmail instance running with floats instead of ints and it's running fine (of course, I can't say all possible function combination was tested). What do you think about this? Or, do you think, there is another solution? Cheers, Michal ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: solution for UIDs bigger than 2^31On Tue, Nov 25, 2008 at 5:40 AM, Michal Hlavinka <mhlavink@...> wrote:
> Hi, > > we're trying to fix squirrelmail's problem with UIDs bigger than 2^31. > > (sf#1855717 , rhbz#450780, ...) > > in short: > IMAP server uses UIDs to identify emails which are 32 bit values. Some > servers use lower values, but for example dovecot can gets to really > high values. > > Squirrelmail handles these UIDs like integers, but PHP (on 32-bit > system) has only 32 bit signed integer, so only first 31 bits are > usable. If UID is bigger, squirrelmail can't communicate about this > email with imap server. > > > solution: > In sf tracker (no change for 10 months) is recommended to "cast" input > values to strings and change them to zero if input value is not numeric. > I was finishing patch for this I hope against 1.5.2. I'm not sure we want to change this much code for 1.4.x. Please send the patch when you are done. > but I've found squirrelmail uses also > ++, -- and comparison operators for UIDs (in > plugins/delete_move_next/setup.php: 152: delete_move_next_read(...) > function). So strings can't be used for this. I think you are using an outdated version of SM. > There is maybe another solution. Use not integers but floats. > http://www.php.net/float says : "The size of a float is > platform-dependent, although a maximum of ~1.8e308 with a precision of > roughly 14 decimal digits is a common value (the 64 bit IEEE format)." I > can confirm that php keeps number without exponent exactly up to 14 > digits (tested on i386, x86_64 and ppc64). For 32 bit values 10 digits > are needed. Also we have one squirrelmail instance running with floats > instead of ints and it's running fine (of course, I can't say all > possible function combination was tested). > > What do you think about this? Or, do you think, there is another solution? I'd vote for the string implementation (in 1.5.2). ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: solution for UIDs bigger than 2^31Paul Lesniewski wrote:
> On Tue, Nov 25, 2008 at 5:40 AM, Michal Hlavinka <mhlavink@...> wrote: > >> ... >> >> solution: >> In sf tracker (no change for 10 months) is recommended to "cast" input >> values to strings and change them to zero if input value is not numeric. >> I was finishing patch for this >> > > I hope against 1.5.2. I'm not sure we want to change this much code > for 1.4.x. Please send the patch when you are done. > $a=sqrestrict_to_num($b); sqrestrict_to_int contains only : return (is_numeric($b) ? $b : 0); Casting not int to int results to 0, so there is no change. I was making this patch against 1.4 svn version, but I can make it for devel version, that's not a problem. >> but I've found squirrelmail uses also >> ++, -- and comparison operators for UIDs (in >> plugins/delete_move_next/setup.php: 152: delete_move_next_read(...) >> function). So strings can't be used for this. >> > > I think you are using an outdated version of SM. > svn 1.4 is outdated? ( http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/ ) >> ... >> What do you think about this? Or, do you think, there is another solution? >> > > I'd vote for the string implementation (in 1.5.2). > Yes, but what about that numeric operators? Of course, making functions for =, !=, <, <=, ++ and -- is not so difficult, but also it's not too nice IMO. Btw, what is 1.5.2 svn directory? Is it http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/trunk/ ? It looks it contains some files 7 years old... for example plugins/delete_move_next/setup.php from the above looks older than from 1.4 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: solution for UIDs bigger than 2^31On Wed, Nov 26, 2008 at 7:50 AM, Michal Hlavinka <mhlavink@...> wrote:
> Paul Lesniewski wrote: >> On Tue, Nov 25, 2008 at 5:40 AM, Michal Hlavinka <mhlavink@...> wrote: >> >>> ... >>> >>> solution: >>> In sf tracker (no change for 10 months) is recommended to "cast" input >>> values to strings and change them to zero if input value is not numeric. >>> I was finishing patch for this >>> >> >> I hope against 1.5.2. I'm not sure we want to change this much code >> for 1.4.x. Please send the patch when you are done. >> > In fact it's not so much code. Only replace $a=(int)$b; to > $a=sqrestrict_to_num($b); > sqrestrict_to_int contains only : return (is_numeric($b) ? $b : 0); > Casting not int to int > results to 0, so there is no change. Not sure what you mean by "no change", but this seems about right. The "this much code" comment was based more on the number of pages that may need to be changed, not that the change itself is big. However, I'm not sure we'd want to use is_numeric(). See the PHP manual regarding how it accepts scientific notation and hex numbers and decimal points. Rather, I believe we only want preg_match('/^[0-9]$/'), no? > I was making this patch against 1.4 svn version, but I can make it for > devel version, > that's not a problem. Thanks >>> but I've found squirrelmail uses also >>> ++, -- and comparison operators for UIDs (in >>> plugins/delete_move_next/setup.php: 152: delete_move_next_read(...) >>> function). So strings can't be used for this. >>> >> >> I think you are using an outdated version of SM. >> > svn 1.4 is outdated? > ( > http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/ > ) Hmm, well, your comments about the delete_move_next plugin didn't match what I see there, but I am not sure I've updated it in a while. I can double-check, but so should you. >>> What do you think about this? Or, do you think, there is another solution? >>> >> >> I'd vote for the string implementation (in 1.5.2). >> > Yes, but what about that numeric operators? Of course, making functions for > =, !=, <, <=, ++ and -- is not so difficult, but also it's not too nice IMO. I don't see them in delete_move_next. > Btw, what is 1.5.2 svn directory? > Is it http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/trunk/ ? Yes, trunk. > It looks it contains some files 7 years old... for example > plugins/delete_move_next/setup.php > from the above looks older than from 1.4 trunk/squirrelmail ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: solution for UIDs bigger than 2^31Paul Lesniewski wrote:
> On Wed, Nov 26, 2008 at 7:50 AM, Michal Hlavinka <mhlavink@...> wrote: > >> In fact it's not so much code. Only replace $a=(int)$b; to >> $a=sqrestrict_to_num($b); >> sqrestrict_to_int contains only : return (is_numeric($b) ? $b : 0); >> Casting not int to int >> results to 0, so there is no change. >> > > Not sure what you mean by "no change", but this seems about right. > > The "this much code" comment was based more on the number of pages > that may need to be changed, not that the change itself is big. > the number of pages (at least in 1.4svn) wasn't so high > However, I'm not sure we'd want to use is_numeric(). See the PHP > manual regarding how it accepts scientific notation and hex numbers > and decimal points. Rather, I believe we only want > preg_match('/^[0-9]$/'), no? > I've preferred is_numeric because it checks if variable is a numeric string or a number. The reason for is_numeric/other check is because of sanitizing "ugly" "accidental" values and number (even in scientific form) can cause no harm at all. Also is_numeric was my first thought and it works :) >>>> but I've found squirrelmail uses also >>>> ++, -- and comparison operators for UIDs (in >>>> plugins/delete_move_next/setup.php: 152: delete_move_next_read(...) >>>> function). So strings can't be used for this >>> I think you are using an outdated version of SM. >>> >> svn 1.4 is outdated? >> ( >> http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/ >> ) >> > > Hmm, well, your comments about the delete_move_next plugin didn't > match what I see there, but I am not sure I've updated it in a while. > I can double-check, but so should you. > function delete_move_next_read: lines 169-173 there are used operators > and -- in 1.5svn2008-11-27: there is no delete_move_next plugin and also I've found no arithmetic operators (just quick search). so... arithmetic operators are used only in 1.4 in delete_move_next plugin, but this is the version I need to fix the most (can't take devel version into on the production hosts). ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: solution for UIDs bigger than 2^31On Thu, Nov 27, 2008 at 9:01 AM, Michal Hlavinka <mhlavink@...> wrote:
> Paul Lesniewski wrote: >> On Wed, Nov 26, 2008 at 7:50 AM, Michal Hlavinka <mhlavink@...> wrote: >> >>> In fact it's not so much code. Only replace $a=(int)$b; to >>> $a=sqrestrict_to_num($b); >>> sqrestrict_to_int contains only : return (is_numeric($b) ? $b : 0); >>> Casting not int to int >>> results to 0, so there is no change. >>> >> >> Not sure what you mean by "no change", but this seems about right. >> > "no change" as invalid values will still be changed to 0. > >> The "this much code" comment was based more on the number of pages >> that may need to be changed, not that the change itself is big. >> > the number of pages (at least in 1.4svn) wasn't so high > >> However, I'm not sure we'd want to use is_numeric(). See the PHP >> manual regarding how it accepts scientific notation and hex numbers >> and decimal points. Rather, I believe we only want >> preg_match('/^[0-9]$/'), no? >> > I've preferred is_numeric because it checks if variable is a numeric > string or a number. > The reason for is_numeric/other check is because of sanitizing "ugly" > "accidental" values SquirrelMail does not create "accidental" values. As far as I know, UIDs should only contain digits. is_numeric() allows things other than digits. My regexp is very easy to understand - easier than looking up what is_numeric() allows in fact. I do not see any reason why using is_numeric() is better than that regexp, especially if the target format is a string. > and number (even in scientific form) can cause no harm at all. Also > is_numeric was > my first thought and it works :) > >>>>> but I've found squirrelmail uses also >>>>> ++, -- and comparison operators for UIDs (in >>>>> plugins/delete_move_next/setup.php: 152: delete_move_next_read(...) >>>>> function). So strings can't be used for this >>>> I think you are using an outdated version of SM. >>>> >>> svn 1.4 is outdated? >>> ( >>> http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/ >>> ) >>> >> >> Hmm, well, your comments about the delete_move_next plugin didn't >> match what I see there, but I am not sure I've updated it in a while. >> I can double-check, but so should you. >> > in 1.4svn2008-11-27: plugins/delete_move_next/setup.php: > function delete_move_next_read: lines 169-173 > there are used operators > and -- Right. > in 1.5svn2008-11-27: there is no delete_move_next plugin and also I've > found no arithmetic > operators (just quick search). Yes, the UIDs are kept in an ordered array, from which positional judgments can be more accurately made. > so... arithmetic operators are used only in 1.4 in delete_move_next > plugin, but this is the > version I need to fix the most (can't take devel version into on the > production hosts). Then I suggest you put a patch together for your float implementation and put it on the SquirrelMail tracker (feel free to post a link to it here). We will review it, but again, as of now, I think the only place we plan to make this change is in our 1.5.x branch. Thanks a lot for your help. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: solution for UIDs bigger than 2^31Hi,
all patches, we were talking about are ready (attached). patches are against 1.4 svn and 1.5 svn (yesterday) In the end, I've used conversion to string in both of them. Only 1.4 contains additional conversion in sources of delete_and_next plugin to float to perform arithmetic operations. I've tested both of them with dovecot and manually created messages with high uids. Both versions were working on systems with 64bit php, both of them resulted with imap error on 32 bit system. Now both of them works on 64 and 32 bit systems. I've checked this functions: send email (created email got big uid from dovecot) - successfully stored in Sent and readable move emails between folders next & prev delete and next & delete and prev delete email forward edit view header forward as attachment and read both email and the attachment in Sent folder Both patches has only changes to the code text for changelog/other document is missing. Regards, Michal Hlavinka Paul Lesniewski wrote: > On Thu, Nov 27, 2008 at 9:01 AM, Michal Hlavinka <mhlavink@...> wrote: > >> Paul Lesniewski wrote: >> >>> On Wed, Nov 26, 2008 at 7:50 AM, Michal Hlavinka <mhlavink@...> wrote: >>> >>> >>>> In fact it's not so much code. Only replace $a=(int)$b; to >>>> $a=sqrestrict_to_num($b); >>>> sqrestrict_to_int contains only : return (is_numeric($b) ? $b : 0); >>>> Casting not int to int >>>> results to 0, so there is no change. >>>> >>>> >>> Not sure what you mean by "no change", but this seems about right. >>> >>> >> "no change" as invalid values will still be changed to 0. >> >> >>> The "this much code" comment was based more on the number of pages >>> that may need to be changed, not that the change itself is big. >>> >>> >> the number of pages (at least in 1.4svn) wasn't so high >> >> >>> However, I'm not sure we'd want to use is_numeric(). See the PHP >>> manual regarding how it accepts scientific notation and hex numbers >>> and decimal points. Rather, I believe we only want >>> preg_match('/^[0-9]$/'), no? >>> >>> >> I've preferred is_numeric because it checks if variable is a numeric >> string or a number. >> The reason for is_numeric/other check is because of sanitizing "ugly" >> "accidental" values >> > > SquirrelMail does not create "accidental" values. As far as I know, > UIDs should only contain digits. is_numeric() allows things other > than digits. My regexp is very easy to understand - easier than > looking up what is_numeric() allows in fact. I do not see any reason > why using is_numeric() is better than that regexp, especially if the > target format is a string. > > >> and number (even in scientific form) can cause no harm at all. Also >> is_numeric was >> my first thought and it works :) >> >> >>>>>> but I've found squirrelmail uses also >>>>>> ++, -- and comparison operators for UIDs (in >>>>>> plugins/delete_move_next/setup.php: 152: delete_move_next_read(...) >>>>>> function). So strings can't be used for this >>>>>> >>>>> I think you are using an outdated version of SM. >>>>> >>>>> >>>> svn 1.4 is outdated? >>>> ( >>>> http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/ >>>> ) >>>> >>>> >>> Hmm, well, your comments about the delete_move_next plugin didn't >>> match what I see there, but I am not sure I've updated it in a while. >>> I can double-check, but so should you. >>> >>> >> in 1.4svn2008-11-27: plugins/delete_move_next/setup.php: >> function delete_move_next_read: lines 169-173 >> there are used operators > and -- >> > > Right. > > >> in 1.5svn2008-11-27: there is no delete_move_next plugin and also I've >> found no arithmetic >> operators (just quick search). >> > > Yes, the UIDs are kept in an ordered array, from which positional > judgments can be more accurately made. > > >> so... arithmetic operators are used only in 1.4 in delete_move_next >> plugin, but this is the >> version I need to fix the most (can't take devel version into on the >> production hosts). >> > > Then I suggest you put a patch together for your float implementation > and put it on the SquirrelMail tracker (feel free to post a link to it > here). We will review it, but again, as of now, I think the only > place we plan to make this change is in our 1.5.x branch. > > Thanks a lot for your help. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ----- > squirrelmail-devel mailing list > Posting guidelines: http://squirrelmail.org/postingguidelines > List address: squirrelmail-devel@... > List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel > List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel > diff -up squirrelmail/functions/global.php.biguid squirrelmail/functions/global.php --- squirrelmail/functions/global.php.biguid 2009-01-22 11:35:17.000000000 +0100 +++ squirrelmail/functions/global.php 2009-01-23 12:12:31.570024148 +0100 @@ -520,3 +520,16 @@ function is_ssl_secured_connection() return FALSE; } +/** + * Restrict value to be numeric string + * + * @param string $value The value to be checked + * + * @return $value if it is numeric string, "0" otherwise + * + * @since 1.5.3 + */ +function sqrestrict_to_num($value) +{ + return preg_match('/^[0-9]*$/',$value) ? $value : '0'; +} diff -up squirrelmail/functions/imap_messages.php.biguid squirrelmail/functions/imap_messages.php --- squirrelmail/functions/imap_messages.php.biguid 2009-01-22 11:35:17.000000000 +0100 +++ squirrelmail/functions/imap_messages.php 2009-01-23 12:11:13.912875541 +0100 @@ -1006,7 +1006,7 @@ function sqimap_get_message($imap_stream global $uid_support; // typecast to int to prohibit 1:* msgs sets - $id = (int) $id; + $id = sqrestrict_to_num($id); $flags = array(); $read = sqimap_run_command($imap_stream, "FETCH $id (FLAGS BODYSTRUCTURE)", true, $response, $message, $uid_support); if ($read) { diff -up squirrelmail/plugins/delete_move_next/setup.php.biguid squirrelmail/plugins/delete_move_next/setup.php --- squirrelmail/plugins/delete_move_next/setup.php.biguid 2009-01-22 11:35:10.000000000 +0100 +++ squirrelmail/plugins/delete_move_next/setup.php 2009-01-23 12:11:13.913875492 +0100 @@ -166,11 +166,11 @@ function delete_move_next_read($currloc) $prev_if_del = $prev; $next_if_del = $next; if (!$uid_support && ($auto_expunge || $move_to_trash)) { - if ($prev_if_del > $passed_id) { - $prev_if_del--; + if (((float)$prev_if_del) > ((float)$passed_id)) { + $prev_if_del = (string) (((float)$prev_if_del) -1); } - if ($next_if_del > $passed_id) { - $next_if_del--; + if (((float)$next_if_del) > ((float)$passed_id)) { + $next_if_del = (string) (((float)$next_if_del) -1); } } @@ -181,31 +181,31 @@ function delete_move_next_read($currloc) '<tr>'. "<td bgcolor=\"$color[9]\" width=\"100%\" align=\"center\"><small>"; - if ($prev > 0){ + if (((float)$prev) > 0){ echo "<a href=\"read_body.php?passed_id=$prev_if_del&mailbox=$urlMailbox&sort=$sort&startMessage=$startMessage&show_more=0&delete_id=$passed_id\">" . _("Delete & Prev") . "</a>" . " | \n"; } else { echo _("Delete & Prev") . " | "; } - if ($next > 0){ + if (((float)$next) > 0){ echo "<a href=\"read_body.php?passed_id=$next_if_del&mailbox=$urlMailbox&sort=$sort&startMessage=$startMessage&show_more=0&delete_id=$passed_id\">" . _("Delete & Next") . "</a>\n"; } else { echo _("Delete & Next"); } echo '</small></td></tr>'; - if ($next_if_del < 0) { + if (((float)$next_if_del) < 0) { $next_if_del = $prev_if_del; } if (($delete_move_next_formATtop == 'on') && ($currloc == 'top')) { - if ($next_if_del > 0) { + if (((float)$next_if_del) > 0) { delete_move_next_moveNextForm($next_if_del); } else { delete_move_next_moveRightMainForm(); } } if (($delete_move_next_formATbottom != 'off') && ($currloc == 'bottom')) { - if ($next_if_del > 0) { + if (((float)$next_if_del) > 0) { delete_move_next_moveNextForm($next_if_del); } else { delete_move_next_moveRightMainForm(); diff -up squirrelmail/src/compose.php.biguid squirrelmail/src/compose.php --- squirrelmail/src/compose.php.biguid 2009-01-22 11:35:13.000000000 +0100 +++ squirrelmail/src/compose.php 2009-01-23 12:11:13.913875492 +0100 @@ -92,7 +92,7 @@ sqgetGlobalVar('ent_num',$ent_num, $SQ_G sqgetGlobalVar('saved_draft',$saved_draft, SQ_FORM); if ( sqgetGlobalVar('delete_draft',$delete_draft) ) { - $delete_draft = (int)$delete_draft; + $delete_draft = sqrestrict_to_num($delete_draft); } if ( sqgetGlobalVar('startMessage',$startMessage) ) { diff -up squirrelmail/src/download.php.biguid squirrelmail/src/download.php --- squirrelmail/src/download.php.biguid 2009-01-22 11:35:13.000000000 +0100 +++ squirrelmail/src/download.php 2009-01-23 12:11:13.914875446 +0100 @@ -38,7 +38,7 @@ sqgetGlobalVar('mailbox', $mailbox, sqgetGlobalVar('ent_id', $ent_id, SQ_GET); sqgetGlobalVar('absolute_dl',$absolute_dl, SQ_GET); if ( sqgetGlobalVar('passed_id', $temp, SQ_GET) ) { - $passed_id = (int) $temp; + $passed_id = sqrestrict_to_num($temp); } global $default_charset; diff -up squirrelmail/src/image.php.biguid squirrelmail/src/image.php --- squirrelmail/src/image.php.biguid 2009-01-22 11:35:13.000000000 +0100 +++ squirrelmail/src/image.php 2009-01-23 12:11:13.914875446 +0100 @@ -32,7 +32,7 @@ displayPageHeader($color, 'None'); /* globals */ if ( sqgetGlobalVar('passed_id', $temp, SQ_GET) ) { - $passed_id = (int) $temp; + $passed_id = sqrestrict_to_num($temp); } sqgetGlobalVar('mailbox', $mailbox, SQ_GET); sqgetGlobalVar('ent_id', $ent_id, SQ_GET); diff -up squirrelmail/src/printer_friendly_main.php.biguid squirrelmail/src/printer_friendly_main.php --- squirrelmail/src/printer_friendly_main.php.biguid 2009-01-22 11:35:13.000000000 +0100 +++ squirrelmail/src/printer_friendly_main.php 2009-01-23 12:11:13.914875446 +0100 @@ -29,7 +29,7 @@ if ( ! sqgetGlobalVar('mailbox',$mailbox ! sqgetGlobalVar('passed_id',$passed_id,SQ_GET)) { error_box(_("Invalid URL"),$color); } else { - $passed_id= (int) $passed_id; + $passed_id= sqrestrict_to_num($passed_id); $view_unsafe_images = (bool) $_GET['view_unsafe_images']; /* end globals */ displayHtmlHeader( _("Printer Friendly"), '', false, true ); diff -up squirrelmail/src/read_body.php.biguid squirrelmail/src/read_body.php --- squirrelmail/src/read_body.php.biguid 2009-01-22 11:35:13.000000000 +0100 +++ squirrelmail/src/read_body.php 2009-01-23 12:11:13.915796109 +0100 @@ -750,7 +750,7 @@ sqgetGlobalVar('passed_ent_id', $passed_ sqgetGlobalVar('mailbox', $mailbox); if ( sqgetGlobalVar('passed_id', $temp) ) { - $passed_id = (int) $temp; + $passed_id = sqrestrict_to_num($temp); } if ( sqgetGlobalVar('sort', $temp) ) { $sort = (int) $temp; diff -up squirrelmail/src/view_header.php.biguid squirrelmail/src/view_header.php --- squirrelmail/src/view_header.php.biguid 2009-01-22 11:35:13.000000000 +0100 +++ squirrelmail/src/view_header.php 2009-01-23 12:11:13.915796109 +0100 @@ -119,7 +119,7 @@ function view_header($header, $mailbox, /* get global vars */ if ( sqgetGlobalVar('passed_id', $temp, SQ_GET) ) { - $passed_id = (int) $temp; + $passed_id = sqrestrict_to_num($temp); } if ( sqgetGlobalVar('mailbox', $temp, SQ_GET) ) { $mailbox = $temp; diff -up squirrelmail/functions/global.php.biguid squirrelmail/functions/global.php --- squirrelmail/functions/global.php.biguid 2009-01-22 11:36:16.000000000 +0100 +++ squirrelmail/functions/global.php 2009-01-23 12:14:24.834693183 +0100 @@ -815,4 +815,17 @@ function get_process_owner_info() return $process_info; } +/** + * Restrict value to be numeric string + * + * @param string $value The value to be checked + * + * @return $value if it is numeric string, "0" otherwise + * + * @since 1.5.3 + */ +function sqrestrict_to_num($value) +{ + return preg_match('/^[0-9]*$/',$value) ? $value : '0'; +} diff -up squirrelmail/functions/imap_messages.php.biguid squirrelmail/functions/imap_messages.php --- squirrelmail/functions/imap_messages.php.biguid 2009-01-22 11:36:16.000000000 +0100 +++ squirrelmail/functions/imap_messages.php 2009-01-23 12:13:46.603935189 +0100 @@ -895,7 +895,7 @@ function sqimap_parse_address($read, &$i */ function sqimap_get_message($imap_stream, $id, $mailbox, $hide=0) { // typecast to int to prohibit 1:* msgs sets - $id = (int) $id; + $id = sqrestrict_to_num($id); $flags = array(); $read = sqimap_run_command($imap_stream, "FETCH $id (FLAGS BODYSTRUCTURE)", true, $response, $message, TRUE); if ($read) { diff -up squirrelmail/src/compose.php.biguid squirrelmail/src/compose.php --- squirrelmail/src/compose.php.biguid 2009-01-22 11:36:09.000000000 +0100 +++ squirrelmail/src/compose.php 2009-01-23 12:13:46.605062882 +0100 @@ -95,7 +95,7 @@ sqgetGlobalVar('ent_num',$ent_num, $SQ_G sqgetGlobalVar('saved_draft',$saved_draft, SQ_FORM); if ( sqgetGlobalVar('delete_draft',$delete_draft) ) { - $delete_draft = (int)$delete_draft; + $delete_draft = sqrestrict_to_num($delete_draft); } if ( sqgetGlobalVar('startMessage',$startMessage) ) { diff -up squirrelmail/src/download.php.biguid squirrelmail/src/download.php --- squirrelmail/src/download.php.biguid 2009-01-22 11:36:09.000000000 +0100 +++ squirrelmail/src/download.php 2009-01-23 12:13:46.605062882 +0100 @@ -49,7 +49,7 @@ sqgetGlobalVar('ent_id', $ent_id, sqgetGlobalVar('absolute_dl',$absolute_dl, SQ_GET); sqgetGlobalVar('force_crlf', $force_crlf, SQ_GET); if ( sqgetGlobalVar('passed_id', $temp, SQ_GET) ) { - $passed_id = (int) $temp; + $passed_id = sqrestrict_to_num($temp); } if (!sqgetGlobalVar('account', $account, SQ_GET) ) { $account = 0; diff -up squirrelmail/src/image.php.biguid squirrelmail/src/image.php --- squirrelmail/src/image.php.biguid 2009-01-22 11:36:09.000000000 +0100 +++ squirrelmail/src/image.php 2009-01-23 12:13:46.606062974 +0100 @@ -23,7 +23,7 @@ displayPageHeader($color); /* globals */ if ( sqgetGlobalVar('passed_id', $temp, SQ_GET) ) { - $passed_id = (int) $temp; + $passed_id = sqrestrict_to_num($temp); } sqgetGlobalVar('mailbox', $mailbox, SQ_GET); sqgetGlobalVar('ent_id', $ent_id, SQ_GET); diff -up squirrelmail/src/read_body.php.biguid squirrelmail/src/read_body.php --- squirrelmail/src/read_body.php.biguid 2009-01-22 11:36:09.000000000 +0100 +++ squirrelmail/src/read_body.php 2009-01-23 12:13:46.606062974 +0100 @@ -785,7 +785,7 @@ sqgetGlobalVar('passed_ent_id', $passed_ sqgetGlobalVar('mailbox', $mailbox); if ( sqgetGlobalVar('passed_id', $temp) ) { - $passed_id = (int) $temp; + $passed_id = sqrestrict_to_num($temp); } if ( sqgetGlobalVar('sort', $temp) ) { $sort = (int) $temp; diff -up squirrelmail/src/view_header.php.biguid squirrelmail/src/view_header.php --- squirrelmail/src/view_header.php.biguid 2009-01-22 11:36:09.000000000 +0100 +++ squirrelmail/src/view_header.php 2009-01-23 12:13:46.606908367 +0100 @@ -84,7 +84,7 @@ function parse_viewheader($imapConnectio /* get global vars */ if ( sqgetGlobalVar('passed_id', $temp, SQ_GET) ) { - $passed_id = (int) $temp; + $passed_id = sqrestrict_to_num($temp); } if ( sqgetGlobalVar('mailbox', $temp, SQ_GET) ) { $mailbox = $temp; diff -up squirrelmail/src/view_html.php.biguid squirrelmail/src/view_html.php --- squirrelmail/src/view_html.php.biguid 2009-01-22 11:36:09.000000000 +0100 +++ squirrelmail/src/view_html.php 2009-01-23 12:13:46.606908367 +0100 @@ -35,7 +35,7 @@ sqgetGlobalVar('mailbox', $mailbox, sqgetGlobalVar('ent_id', $ent_id, SQ_GET); sqgetGlobalVar('passed_ent_id', $passed_ent_id, SQ_GET); if (sqgetGlobalVar('passed_id', $temp, SQ_GET)) { - $passed_id = (int) $temp; + $passed_id = sqrestrict_to_num($temp); } // TODO: add required var checks here. diff -up squirrelmail/src/view_text.php.biguid squirrelmail/src/view_text.php --- squirrelmail/src/view_text.php.biguid 2009-01-22 11:36:09.000000000 +0100 +++ squirrelmail/src/view_text.php 2009-01-23 12:13:46.606908367 +0100 @@ -28,7 +28,7 @@ sqgetGlobalVar('ent_id', $ent_id, sqgetGlobalVar('passed_ent_id', $passed_ent_id, SQ_GET); sqgetGlobalVar('QUERY_STRING', $QUERY_STRING, SQ_SERVER); if (sqgetGlobalVar('passed_id', $temp, SQ_GET)) { - $passed_id = (int) $temp; + $passed_id = sqrestrict_to_num($temp); } $imapConnection = sqimap_login($username, false, $imapServerAddress, $imapPort, 0); ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: solution for UIDs bigger than 2^31one note... in patch for 1.4 there is wrongly specified tag @since 1.5.3
instead of 1.4.18 (squirrelmail/functions/global.php, on the top of the patch) Michal Hlavinka wrote: > Hi, > > all patches, we were talking about are ready (attached). > > patches are against 1.4 svn and 1.5 svn (yesterday) > In the end, I've used conversion to string in both of them. Only 1.4 > contains > additional conversion in sources of delete_and_next plugin to float > to perform arithmetic operations. > > I've tested both of them with dovecot and manually created messages > with high > uids. Both versions were working on systems with 64bit php, both of them > resulted with imap error on 32 bit system. > > Now both of them works on 64 and 32 bit systems. I've checked this > functions: > send email (created email got big uid from dovecot) - successfully > stored in Sent and readable > move emails between folders > next & prev > delete and next & delete and prev > delete email > forward > edit > view header > forward as attachment and read both email and the attachment in Sent > folder > > Both patches has only changes to the code text for changelog/other > document is missing. > > Regards, > > Michal Hlavinka > ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: solution for UIDs bigger than 2^31Please do not top-post. Please review our mailing list posting
guidelines (linked at the bottom of all messages on this list) for more information about how to post on our lists. >>>>> In fact it's not so much code. Only replace $a=(int)$b; to >>>>> $a=sqrestrict_to_num($b); >>>>> sqrestrict_to_int contains only : return (is_numeric($b) ? $b : 0); >>>>> Casting not int to int >>>>> results to 0, so there is no change. >>>>> >>>>> >>>> >>>> Not sure what you mean by "no change", but this seems about right. >>>> >>>> >>> >>> "no change" as invalid values will still be changed to 0. >>> >>> >>>> >>>> The "this much code" comment was based more on the number of pages >>>> that may need to be changed, not that the change itself is big. >>>> >>>> >>> >>> the number of pages (at least in 1.4svn) wasn't so high >>> >>> >>>> >>>> However, I'm not sure we'd want to use is_numeric(). See the PHP >>>> manual regarding how it accepts scientific notation and hex numbers >>>> and decimal points. Rather, I believe we only want >>>> preg_match('/^[0-9]$/'), no? >>>> >>>> >>> >>> I've preferred is_numeric because it checks if variable is a numeric >>> string or a number. >>> The reason for is_numeric/other check is because of sanitizing "ugly" >>> "accidental" values >>> >> >> SquirrelMail does not create "accidental" values. As far as I know, >> UIDs should only contain digits. is_numeric() allows things other >> than digits. My regexp is very easy to understand - easier than >> looking up what is_numeric() allows in fact. I do not see any reason >> why using is_numeric() is better than that regexp, especially if the >> target format is a string. >> >> >>> >>> and number (even in scientific form) can cause no harm at all. Also >>> is_numeric was >>> my first thought and it works :) >>> >>> >>>>>>> >>>>>>> but I've found squirrelmail uses also >>>>>>> ++, -- and comparison operators for UIDs (in >>>>>>> plugins/delete_move_next/setup.php: 152: delete_move_next_read(...) >>>>>>> function). So strings can't be used for this >>>>>>> >>>>>> >>>>>> I think you are using an outdated version of SM. >>>>>> >>>>>> >>>>> >>>>> svn 1.4 is outdated? >>>>> ( >>>>> >>>>> http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/ >>>>> ) >>>>> >>>>> >>>> >>>> Hmm, well, your comments about the delete_move_next plugin didn't >>>> match what I see there, but I am not sure I've updated it in a while. >>>> I can double-check, but so should you. >>>> >>>> >>> >>> in 1.4svn2008-11-27: plugins/delete_move_next/setup.php: >>> function delete_move_next_read: lines 169-173 >>> there are used operators > and -- >>> >> >> Right. >> >> >>> >>> in 1.5svn2008-11-27: there is no delete_move_next plugin and also I've >>> found no arithmetic >>> operators (just quick search). >>> >> >> Yes, the UIDs are kept in an ordered array, from which positional >> judgments can be more accurately made. >> >> >>> >>> so... arithmetic operators are used only in 1.4 in delete_move_next >>> plugin, but this is the >>> version I need to fix the most (can't take devel version into on the >>> production hosts). >>> >> >> Then I suggest you put a patch together for your float implementation >> and put it on the SquirrelMail tracker (feel free to post a link to it >> here). We will review it, but again, as of now, I think the only >> place we plan to make this change is in our 1.5.x branch. >> >> Thanks a lot for your help. > > all patches, we were talking about are ready (attached). > patches are against 1.4 svn and 1.5 svn (yesterday) > In the end, I've used conversion to string in both of them. Only 1.4 > contains > additional conversion in sources of delete_and_next plugin to float > to perform arithmetic operations. Thank you. We won't be applying this to 1.4 for now, but I have attached it to the tracker item you created. For 1.5, I have just applied some changes that are different from yours, so we'd really appreciate if you could download the newest 1.5.2 SVN code (if using snapshots, wait at least 24 hours, or see the attached patch) and test that it works. I have a couple plugins (beside the core ones I changed in 1.5.2) that need corresponding changes, which I will release soon, especially if I can get feedback on the 1.5.2 changes. Thanks again very much for your help. > I've tested both of them with dovecot and manually created messages with > high > uids. Both versions were working on systems with 64bit php, both of them > resulted with imap error on 32 bit system. > > Now both of them works on 64 and 32 bit systems. I've checked this > functions: > send email (created email got big uid from dovecot) - successfully stored in > Sent and readable > move emails between folders > next & prev > delete and next & delete and prev > delete email > forward > edit > view header > forward as attachment and read both email and the attachment in Sent folder > > Both patches has only changes to the code text for changelog/other document > is missing. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: solution for UIDs bigger than 2^31>> all patches, we were talking about are ready (attached).
>> >> patches are against 1.4 svn and 1.5 svn (yesterday) >> In the end, I've used conversion to string in both of them. Only 1.4 >> contains >> additional conversion in sources of delete_and_next plugin to float >> to perform arithmetic operations. >> >> I've tested both of them with dovecot and manually created messages >> with high >> uids. Both versions were working on systems with 64bit php, both of them >> resulted with imap error on 32 bit system. >> >> Now both of them works on 64 and 32 bit systems. I've checked this >> functions: >> send email (created email got big uid from dovecot) - successfully >> stored in Sent and readable >> move emails between folders >> next & prev >> delete and next & delete and prev >> delete email >> forward >> edit >> view header >> forward as attachment and read both email and the attachment in Sent >> folder >> >> Both patches has only changes to the code text for changelog/other >> document is missing. > > one note... in patch for 1.4 there is wrongly specified tag @since 1.5.3 > instead of 1.4.18 > (squirrelmail/functions/global.php, on the top of the patch) There is no such thing as 1.5.3, so it's wrong in both places, but no big deal! :-) ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: solution for UIDs bigger than 2^31...
>> all patches, we were talking about are ready (attached). >> > > Thank you. (No need to paste them in the email body too.) > > I didn't paste them in email body, only attached them. Maybe thunderbird did it? Anyway, on the mailing list archive they are not pasted in text too. > There is no such thing as 1.5.3, so it's wrong in both places, but no > big deal! I meant actual released version is 1.5.2 so first time, it'd be released in 1.5.3 >> patches are against 1.4 svn and 1.5 svn (yesterday) >> In the end, I've used conversion to string in both of them. Only 1.4 >> contains >> additional conversion in sources of delete_and_next plugin to float >> to perform arithmetic operations. >> > > Thank you. We won't be applying this to 1.4 for now, but I have > attached it to the tracker item you created. For 1.5, I have just > applied some changes that are different from yours, so we'd really > appreciate if you could download the newest 1.5.2 SVN code (if using > snapshots, wait at least 24 hours, or see the attached patch) and test > that it works. > * send email (created email got big uid from dovecot) - successfully stored in Sent and readable * move emails between folders * next & prev * delete and next & delete and prev * delete email * forward * edit * view header * forward as attachment and read both email and the attachment in Sent folder it works. I need 1.4 working with big uids, so I'm going to apply this (or modified) patch to our squirrelmail rpm packages, so I wonder what's the destiny of the 1.4 patch? > I have a couple plugins (beside the core ones I changed in 1.5.2) that > need corresponding changes, which I will release soon, especially if I > can get feedback on the 1.5.2 changes. > > Thanks again very much for your help. > Is there any ETA for 1.5 beta, rc, final? Michal ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: solution for UIDs bigger than 2^31>> There is no such thing as 1.5.3, so it's wrong in both places, but no
>> big deal! > I meant actual released version is 1.5.2 so first time, it'd be released > in 1.5.3 1.5.2 has not been released yet. It would in fact be released in version 1.5.2. >>> patches are against 1.4 svn and 1.5 svn (yesterday) >>> In the end, I've used conversion to string in both of them. Only 1.4 >>> contains >>> additional conversion in sources of delete_and_next plugin to float >>> to perform arithmetic operations. >>> >> >> Thank you. We won't be applying this to 1.4 for now, but I have >> attached it to the tracker item you created. For 1.5, I have just >> applied some changes that are different from yours, so we'd really >> appreciate if you could download the newest 1.5.2 SVN code (if using >> snapshots, wait at least 24 hours, or see the attached patch) and test >> that it works. > > I've checked this functions: > * send email (created email got big uid from dovecot) - successfully > stored in Sent and readable > * move emails between folders > * next & prev > * delete and next & delete and prev > * delete email > * forward > * edit > * view header > * forward as attachment and read both email and the attachment in Sent > folder > > it works. THANK YOU SO VERY MUCH. We really appreciate the help!!!! > I need 1.4 working with big uids, so I'm going to apply this (or > modified) patch to our > squirrelmail rpm packages, so I wonder what's the destiny of the 1.4 patch? It will continue to be available in our tracker for people who want it, and depending on feedback and team opinions based on how popular it is, we may decide at some time in the future that the changes in the (stable) code are worth adding. >> I have a couple plugins (beside the core ones I changed in 1.5.2) that >> need corresponding changes, which I will release soon, especially if I >> can get feedback on the 1.5.2 changes. >> >> Thanks again very much for your help. > > Is there any ETA for 1.5 beta, rc, final? Not yet, but I'd personally like to see the heat turned up on this. We'll see. Help is always appreciated. ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
| Free embeddable forum powered by Nabble | Forum Help |