From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "A.C." Newsgroups: gmane.emacs.bugs Subject: bug#37974: eww produces "error in process filter: Specified time is not representable" Date: Tue, 29 Oct 2019 18:23:04 -0400 Message-ID: References: <20191029003245.GA10341@arch-chirva.localdomain> <20191029045102.GA5852@D-69-91-141-110.dhcp4.washington.edu> <20191029102522.GA26999@D-69-91-141-110.dhcp4.washington.edu> <1FB46AE7-5E98-443D-950D-212F81FF5E77@gmail.com> <87wocnzpkp.fsf@gnus.org> <871ruvz0cd.fsf@gnus.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----447POUZVO0D04GDCUJ0MWZOWZEO5T1" Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="187589"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: K-9 Mail for Android Cc: 37974@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 29 23:24:14 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iPZuQ-000mgy-Hb for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 Oct 2019 23:24:14 +0100 Original-Received: from localhost ([::1]:34552 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iPZuO-0008Dp-Qf for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 Oct 2019 18:24:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42655) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iPZuH-0008AB-QP for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2019 18:24:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iPZuG-0000Lx-AY for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2019 18:24:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39898) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iPZuE-0000Kt-6Y for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2019 18:24:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iPZuD-0008Ux-V9 for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2019 18:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "A.C." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Oct 2019 22:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37974 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed Original-Received: via spool by 37974-submit@debbugs.gnu.org id=B37974.157238779832588 (code B ref 37974); Tue, 29 Oct 2019 22:24:01 +0000 Original-Received: (at 37974) by debbugs.gnu.org; 29 Oct 2019 22:23:18 +0000 Original-Received: from localhost ([127.0.0.1]:48719 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iPZtU-0008TX-O4 for submit@debbugs.gnu.org; Tue, 29 Oct 2019 18:23:17 -0400 Original-Received: from mail-qt1-f180.google.com ([209.85.160.180]:40796) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iPZtS-0008TF-V0 for 37974@debbugs.gnu.org; Tue, 29 Oct 2019 18:23:15 -0400 Original-Received: by mail-qt1-f180.google.com with SMTP id o49so439917qta.7 for <37974@debbugs.gnu.org>; Tue, 29 Oct 2019 15:23:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:cc:from:message-id; bh=lnrrzXyxqP9gZOM2LGwQLMYP9OGjHkURqgTKr3aeMRM=; b=H31CqgYvqh6NDpAeCyz6TqMwTJXkm0S+CXhxP5wiEAryuF3kgdaB5/Nutmgc9OWm9j mTsmcp61PlCaklEwhYZkupxR1ejAJnk9pPwja1sR6yrBtkFDakDLtYttl4xPqNAueu+p jE7gUJXb8JiUKhoQxLZXydvMijekHMLWNhcTRXsR7/KU2geWgo71iMAPPh5NAeoUJBPv rkIx8bZow0CocLpcCjsW1nYjumoXYpkJkBT5ZbCPTZMJp8V1w+fNTSul51is9Shjd3JC W5Pnu1NU4d6QMHyZyZpIjaZdTALkwKETkRYdxq9bqUNXTuGtVDhnVejMj+1gFc6CA3Yx 791A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:cc:from :message-id; bh=lnrrzXyxqP9gZOM2LGwQLMYP9OGjHkURqgTKr3aeMRM=; b=ruyuuHR1ERTdtPp4XAYF14k314dIMUA9V8OX+9fOJvCKX8uTijkzLmbPOa/6i85pNo OfNiE/AHsy9bBkkTiA8o38Ha9eMpMn8ZXPinr3WYtPeOGyPax7SVLfO0HXPrKgKmts/d hrTlCHAhVTLv4ulbaaWM+yDhf6BCIFo2CpYwc9vaDBfJCKYXCVhhnIJ9OG99/uVUoS38 JLw1CYab7D6AhYTAyTiDU8gcBTc/I2+M8jJ+fukF4x/m6aq4EYdeYlCIJN246yQWHuDH TZdX8B04977RJe+JGkrZGc5K8+zlhYJNwo7BN4Vc2+01GcjPSGt99e0txaUtqiCWktAu KXlg== X-Gm-Message-State: APjAAAVbHDn/dwnlHdQkmeOYAzCKF51QEId3x7BcSiJBW/Vp0AVyqVaK YOO//xCsk+vBHl93wtWpaeqYKCRb X-Google-Smtp-Source: APXvYqx1KifybWDgrBVR7FXYVzvZ0uMe1opMaF/5eQh5hFByVDua6glwOBNW2pBKQHX7r0xAZnuN1g== X-Received: by 2002:a05:6214:14b2:: with SMTP id bo18mr9072107qvb.72.1572387789371; Tue, 29 Oct 2019 15:23:09 -0700 (PDT) Original-Received: from [192.168.1.171] (pool-68-133-6-220.bflony.fios.verizon.net. [68.133.6.220]) by smtp.gmail.com with ESMTPSA id r2sm154852qtc.28.2019.10.29.15.23.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Oct 2019 15:23:08 -0700 (PDT) In-Reply-To: <871ruvz0cd.fsf@gnus.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:170382 Archived-At: ------447POUZVO0D04GDCUJ0MWZOWZEO5T1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On October 29, 2019 5:52:02 PM EDT, Lars Ingebrigtsen w= rote: >"A=2EC=2E" writes: > >>>In any case, Emacs 27 has bignum support, so this should hopefully >not >>>be a problem any more=2E Can you try the test case with the current >>>Emacs >>>trunk and see whether it's still present? >> >> That will be tough=2E This 32-bit machine overheats something fierce; I >> doubt I can even clone the git repo without it dying, let alone >> compile=2E > >Testing a bit more, the bug is present even on 64-bits systems=2E > >While this works: > >(format-time-string "%a %b %d %H:%M:%S %Y GMT" 9460800000000000 t) >=3D> "Wed Apr 08 00:00:00 299802787 GMT" > >(format-time-string "%a %b %d %H:%M:%S %Y GMT" 94608000000000000 t) > >errors out with > >"Specified time is not representable" Absolutely; I noted as much in the follow-up email to the one you cited ab= ove: While 32-bit systems are vulnerable to the "year-2038 problem" 64-bit ones= have an issue with year=20 2147485548 =3D 1900 + 2**31 So you can only go up to Wed Dec 31 23:59:59 GMT 2147485547 meaning the highest it'll run without error is (format-time-string "%a %b %d %H:%M:%S %Y GMT" 67768036191676799 t) As soon as you try 67768036191676800 =3D 67768036191676799 + 1 you'll get the=20 "Specified time is not representable" complaint=2E > >Test case: > >(url-cookie-handle-set-cookie "browser=3D68=2E133=2E6=2E220=2E15723241609= 79722; >path=3D/; max-age=3D946080000000000000; domain=3D=2Earxiv=2Eorg") > >The input is completely controlled by the server, of course, and bogus >data may appear in the cookie, and the URL library should protect >against this, so I've now made it ignore these errors in Emacs 27=2E=20 >This >patch may also apply to the version of Emacs you're using; I haven't >checked=2E > >diff --git a/lisp/url/url-cookie=2Eel b/lisp/url/url-cookie=2Eel >index 31fc3e7266=2E=2E740a43fa16 100644 >--- a/lisp/url/url-cookie=2Eel >+++ b/lisp/url/url-cookie=2Eel >@@ -304,9 +304,10 @@ url-cookie-handle-set-cookie > (url-filename url-current-object)))) > (expires nil)) > (if (and max-age (string-match "\\`-?[0-9]+\\'" max-age)) >- (setq expires (format-time-string "%a %b %d %H:%M:%S %Y GMT" >- (time-add nil (read max-age)) >- t)) >+ (setq expires (ignore-errors >+ (format-time-string "%a %b %d %H:%M:%S %Y GMT" >+ (time-add nil (read max-age)) >+ t))) > (setq expires (cdr-safe (assoc-string "expires" args t)))) > (while (consp trusted) > (if (string-match (car trusted) current-url) --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------447POUZVO0D04GDCUJ0MWZOWZEO5T1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On October 29, 2019 5:52:02 PM EDT, Lars Ingebrigtsen <larsi@gnu= s=2Eorg> wrote:
>"A=2EC=2E" <achirvasub@gmail=2Ecom> writes:=
>
>>>In any case, Emacs 27 has bignum support, so this s= hould hopefully
>not
>>>be a problem any more=2E Can you = try the test case with the current
>>>Emacs
>>>trun= k and see whether it's still present?
>>
>> That will be = tough=2E This 32-bit machine overheats something fierce; I
>> doub= t I can even clone the git repo without it dying, let alone
>> com= pile=2E
>
>Testing a bit more, the bug is present even on 64-bi= ts systems=2E
>
>While this works:
>
>(format-time-= string "%a %b %d %H:%M:%S %Y GMT" 9460800000000000 t)
>=3D> "Wed A= pr 08 00:00:00 299802787 GMT"
>
>(format-time-string "%a %b %d = %H:%M:%S %Y GMT" 94608000000000000 t)
>
>errors out with
>= ;
>"Specified time is not representable"

