wget-1.10.2 cookie expiry bug

[Jay Soffian]

(Resend as I've received no reply to the original message.)

Kind wget maintainers,









      expires = http_atotm (value_copy);
      if (expires != (time_t) -1)
    {
      cookie->permanent = 1;
      cookie->expiry_time = expires;
    }
      else
    /* Error in expiration spec.  Assume default (cookie doesn't
       expire, but valid only for this session.)  */
    ;

      /* According to netscape's specification, expiry time in the
     past means that discarding of a matching cookie is
     requested.  */
      if (cookie->expiry_time < cookies_now)
    cookie->discard_requested = 1;



Thanks,

j.

I believe I found a bug in the wget cookie expiry handling. Recently I was using wget receiving back a cookie with an expiration of "Sun, 20-Sep-2043 19:37:28 GMT". This fits inside a 32-bit unsigned long but unfortunately overflows a 32-bit signed long by about 4 years. It would appear that timegm (called from http_atotm) returns -1 when it overflows. At least that was the behavior I observed with my system's timegm (OS X 10.4.8/i386) and the timegm that ships with wget (I recompiled using the wget timegm function to test). Looking at cookies.c, the intent seems to be to treat a (time_t) -1 as a session cookie. If this is the case, there is a bug in the logic which instead causes wget to discard the cookie entirely: The problem is that when http_atotm returns -1, cookie->expiry_time does not get set, defaulting to 0 (I think). That then causes the cookie to be discarded. I've attached the world's smallest patch which corrects this behavior to what I believe the comments intended.

wget-1.10.2.cookie_expiry.patch
Description: Binary data