From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Richard M. Stallman" Newsgroups: gmane.emacs.devel Subject: Re: image size limit? Date: Sun, 16 Oct 2005 13:36:41 -0400 Message-ID: References: <87oe5v7q19.fsf@stupidchicken.com> <87k6giiqh3.fsf@pacem.orebokech.com> <87fyr4w8sh.fsf@stupidchicken.com> <87oe5qiq96.fsf@stupidchicken.com> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1129484296 5020 80.91.229.2 (16 Oct 2005 17:38:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 16 Oct 2005 17:38:16 +0000 (UTC) Cc: romain@orebokech.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 16 19:38:13 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ERCRJ-0006Qk-Ng for ged-emacs-devel@m.gmane.org; Sun, 16 Oct 2005 19:36:54 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ERCRJ-0001n1-5j for ged-emacs-devel@m.gmane.org; Sun, 16 Oct 2005 13:36:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ERCR8-0001mw-8G for emacs-devel@gnu.org; Sun, 16 Oct 2005 13:36:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ERCR7-0001mk-QW for emacs-devel@gnu.org; Sun, 16 Oct 2005 13:36:42 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ERCR7-0001mh-Nb for emacs-devel@gnu.org; Sun, 16 Oct 2005 13:36:41 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ERCR7-0004ZA-Tc for emacs-devel@gnu.org; Sun, 16 Oct 2005 13:36:41 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1ERCR7-0002Lh-47; Sun, 16 Oct 2005 13:36:41 -0400 Original-To: Chong Yidong In-reply-to: <87oe5qiq96.fsf@stupidchicken.com> (message from Chong Yidong on Sat, 15 Oct 2005 14:33:57 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:44134 Archived-At: As for libpng, the png_set_user_limits() function was only added in version 1.0.16rc1, from 2004, so if we use that we'll lose compatibility with older versions. I think it is ok for the new Emacs to use a feature of libpng that is one year old. Would you like to write the code? Perhaps configure should verify that that entry point exists, and call it only if it is available. > At the same time, we implement image width and height limits in > x_create_x_image_and_pixmap, to deal with malicious images that > specify gigantic width and height sizes, even though the file size > isn't that big. > > Will that succeed in handling the problem case we got? It will avoid allocating too much memory in Emacs. Whether libungif tries to allocate too much memory prior to this, depends on the internal implementation of libungif. Worst that could happen is that libungif believes the invalid width and height data, tries to malloc a big chunk of memory, malloc fails, and DGifSlurp() frees the memory and returns with an error, which we catch. I am not sure that is the worst that can happen, but if it does happen, I agree it is better than what happens now. So would you like to implement that?