Return-Path: <tiff-bounces@lists.maptools.org>
Delivered-To: info@awaresystems.be
Received: (qmail 8205 invoked from network); 1 Sep 2008 15:35:02 -0000
Received: from jack.telenet-ops.be ([195.130.136.5])
          (envelope-sender <tiff-bounces@lists.maptools.org>)
          by angelia.telenet-ops.be (qmail-ldap-1.03) with SMTP
          for <info@awaresystems.be>; 1 Sep 2008 15:35:02 -0000
Received: from waldo.telenet-ops.be (waldo.telenet-ops.be [195.130.136.10])
	by jack.telenet-ops.be (8.13.1/8.13.1) with ESMTP id m81FZ1nD003357
	for <info@awaresystems.be>; Mon, 1 Sep 2008 17:35:01 +0200
Received: from localhost (localhost.localdomain [127.0.0.1])
	by waldo.telenet-ops.be (Postfix) with SMTP id DD8921C00C
	for <info@awaresystems.be>; Mon,  1 Sep 2008 17:35:01 +0200 (CEST)
Received: from ladon.telenet-ops.be (ladon.telenet-ops.be [195.130.132.50])
	by waldo.telenet-ops.be (Postfix) with ESMTP id D38CD1C00A
	for <info@awaresystems.be>; Mon,  1 Sep 2008 17:35:01 +0200 (CEST)
Received: from duke.maptools.org (r153.dmsolutions.ca [209.217.116.153])
	by ladon.telenet-ops.be (Postfix) with ESMTP id 64221312776
	for <info@awaresystems.be>; Mon,  1 Sep 2008 17:35:01 +0200 (CEST)
Received: from duke.maptools.org (duke.maptools.org [127.0.0.1])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id m81FUimm011828;
	Mon, 1 Sep 2008 11:32:40 -0400
Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com
	[207.106.133.19])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id m81FUfld011825
	for <tiff@lists.maptools.org>; Mon, 1 Sep 2008 11:30:41 -0400
Received: from localhost.localdomain (localhost [127.0.0.1])
	by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id
	56FF55C8A5; Mon,  1 Sep 2008 11:30:40 -0400 (EDT)
Received: from [192.168.2.4] (dpc674728121.direcpc.com [67.47.28.121]) (using
	TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client
	certificate
	requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA
	id 3A0D35C89D; Mon,  1 Sep 2008 11:30:23 -0400 (EDT)
Message-ID: <48BC0A84.7070502@pobox.com>
Date: Mon, 01 Sep 2008 11:30:12 -0400
From: Frank Warmerdam <warmerdam@pobox.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: [Tiff] Some security fixes from RHEL
References: <200808300053.35585.even.rouault@mines-paris.org>
	<48BAB60F.7040207@pobox.com>
	<Pine.SOC.4.64.0808311028060.1110@freddy.simplesystems.org>
	<48BB143F.4020301@howardsilvan.com> <4983.1220245910@sss.pgh.pa.us>
In-Reply-To: <4983.1220245910@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: EEF4AD00-783A-11DD-A83F-9EE598D589B0-06493634!a-sasl-fastnet.pobox.com
Cc: tiff@lists.maptools.org
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
X-SpamCatcher-Score: 50 [XX]

Tom Lane wrote:
> As maintainer of Red Hat's libtiff package, I am now seriously wondering
> whether I must recommend that Red Hat disable TIFF support in any
> application that has any internet exposure.  

Tom,

Well, thats your call I suppose, though I'd hope you would also balance
such a decision against the lost utility.  I do think it would be foolish
for something like firefox to automatically use libtiff to read and attempt
to display TIFF files embedded as images on web sites.  At the very least
users ought to be making a trust-decision for web sourced TIFF files before
they are opened.

Likewise, I would seriously consider not automatically accessing TIFF files
and offering cute little previews on desktops by default, though at least
in these situations the user has presumably deliberately choosen to download
the image and save it to their file system.

 > My rough estimate is that
> the number of packages that would continue to support TIFF after such a
> recommendation would be zero.  libtiff would become an instant pariah.
 >
> I realize that hardening libtiff is likely to be a long and tedious
> process.  But I think failing to accept that you've got to do it is
> a good way to kill the project.

The point is that Bob, Joris, Andrey and myself have very limited
amounts of time to apply to libtiff maintenance and we have a hard
time keeping up with existing routine maintenance.  We do not generally
have the skills required for a serious security audit of libtiff.

So, either folks who care about the security issues will need to step
forward and take on the task as libtiff co-maintainers, or else it is
not going to happen.

Frankly, TIFF will not become a pariah in my community of use so the
issue isn't all that pressing for me.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
