GNU logs - #19565, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#19565: Emacs vulnerable to endless-data attack (minor)
Resent-From: Kelly Dean <kelly@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 11 Jan 2015 11:14:02 +0000
Resent-Message-ID: <handler.19565.B.142097478325204 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 19565 <at> debbugs.gnu.org
From: Kelly Dean <kelly@HIDDEN>
Date: Sun, 11 Jan 2015 11:12:00 +0000
Message-ID: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

A few days ago I speculated, but now I confirmed. It's technically considered a vulnerability, but in Emacs's case it's a minor problem; exploiting it would be more a prank than a real attack.

To demo locally for archive metadata:
echo -en 'HTTP/1.1 200 OK\r\n\r\n' > header
cat header /dev/urandom | nc -l -p 80

Then in Emacs:
(setq package-archives '(("foo" . "http://127.0.0.1/")))
M-x list-packages

Watch Emacs's memory usage grow and grow...

If you set some arbitrary limit on the size of archive-contents, then theoretically you break some legitimate ginormous elpa. And if you're getting garbage, you wouldn't know it until you've downloaded more garbage than the limit. The right way to fix it is to include the size of archive-contents in another file that can legitimately be constrained to a specified small maximum size, sign that file, and in the client, abort the archive-contents download if you get more data than you're supposed to.

The timestamp file that I proposed for fixing the metadata replay vuln (bug #19479) would be a suitable place to record the size; then no additional file (and signature) is needed just to solve endless-metadata. For the corresponding endless-data vuln for packages instead of metadata, I already put sizes in the package records in my patch for the package replay vuln.

Don't forget you need to set a maximum size not only on the timestamp file, but also on the signature file, or they would be vulnerable too. E.g. just hardcode 1kB.

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.503 (Entity 5.503)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Kelly Dean <kelly@HIDDEN>
Subject: bug#19565: Acknowledgement (Emacs vulnerable to endless-data
 attack (minor))
Message-ID: <handler.19565.B.142097478325204.ack <at> debbugs.gnu.org>
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
X-Gnu-PR-Message: ack 19565
X-Gnu-PR-Package: emacs
Reply-To: 19565 <at> debbugs.gnu.org
Date: Sun, 11 Jan 2015 11:14:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 19565 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
19565: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D19565
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#19565: Emacs vulnerable to endless-data attack (minor)
Resent-From: Richard Stallman <rms@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 11 Jan 2015 18:34:02 +0000
Resent-Message-ID: <handler.19565.B19565.142100121712921 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Kelly Dean <kelly@HIDDEN>
Cc: 19565 <at> debbugs.gnu.org
Reply-To: rms@HIDDEN
Date: Sun, 11 Jan 2015 13:33:34 -0500
Message-Id: <E1YANKQ-0006v8-6Y@HIDDEN>
Content-Type: text/plain; charset=Utf-8
From: Richard Stallman <rms@HIDDEN>
In-reply-to: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local> (message from
 Kelly Dean on Sun, 11 Jan 2015 11:12:00 +0000)
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > A few days ago I speculated, but now I confirmed. It's technically considered a vulnerability, but in Emacs's case it's a minor problem; exploiting it would be more a prank than a real attack.

That is a relief.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#19565: Emacs vulnerable to endless-data attack (minor)
Resent-From: Kelly Dean <kelly@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 11 Jan 2015 21:20:01 +0000
Resent-Message-ID: <handler.19565.B19565.142101116428493 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 19565 <at> debbugs.gnu.org
From: Kelly Dean <kelly@HIDDEN>
In-Reply-To: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
Date: Sun, 11 Jan 2015 21:18:29 +0000
Message-ID: <dXJcMhaCvuo4JeWptrVIHP2ruS6z4KudXFZv9NCYUHO@local>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

If Emacs gets an auto-updater, or even an auto-checker for updates, like some common operating systems and web browsers have, then this bug would become an actual problem, enabling denial-of-service attacks. Since Emacs is an OS, and now a web browser too, it might get an auto-updater or auto-checker.

Even so, it would only enable DOS attacks, nothing more.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19565: Emacs vulnerable to endless-data attack (minor)
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
In-Reply-To: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
Resent-From: Stefan Kangas <stefan@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 06 Oct 2019 03:14:01 +0000
Resent-Message-ID: <handler.19565.B19565.157033163329796 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19565
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: security
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 19565 <at> debbugs.gnu.org
Received: via spool by 19565-submit <at> debbugs.gnu.org id=B19565.157033163329796
          (code B ref 19565); Sun, 06 Oct 2019 03:14:01 +0000
Received: (at 19565) by debbugs.gnu.org; 6 Oct 2019 03:13:53 +0000
Received: from localhost ([127.0.0.1]:45421 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iGwzZ-0007kW-AD
	for submit <at> debbugs.gnu.org; Sat, 05 Oct 2019 23:13:53 -0400
Received: from mail-pf1-f178.google.com ([209.85.210.178]:40827)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <stefankangas@HIDDEN>) id 1iGwzQ-0007k8-Dr
 for 19565 <at> debbugs.gnu.org; Sat, 05 Oct 2019 23:13:51 -0400
Received: by mail-pf1-f178.google.com with SMTP id x127so6298389pfb.7
 for <19565 <at> debbugs.gnu.org>; Sat, 05 Oct 2019 20:13:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc;
 bh=cVCKHJgKUNMjwLgeJp+kj7cbEFBtRI2B77Ezb+x9zKk=;
 b=t2gOIsqquIae4Zz9Eq0e2t2lIJi31sSIEIs32KQ5cRLnfX2I8Kz+4f3zZGsSI6iiuK
 TEp7DYBzIH/eXEPVvy5iWeoO87mM4oNm6vUTMhp6AcGuw8GfO7kKqv5A+lnWV6ipGBI9
 2tZhenHcxnYpNCExxo97EOI+yxsESxSEc6AaSCM/Ssfj8RK4qTejiP0DNqI5yj/srUFI
 y8AqeMpAej6olM76oKMFGJIe7EyM9pgpEjh84exQXJDGjpXTjrwlFVQJPlSwGMAGpD0+
 K9BQAeapdSlSx3t5VyhGLc2dEbW6qW5c3iFt9P1Xg4NqcRrXnw8NhgSyTwyzeSJvGF+d
 7/Rg==
X-Gm-Message-State: APjAAAXu8HADzbzjivbUr9zFH30EZ3yMo83UUVzybf05D+IU8lcP4QR3
 iUYh12ZsvxlAPzZHqep3/Mjmyyybnk/kG/4fPeM=
X-Google-Smtp-Source: APXvYqxBowy186hNLQJYnY1SBm5EMiLjenmd6prYhd3ZCPd4BezUn9QArgAi/uUnpHuvhEzKSsWJVZQCiULY5R6MshY=
X-Received: by 2002:a62:e917:: with SMTP id j23mr25745085pfh.50.1570331618693; 
 Sat, 05 Oct 2019 20:13:38 -0700 (PDT)
MIME-Version: 1.0
From: Stefan Kangas <stefan@HIDDEN>
Date: Sun, 6 Oct 2019 05:13:27 +0200
Message-ID: <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Kelly Dean <kelly@HIDDEN> writes:

> A few days ago I speculated, but now I confirmed. It's technically considered a vulnerability, but in Emacs's case it's a minor problem; exploiting it would be more a prank than a real attack.
>
> To demo locally for archive metadata:
> echo -en 'HTTP/1.1 200 OK\r\n\r\n' > header
> cat header /dev/urandom | nc -l -p 80
>
> Then in Emacs:
> (setq package-archives '(("foo" . "http://127.0.0.1/")))
> M-x list-packages
>
> Watch Emacs's memory usage grow and grow...
>
> If you set some arbitrary limit on the size of archive-contents, then
> theoretically you break some legitimate ginormous elpa. And if you're getting
> garbage, you wouldn't know it until you've downloaded more garbage than the
> limit. The right way to fix it is to include the size of archive-contents in
> another file that can legitimately be constrained to a specified small maximum
> size, sign that file, and in the client, abort the archive-contents download if
> you get more data than you're supposed to.
>
> The timestamp file that I proposed for fixing the metadata replay vuln (bug
> #19479) would be a suitable place to record the size; then no additional file
> (and signature) is needed just to solve endless-metadata. For the corresponding
> endless-data vuln for packages instead of metadata, I already put sizes in the
> package records in my patch for the package replay vuln.
>
> Don't forget you need to set a maximum size not only on the timestamp file, but also on the signature file, or they would be vulnerable too. E.g. just hardcode 1kB.

I think this affects more than just package.el.  AFAICT, anywhere we
use the url library, an endless data attack can get Emacs to fill up
all available memory (wasting also bandwidth resources, of course).

Lars, perhaps we could add code to handle this in with-fetched-url?

For example, a new keyword argument :max-size, which would make it
stop after having reached that many bytes.  IMO, it would be even
better if this was set to some arbitrarily chosen high value by
default, like 256 MiB or something, so that this protection is on
unless explicitly turned off with nil.

Best regards,
Stefan Kangas

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19565: Emacs vulnerable to endless-data attack (minor)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 06 Oct 2019 17:33:01 +0000
Resent-Message-ID: <handler.19565.B19565.157038316831231 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19565
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: security
To: Stefan Kangas <stefan@HIDDEN>
Cc: larsi@HIDDEN, 19565 <at> debbugs.gnu.org
Received: via spool by 19565-submit <at> debbugs.gnu.org id=B19565.157038316831231
          (code B ref 19565); Sun, 06 Oct 2019 17:33:01 +0000
Received: (at 19565) by debbugs.gnu.org; 6 Oct 2019 17:32:48 +0000
Received: from localhost ([127.0.0.1]:46789 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iHAOm-00087d-72
	for submit <at> debbugs.gnu.org; Sun, 06 Oct 2019 13:32:48 -0400
Received: from eggs.gnu.org ([209.51.188.92]:57677)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1iHAOk-00087M-6I
 for 19565 <at> debbugs.gnu.org; Sun, 06 Oct 2019 13:32:46 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:60541)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1iHAOe-0007ob-Vz; Sun, 06 Oct 2019 13:32:41 -0400
Received: from [176.228.60.248] (port=1761 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1iHAOd-00052N-Ti; Sun, 06 Oct 2019 13:32:40 -0400
Date: Sun, 06 Oct 2019 20:32:28 +0300
Message-Id: <83a7ad3hlf.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
 (message from Stefan Kangas on Sun, 6 Oct 2019 05:13:27 +0200)
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
 <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Kangas <stefan@HIDDEN>
> Date: Sun, 6 Oct 2019 05:13:27 +0200
> Cc: 19565 <at> debbugs.gnu.org
> 
> I think this affects more than just package.el.  AFAICT, anywhere we
> use the url library, an endless data attack can get Emacs to fill up
> all available memory (wasting also bandwidth resources, of course).

At which point the system will kill the Emacs process.  Why is that a
problem we need to work, given that we already have at least some
protection against stack overflows and running out of memory?

> For example, a new keyword argument :max-size, which would make it
> stop after having reached that many bytes.

The Gnu Coding Standards frown on having arbitrary limits in a
program.  So this could only work if we had some reasonable way of
computing a limit that is not arbitrary.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19565: Emacs vulnerable to endless-data attack (minor)
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 07 Oct 2019 01:52:02 +0000
Resent-Message-ID: <handler.19565.B19565.157041310310581 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19565
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: security
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Stefan Kangas <stefan@HIDDEN>, 19565 <at> debbugs.gnu.org
Received: via spool by 19565-submit <at> debbugs.gnu.org id=B19565.157041310310581
          (code B ref 19565); Mon, 07 Oct 2019 01:52:02 +0000
Received: (at 19565) by debbugs.gnu.org; 7 Oct 2019 01:51:43 +0000
Received: from localhost ([127.0.0.1]:47041 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iHIBa-0002kb-JB
	for submit <at> debbugs.gnu.org; Sun, 06 Oct 2019 21:51:42 -0400
Received: from quimby.gnus.org ([80.91.231.51]:53178)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1iHIBY-0002kS-M7
 for 19565 <at> debbugs.gnu.org; Sun, 06 Oct 2019 21:51:41 -0400
Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie)
 by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.89) (envelope-from <larsi@HIDDEN>)
 id 1iHIBT-0003uP-M7; Mon, 07 Oct 2019 03:51:38 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
 <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
 <83a7ad3hlf.fsf@HIDDEN>
Date: Mon, 07 Oct 2019 03:51:35 +0200
In-Reply-To: <83a7ad3hlf.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 06 Oct
 2019 20:32:28 +0300")
Message-ID: <874l0le314.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview: Eli Zaretskii <eliz@HIDDEN> writes: >> I think this affects
 more than just package.el. AFAICT, anywhere we >> use the url library, an
 endless data attack can get Emacs to fill up >> all available memory (wasting
 also bandwidth resources [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

>> I think this affects more than just package.el.  AFAICT, anywhere we
>> use the url library, an endless data attack can get Emacs to fill up
>> all available memory (wasting also bandwidth resources, of course).
>
> At which point the system will kill the Emacs process.  Why is that a
> problem we need to work, given that we already have at least some
> protection against stack overflows and running out of memory?

It's not something we have to do, but it would be nice to have some
protection against this.

>> For example, a new keyword argument :max-size, which would make it
>> stop after having reached that many bytes.
>
> The Gnu Coding Standards frown on having arbitrary limits in a
> program.  So this could only work if we had some reasonable way of
> computing a limit that is not arbitrary.

I think it would perhaps make some sense to warn (or query) the user if
you get more data than `large-file-warning-threshold'.  I think it would
be pretty trivial to implement -- at least in the new with-fetched-url
interface, which I think is where this pretty theoretical problem is
least theoretical, perhaps?

On the other hand, I could see that in some ways it would be easier to
implement in wait_reading_process_output: We could just maintain a byte
counter in the process objects (if we don't do that already) and have a
callback we call if that counter grows larger than
`large-file-warning-threshold'.

That way Emacs wouldn't be open to flooding from, say, rogue SMTP
servers, either.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19565: Emacs vulnerable to endless-data attack (minor)
Resent-From: Stefan Kangas <stefan@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 07 Oct 2019 12:52:01 +0000
Resent-Message-ID: <handler.19565.B19565.157045266130678 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19565
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: security
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 19565 <at> debbugs.gnu.org
Received: via spool by 19565-submit <at> debbugs.gnu.org id=B19565.157045266130678
          (code B ref 19565); Mon, 07 Oct 2019 12:52:01 +0000
Received: (at 19565) by debbugs.gnu.org; 7 Oct 2019 12:51:01 +0000
Received: from localhost ([127.0.0.1]:47455 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iHSTd-0007yY-Du
	for submit <at> debbugs.gnu.org; Mon, 07 Oct 2019 08:51:01 -0400
Received: from mail-pl1-f172.google.com ([209.85.214.172]:44944)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <stefankangas@HIDDEN>) id 1iHSTa-0007yF-QN
 for 19565 <at> debbugs.gnu.org; Mon, 07 Oct 2019 08:50:59 -0400
Received: by mail-pl1-f172.google.com with SMTP id q15so6807443pll.11
 for <19565 <at> debbugs.gnu.org>; Mon, 07 Oct 2019 05:50:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=B/99XR5MTyBZGSZPFZ2DXiEoRXS2qCqMMGm/XtgyHFQ=;
 b=IxDjsyGoUz+JKfphVpooZ0tmLPd4Wfg2VW4BPhHmFPDvDG7azq5WyGZ4yHAN0ySeaL
 W8qSbfEj5HULS0ZSMs4rrKtD5/dCP7DK4XrZjfuGipcYRIRRHATh6PMTGny1W67JgFOn
 Q1yK3EuaBuxgGbk8+eQYcQa0Xu2qlKGTxjGLEmINAvsy2PPSWof6ZD81o9JHmbW3+cOF
 0/LdtKegyH6ikggCXa4KnNZRjMVazTefun6uJlB9v9rMpNVCS081R/+jnhxv6wSOYLp3
 T7n1y6OO6kJzRCuHI3jimH+eoY0Xc5OBINgpOsFj9ZS8UiZuNpXVC+RMB30t9YubZB21
 ZtOg==
X-Gm-Message-State: APjAAAUVjIYHyXwqeuczHDPh6nUZNQRJShUr6z2ift8VmrZSFOu+gCNx
 GC1jH6Epzv+9d3KpOaHsYtx+ivbJBm/do8yBJs8=
X-Google-Smtp-Source: APXvYqz7ZDi+h8MjZNW1387veNdrhwA1LjENbGkM7O8jrwCMxX58UGk+72Tlv23+LmjCfbBecOI40MpXLh+h4WjCqTM=
X-Received: by 2002:a17:902:326:: with SMTP id
 35mr30189600pld.128.1570452652980; 
 Mon, 07 Oct 2019 05:50:52 -0700 (PDT)
MIME-Version: 1.0
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
 <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
 <83a7ad3hlf.fsf@HIDDEN> <874l0le314.fsf@HIDDEN>
In-Reply-To: <874l0le314.fsf@HIDDEN>
From: Stefan Kangas <stefan@HIDDEN>
Date: Mon, 7 Oct 2019 14:50:41 +0200
Message-ID: <CADwFkmn4-ZfxyacpZua7fjE4P0dM_MKbTGPJjmK0rfrVgejRGw@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Lars Ingebrigtsen <larsi@HIDDEN> writes:

> It's not something we have to do, but it would be nice to have some
> protection against this.

This is my view, too.  And don't we usually treat a potential crash as
a bug to be fixed?

> I think it would perhaps make some sense to warn (or query) the user if
> you get more data than `large-file-warning-threshold'.  I think it would
> be pretty trivial to implement -- at least in the new with-fetched-url
> interface, which I think is where this pretty theoretical problem is
> least theoretical, perhaps?

Not sure if it's practical, but perhaps we could initialize the
threshold depending on the available memory.

> On the other hand, I could see that in some ways it would be easier to
> implement in wait_reading_process_output: We could just maintain a byte
> counter in the process objects (if we don't do that already) and have a
> callback we call if that counter grows larger than
> `large-file-warning-threshold'.
>
> That way Emacs wouldn't be open to flooding from, say, rogue SMTP
> servers, either.

If we can have a more general protection, that would be even better,
in my view.  Are there any drawbacks to such a solution?

Best regards,
Stefan Kangas

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19565: Emacs vulnerable to endless-data attack (minor)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 07 Oct 2019 16:14:01 +0000
Resent-Message-ID: <handler.19565.B19565.157046481117898 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19565
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: security
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: stefan@HIDDEN, 19565 <at> debbugs.gnu.org
Received: via spool by 19565-submit <at> debbugs.gnu.org id=B19565.157046481117898
          (code B ref 19565); Mon, 07 Oct 2019 16:14:01 +0000
Received: (at 19565) by debbugs.gnu.org; 7 Oct 2019 16:13:31 +0000
Received: from localhost ([127.0.0.1]:48965 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iHVdb-0004ea-7o
	for submit <at> debbugs.gnu.org; Mon, 07 Oct 2019 12:13:31 -0400
Received: from eggs.gnu.org ([209.51.188.92]:47569)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1iHVdY-0004eM-JX
 for 19565 <at> debbugs.gnu.org; Mon, 07 Oct 2019 12:13:29 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:53100)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1iHVdT-0001q4-4x; Mon, 07 Oct 2019 12:13:23 -0400
Received: from [176.228.60.248] (port=4915 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1iHVdO-0008M7-6u; Mon, 07 Oct 2019 12:13:20 -0400
Date: Mon, 07 Oct 2019 19:13:11 +0300
Message-Id: <831rvo1qlk.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <874l0le314.fsf@HIDDEN> (message from Lars Ingebrigtsen on Mon, 
 07 Oct 2019 03:51:35 +0200)
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
 <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
 <83a7ad3hlf.fsf@HIDDEN> <874l0le314.fsf@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Lars Ingebrigtsen <larsi@HIDDEN>
> Cc: Stefan Kangas <stefan@HIDDEN>,  19565 <at> debbugs.gnu.org
> Date: Mon, 07 Oct 2019 03:51:35 +0200
> 
> I think it would perhaps make some sense to warn (or query) the user if
> you get more data than `large-file-warning-threshold'.  I think it would
> be pretty trivial to implement -- at least in the new with-fetched-url
> interface, which I think is where this pretty theoretical problem is
> least theoretical, perhaps?
> 
> On the other hand, I could see that in some ways it would be easier to
> implement in wait_reading_process_output: We could just maintain a byte
> counter in the process objects (if we don't do that already) and have a
> callback we call if that counter grows larger than
> `large-file-warning-threshold'.

I think this must be in terms of bytes/sec, not just bytes.  E.g., I
have a spell-checker active during my entire Emacs session (which
could go on for weeks and months on end), and I don't want to get a
prompt just because the number of bytes that went in that pipe becomes
above the threshold.  We may also need to measure the growth of the
Emacs memory footprint during that time, because if Emacs reads bytes
and discards them, it isn't going to be a problem, right?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19565: Emacs vulnerable to endless-data attack (minor)
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 08 Oct 2019 16:28:02 +0000
Resent-Message-ID: <handler.19565.B19565.157055204225813 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19565
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: security
To: Eli Zaretskii <eliz@HIDDEN>
Cc: stefan@HIDDEN, 19565 <at> debbugs.gnu.org
Received: via spool by 19565-submit <at> debbugs.gnu.org id=B19565.157055204225813
          (code B ref 19565); Tue, 08 Oct 2019 16:28:02 +0000
Received: (at 19565) by debbugs.gnu.org; 8 Oct 2019 16:27:22 +0000
Received: from localhost ([127.0.0.1]:51323 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iHsKY-0006iG-F3
	for submit <at> debbugs.gnu.org; Tue, 08 Oct 2019 12:27:22 -0400
Received: from quimby.gnus.org ([80.91.231.51]:39376)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1iHsKW-0006i8-A4
 for 19565 <at> debbugs.gnu.org; Tue, 08 Oct 2019 12:27:21 -0400
Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie)
 by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.89) (envelope-from <larsi@HIDDEN>)
 id 1iHsKS-0007M0-7U; Tue, 08 Oct 2019 18:27:18 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
 <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
 <83a7ad3hlf.fsf@HIDDEN> <874l0le314.fsf@HIDDEN>
 <831rvo1qlk.fsf@HIDDEN>
Date: Tue, 08 Oct 2019 18:27:15 +0200
In-Reply-To: <831rvo1qlk.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 07 Oct
 2019 19:13:11 +0300")
Message-ID: <87zhibyzh8.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview: Eli Zaretskii <eliz@HIDDEN> writes: > I think this must be
 in terms of bytes/sec, not just bytes. E.g., I > have a spell-checker active
 during my entire Emacs session (which > could go on for weeks and months
 on end), and I don't want t [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

> I think this must be in terms of bytes/sec, not just bytes.  E.g., I
> have a spell-checker active during my entire Emacs session (which
> could go on for weeks and months on end), and I don't want to get a
> prompt just because the number of bytes that went in that pipe becomes
> above the threshold.  We may also need to measure the growth of the
> Emacs memory footprint during that time, because if Emacs reads bytes
> and discards them, it isn't going to be a problem, right?

Yeah, that's true -- a counter wouldn't help at all here.

Would checking the size of the `process-buffer' of the process be more
helpful?  It might be a somewhat unnatural thing to do -- Emacs doesn't
give you a warning if you say

(dotimes (i 100000000) (insert (make-string 80 ?a)))

so perhaps that's not a good heuristic, either.

So bytes/sec, as you suggest, may be the best heuristic.  But it should
only kick in after having received a large number of bytes, probably.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19565: Emacs vulnerable to endless-data attack (minor)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 08 Oct 2019 16:49:02 +0000
Resent-Message-ID: <handler.19565.B19565.15705532923562 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19565
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: security
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: stefan@HIDDEN, 19565 <at> debbugs.gnu.org
Received: via spool by 19565-submit <at> debbugs.gnu.org id=B19565.15705532923562
          (code B ref 19565); Tue, 08 Oct 2019 16:49:02 +0000
Received: (at 19565) by debbugs.gnu.org; 8 Oct 2019 16:48:12 +0000
Received: from localhost ([127.0.0.1]:51387 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iHsei-0000vO-Aa
	for submit <at> debbugs.gnu.org; Tue, 08 Oct 2019 12:48:12 -0400
Received: from eggs.gnu.org ([209.51.188.92]:35937)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1iHseg-0000v9-Fx
 for 19565 <at> debbugs.gnu.org; Tue, 08 Oct 2019 12:48:10 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:46735)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1iHseY-0004EC-42; Tue, 08 Oct 2019 12:48:03 -0400
Received: from [176.228.60.248] (port=4378 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1iHseR-0006C5-VQ; Tue, 08 Oct 2019 12:47:59 -0400
Date: Tue, 08 Oct 2019 19:47:54 +0300
Message-Id: <83wodfw5dx.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <87zhibyzh8.fsf@HIDDEN> (message from Lars Ingebrigtsen on Tue, 
 08 Oct 2019 18:27:15 +0200)
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
 <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
 <83a7ad3hlf.fsf@HIDDEN> <874l0le314.fsf@HIDDEN>
 <831rvo1qlk.fsf@HIDDEN> <87zhibyzh8.fsf@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Lars Ingebrigtsen <larsi@HIDDEN>
> Cc: stefan@HIDDEN,  19565 <at> debbugs.gnu.org
> Date: Tue, 08 Oct 2019 18:27:15 +0200
> 
> So bytes/sec, as you suggest, may be the best heuristic.  But it should
> only kick in after having received a large number of bytes, probably.

Yes, I agree.  So maybe make it kick in once the process buffer is
large enough?  And even here we will need to consider, say, shell and
term.el buffers, which could grow quite large.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19565: Emacs vulnerable to endless-data attack (minor)
Resent-From: Stefan Kangas <stefan@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 08 Oct 2019 16:51:02 +0000
Resent-Message-ID: <handler.19565.B19565.15705534423805 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19565
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: security
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 19565 <at> debbugs.gnu.org
Received: via spool by 19565-submit <at> debbugs.gnu.org id=B19565.15705534423805
          (code B ref 19565); Tue, 08 Oct 2019 16:51:02 +0000
Received: (at 19565) by debbugs.gnu.org; 8 Oct 2019 16:50:42 +0000
Received: from localhost ([127.0.0.1]:51391 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iHsh7-0000zI-RF
	for submit <at> debbugs.gnu.org; Tue, 08 Oct 2019 12:50:42 -0400
Received: from mail-pg1-f179.google.com ([209.85.215.179]:38394)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <stefankangas@HIDDEN>) id 1iHsh5-0000z4-LC
 for 19565 <at> debbugs.gnu.org; Tue, 08 Oct 2019 12:50:39 -0400
Received: by mail-pg1-f179.google.com with SMTP id x10so10561992pgi.5
 for <19565 <at> debbugs.gnu.org>; Tue, 08 Oct 2019 09:50:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=Tgr6jf8dpCM9V5gjAaAqYly3gWMIgw0+qhReVOepk2A=;
 b=X1ptRFUDvdUOD4ZpGX603XCLuqntz8sUWGmThjzYHIjY0VRzs1jWmVWWsO4KFAWx/4
 Ki6spizXB8svnJboI29pvVhIKO3WtKuL54UtcKGE92BcsQTUqu1awC+v5m/Cj/7dlkL5
 /Hhv66bqi+bb1J00XXlDcQIYWuyf0e5xjDPBYWiB4rYsJv7LjgXjD+72NR/gXfBcr+CU
 ZrQjzpS+hTqfTiwcB3UXosq4nON1Kn3EkdQwdaZ3JFxkoJhvIwuIvzqe/wnQU1pY84zZ
 V/wGllc3i6+GNCpTbvED/CgPL50jePBaL2b23EuoPr5OzrStmr0K5H/h+d655obDavcJ
 YgkQ==
X-Gm-Message-State: APjAAAU0crqlf7xRcgzaARWTQH7UAMUDD6xfI6dUel4TQrMAJ76SX0X+
 oODHgH2cDzDqDRDjjHHQ7CpezFuGhTQ4BHLZCGs=
X-Google-Smtp-Source: APXvYqyN/i9d8+6p/wKutkj2BlE5Als7kXaKLh+JhPLayQTyWO0UF4o0CoenGZd9qJ428DNOhnEakSm0v1Cz15kViUU=
X-Received: by 2002:a63:1310:: with SMTP id i16mr34861166pgl.200.1570553433663; 
 Tue, 08 Oct 2019 09:50:33 -0700 (PDT)
MIME-Version: 1.0
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
 <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
 <83a7ad3hlf.fsf@HIDDEN> <874l0le314.fsf@HIDDEN> <831rvo1qlk.fsf@HIDDEN>
 <87zhibyzh8.fsf@HIDDEN>
In-Reply-To: <87zhibyzh8.fsf@HIDDEN>
From: Stefan Kangas <stefan@HIDDEN>
Date: Tue, 8 Oct 2019 18:50:22 +0200
Message-ID: <CADwFkmnP4+c=o5B5eQ9hVtOciURv_tsKBTTC3=JJzrVMv8K=8A@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Lars Ingebrigtsen <larsi@HIDDEN> writes:

> So bytes/sec, as you suggest, may be the best heuristic.  But it should
> only kick in after having received a large number of bytes, probably.

Maybe this is a stupid question, but what if I'm on a slow connection?
 Then I would never hit the max?  Emacs does have users also in areas
of the world where the connections are generally slow, but where AFAIK
in addition to that they may have to pay for data.  Also consider the
use case of a user from the developed world currently on data roaming,
with a maximum of 100 MiB of free data...

I'm not against the bytes/sec idea, and maybe I don't understand it
well enough, but I also think there is a case for being able to
specify a maximum number of bytes for a particular connection.  For
example, the "archive-contents" file is never that big unless
something is seriously wrong.  The MELPA "archive-contents" file is
probably one of the biggest examples in use today and currently weighs
in at 1,433,186 bytes.  This means that a maximum of, say, 128 MiB
should be extremely generous in this case, also allowing for it to
grow quite a lot in the next decade or so.

Best regards,
Stefan Kangas

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19565: Emacs vulnerable to endless-data attack (minor)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 08 Oct 2019 17:23:02 +0000
Resent-Message-ID: <handler.19565.B19565.157055533414870 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19565
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: security
To: Stefan Kangas <stefan@HIDDEN>
Cc: larsi@HIDDEN, 19565 <at> debbugs.gnu.org
Received: via spool by 19565-submit <at> debbugs.gnu.org id=B19565.157055533414870
          (code B ref 19565); Tue, 08 Oct 2019 17:23:02 +0000
Received: (at 19565) by debbugs.gnu.org; 8 Oct 2019 17:22:14 +0000
Received: from localhost ([127.0.0.1]:51427 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iHtBd-0003rm-LT
	for submit <at> debbugs.gnu.org; Tue, 08 Oct 2019 13:22:13 -0400
Received: from eggs.gnu.org ([209.51.188.92]:40699)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1iHtBc-0003rZ-Pg
 for 19565 <at> debbugs.gnu.org; Tue, 08 Oct 2019 13:22:13 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:47247)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1iHtBV-0004SY-Q9; Tue, 08 Oct 2019 13:22:07 -0400
Received: from [176.228.60.248] (port=2473 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1iHtBU-0000tA-Uk; Tue, 08 Oct 2019 13:22:05 -0400
Date: Tue, 08 Oct 2019 20:22:02 +0300
Message-Id: <83tv8jw3t1.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CADwFkmnP4+c=o5B5eQ9hVtOciURv_tsKBTTC3=JJzrVMv8K=8A@HIDDEN>
 (message from Stefan Kangas on Tue, 8 Oct 2019 18:50:22 +0200)
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
 <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
 <83a7ad3hlf.fsf@HIDDEN> <874l0le314.fsf@HIDDEN> <831rvo1qlk.fsf@HIDDEN>
 <87zhibyzh8.fsf@HIDDEN>
 <CADwFkmnP4+c=o5B5eQ9hVtOciURv_tsKBTTC3=JJzrVMv8K=8A@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Kangas <stefan@HIDDEN>
> Date: Tue, 8 Oct 2019 18:50:22 +0200
> Cc: Eli Zaretskii <eliz@HIDDEN>, 19565 <at> debbugs.gnu.org
> 
> Lars Ingebrigtsen <larsi@HIDDEN> writes:
> 
> > So bytes/sec, as you suggest, may be the best heuristic.  But it should
> > only kick in after having received a large number of bytes, probably.
> 
> Maybe this is a stupid question, but what if I'm on a slow connection?

Please define "slow" in terms of bytes/sec.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19565: Emacs vulnerable to endless-data attack (minor)
Resent-From: Stefan Kangas <stefan@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 08 Oct 2019 17:39:01 +0000
Resent-Message-ID: <handler.19565.B19565.157055633924448 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19565
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: security
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Lars Ingebrigtsen <larsi@HIDDEN>, 19565 <at> debbugs.gnu.org
Received: via spool by 19565-submit <at> debbugs.gnu.org id=B19565.157055633924448
          (code B ref 19565); Tue, 08 Oct 2019 17:39:01 +0000
Received: (at 19565) by debbugs.gnu.org; 8 Oct 2019 17:38:59 +0000
Received: from localhost ([127.0.0.1]:51457 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iHtRr-0006MG-63
	for submit <at> debbugs.gnu.org; Tue, 08 Oct 2019 13:38:59 -0400
Received: from mail-pg1-f176.google.com ([209.85.215.176]:43046)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <stefankangas@HIDDEN>) id 1iHtRp-0006M3-Dk
 for 19565 <at> debbugs.gnu.org; Tue, 08 Oct 2019 13:38:57 -0400
Received: by mail-pg1-f176.google.com with SMTP id i32so3330156pgl.10
 for <19565 <at> debbugs.gnu.org>; Tue, 08 Oct 2019 10:38:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=H8oT1MJomHUr/jGE1OCFSn2kcg5EIYYEdQxXsDCgRe4=;
 b=NH8Xg5qZcIuRmDEoe4e7Nx0BRTO8ZX9jzLaQjVY/8JYHqRO40Gm2jUJOyeyXuUplfI
 ZtrdaF+VRoMei3/CagvVkeKharrw99xS6dbGWB94yeeK5wI2mbQi1mSaHMHxr/crc/8g
 5bsumWgzbLQtfKL3bO0zUvM/l0ZstUdfHkk/D1q2SPBhRmt/iqxuoBxHYTNFb0lDsGt8
 TkKdBDBqAN/AaH0LuGXffj8XVwu436F8sRSa2ssRRrHJbzKfo/lAGpwVqlT1bRXnqlRb
 fJX5uHouE72tyXrOv5lSTiWzzJDtqlebmTX4/bCtno+f/Golv91JKMppDusW/V7SiFAj
 8QRQ==
X-Gm-Message-State: APjAAAVLfm1GAA3jDFz+I/CZOKaBNbGT3Gm6hVeevYVR2yQK9sgM/cy9
 76seOc+JEr+9Whj00eAD7RAu5BeILTfsHyWe+H0=
X-Google-Smtp-Source: APXvYqwFrIzZSKEfaV+Oa58Xe6k8WCIbgiwYwL+JYtYX6SvYdYWxQZJev1rUydUpvri+p6uOTZC5dMosJsgXo7mfjSQ=
X-Received: by 2002:aa7:8009:: with SMTP id j9mr39737793pfi.107.1570556331540; 
 Tue, 08 Oct 2019 10:38:51 -0700 (PDT)
MIME-Version: 1.0
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
 <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
 <83a7ad3hlf.fsf@HIDDEN> <874l0le314.fsf@HIDDEN> <831rvo1qlk.fsf@HIDDEN>
 <87zhibyzh8.fsf@HIDDEN>
 <CADwFkmnP4+c=o5B5eQ9hVtOciURv_tsKBTTC3=JJzrVMv8K=8A@HIDDEN>
 <83tv8jw3t1.fsf@HIDDEN>
In-Reply-To: <83tv8jw3t1.fsf@HIDDEN>
From: Stefan Kangas <stefan@HIDDEN>
Date: Tue, 8 Oct 2019 19:38:40 +0200
Message-ID: <CADwFkmmsqNEKCPxTOgZuASHJEAtrZW8GXGW1naJ97HGuhRQDzQ@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Eli Zaretskii <eliz@HIDDEN> writes:

> > > So bytes/sec, as you suggest, may be the best heuristic.  But it should
> > > only kick in after having received a large number of bytes, probably.
> >
> > Maybe this is a stupid question, but what if I'm on a slow connection?
>
> Please define "slow" in terms of bytes/sec.

- 56 kbps dialup is 7000 bytes/sec.
- 2G cellular network is 40 kbps, or 384 kbps, which is 5000 bytes/sec
and 48000 bytes/sec respectively.

These are theoretical maximums.

Best regards,
Stefan Kangas

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19565: Emacs vulnerable to endless-data attack (minor)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 08 Oct 2019 18:03:01 +0000
Resent-Message-ID: <handler.19565.B19565.15705577542009 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19565
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: security
To: Stefan Kangas <stefan@HIDDEN>
Cc: larsi@HIDDEN, 19565 <at> debbugs.gnu.org
Received: via spool by 19565-submit <at> debbugs.gnu.org id=B19565.15705577542009
          (code B ref 19565); Tue, 08 Oct 2019 18:03:01 +0000
Received: (at 19565) by debbugs.gnu.org; 8 Oct 2019 18:02:34 +0000
Received: from localhost ([127.0.0.1]:51466 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iHtoe-0000WI-Gd
	for submit <at> debbugs.gnu.org; Tue, 08 Oct 2019 14:02:32 -0400
Received: from eggs.gnu.org ([209.51.188.92]:46365)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1iHtod-0000TI-7V
 for 19565 <at> debbugs.gnu.org; Tue, 08 Oct 2019 14:02:31 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:48482)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1iHtoX-0002H1-D3; Tue, 08 Oct 2019 14:02:25 -0400
Received: from [176.228.60.248] (port=4917 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1iHtoW-0004Zl-Kx; Tue, 08 Oct 2019 14:02:25 -0400
Date: Tue, 08 Oct 2019 21:02:22 +0300
Message-Id: <83r23nw1xt.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CADwFkmmsqNEKCPxTOgZuASHJEAtrZW8GXGW1naJ97HGuhRQDzQ@HIDDEN>
 (message from Stefan Kangas on Tue, 8 Oct 2019 19:38:40 +0200)
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
 <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
 <83a7ad3hlf.fsf@HIDDEN> <874l0le314.fsf@HIDDEN> <831rvo1qlk.fsf@HIDDEN>
 <87zhibyzh8.fsf@HIDDEN>
 <CADwFkmnP4+c=o5B5eQ9hVtOciURv_tsKBTTC3=JJzrVMv8K=8A@HIDDEN>
 <83tv8jw3t1.fsf@HIDDEN>
 <CADwFkmmsqNEKCPxTOgZuASHJEAtrZW8GXGW1naJ97HGuhRQDzQ@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Kangas <stefan@HIDDEN>
> Date: Tue, 8 Oct 2019 19:38:40 +0200
> Cc: Lars Ingebrigtsen <larsi@HIDDEN>, 19565 <at> debbugs.gnu.org
> 
> > > Maybe this is a stupid question, but what if I'm on a slow connection?
> >
> > Please define "slow" in terms of bytes/sec.
> 
> - 56 kbps dialup is 7000 bytes/sec.
> - 2G cellular network is 40 kbps, or 384 kbps, which is 5000 bytes/sec
> and 48000 bytes/sec respectively.

I see no problem with these numbers.  If a process buffer receives
more than some threshold at speed like these or faster, we can prompt
the user.

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.