bundled libcurl limits cookie expiry date to the year 2038

[apparentorder]

When curl-rust is using the bundled libcurl, it will silently limit the expiry time (unix timestamp) of received cookies to i32::MAX (2147483647), for example:

< Set-Cookie: LSID=DQAAAKEaem_vYg; Expires=Thu, 13 Jan 2078 22:23:01 GMT; HttpOnly; Path=/accounts
* Added cookie HSID="AYQEVnDKrdst" for domain localhost, path /, expire 2147483647

But "Thu, 13 Jan 2078 22:23:01 GMT" actually is 3409338181.

I have reproduced this on different OS (Amazon Linux, Ubuntu) and different architectures (x86-64, aarch64).

When libcurl header files are present and curl-rust is built without the bundled libcurl, this bug does not occur. Assorted versions of the curl client also seem to be unaffected.

Test program:

use curl::easy::Easy;

fn main() {
    let mut easy = Easy::new();
    easy.url("http://localhost:8000/cookie-jar").unwrap();

    easy.verbose(true);
    easy.cookie_jar("/dev/stdout");
    easy.perform().unwrap();
}

With bundled libcurl, the output will contain the above line, and also:

#HttpOnly_localhost	FALSE	/accounts	FALSE	2147483647	LSID	DQAAAKEaem_vYg

I'll also mention #321 here because I was completely unaware that I forgot to install libcurl-devel, and I was really surprised that some libcurl gets bundled silently.

[sagebind]

It is possible there is some build-time configuration define that we aren't setting when building the bundled libcurl version that usually gets set when libcurl is built using its typical distro build chain. I would check here to see if there is a HAVE_ variable that may be necessary that we aren't setting. Being limited to a 32-bit timestamp sounds an awful lot like libcurl wanting to detect optional 64-bit timestamp support, and our build script not informing libcurl of the timestamp width of the target triple.

I'll also mention https://github.com/alexcrichton/curl-rust/issues/321 here because I was completely unaware that I forgot to install libcurl-devel, and I was really surprised that some libcurl gets bundled silently.

I think we're likely to close that issue as "won't fix". Not only would not falling back to the bundled libcurl be a breaking change, it would also be annoying for most users who would rather see compiling curl-rust to "just work" whether or not a system libcurl is available rather than needing to opt-in to a bundled version somehow. That's been @alexcrichton's general stance too if I recall.