Absolutely; I noted a= s much in the follow-up email to the one you cited above:

While 32-b= it systems are vulnerable to the "year-2038 problem" 64-bit ones have an is= sue with year

2147485548 =3D 1900 + 2**31

So you can only go= up to

Wed Dec 31 23:59:59 GMT 2147485547

meaning the highest= it'll run without error is

(format-time-string "%a %b %d %H:%M:%S %= Y GMT" 67768036191676799 t)

As soon as you try

67768036191676= 800 =3D 67768036191676799 + 1

you'll get the

"Specified time= is not representable"

complaint=2E

>
>Test case:>
>(url-cookie-handle-set-cookie "browser=3D68=2E133=2E6=2E220=2E= 1572324160979722;
>path=3D/; max-age=3D946080000000000000; domain=3D= =2Earxiv=2Eorg")
>
>The input is completely controlled by the s= erver, of course, and bogus
>data may appear in the cookie, and the U= RL library should protect
>against this, so I've now made it ignore t= hese errors in Emacs 27=2E
>This
>patch may also apply to the = version of Emacs you're using; I haven't
>checked=2E
>
>d= iff --git a/lisp/url/url-cookie=2Eel b/lisp/url/url-cookie=2Eel
>inde= x 31fc3e7266=2E=2E740a43fa16 100644
>--- a/lisp/url/url-cookie=2Eel>+++ b/lisp/url/url-cookie=2Eel
>@@ -304,9 +304,10 @@ url-cookie= -handle-set-cookie
> (url-filename url-current-object))))
>= (expires nil))
> (if (and max-age (string-match "\\`-?[0-9]+\\= '" max-age))
>- (setq expires (format-time-string "%a %b %d %H:%M:%S = %Y GMT"
>- (time-add nil (read max-age))
>- t))
= >+ (setq expires (ignore-errors
>+ (format-= time-string "%a %b %d %H:%M:%S %Y GMT"
>+ (time-add nil (read= max-age))
>+ t)))
> (setq expires (cdr-safe (ass= oc-string "expires" args t))))
> (while (consp trusted)
> = (if (string-match (car trusted) current-url)

--
Sent from m= y Android device with K-9 Mail=2E Please excuse my brevity=2E ------447POUZVO0D04GDCUJ0MWZOWZEO5T1--