Return-Path: Delivered-To: apmail-lucene-solr-dev-archive@minotaur.apache.org Received: (qmail 829 invoked from network); 12 Sep 2009 00:38:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 12 Sep 2009 00:38:17 -0000 Received: (qmail 22618 invoked by uid 500); 12 Sep 2009 00:38:16 -0000 Delivered-To: apmail-lucene-solr-dev-archive@lucene.apache.org Received: (qmail 22533 invoked by uid 500); 12 Sep 2009 00:38:16 -0000 Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-dev@lucene.apache.org Delivered-To: mailing list solr-dev@lucene.apache.org Received: (qmail 22523 invoked by uid 99); 12 Sep 2009 00:38:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 12 Sep 2009 00:38:16 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [208.69.42.181] (HELO radix.cryptio.net) (208.69.42.181) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 12 Sep 2009 00:38:08 +0000 Received: by radix.cryptio.net (Postfix, from userid 1007) id 87A6A71C85E; Fri, 11 Sep 2009 17:37:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by radix.cryptio.net (Postfix) with ESMTP id 804F171C85D; Fri, 11 Sep 2009 17:37:47 -0700 (PDT) Date: Fri, 11 Sep 2009 17:37:47 -0700 (PDT) From: Chris Hostetter To: solr-dev@lucene.apache.org, yonik@lucidimagination.com Subject: Re: svn commit: r808988 - in /lucene/solr/trunk: CHANGES.txt src/java/org/apache/solr/request/PHPSerializedResponseWriter.java In-Reply-To: Message-ID: References: <20090828190200.EC177238884C@eris.apache.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Checked: Checked by ClamAV on apache.org : > if the container can't correctly output : > some characters, i see no reason to hide the bug : : Another problem is that it won't reliably break. The bug breaks our : encapsulation (before the patch) and thus the client reads the wrong : number of chars for the string, and who knows what happens after that. : The majority of the time will result in an exception, but it really : depends. This is the type of stuff (buffer underflows / overflows) : that could be used to mess with security too... a carefully crafted : request could inject / change fields in the response and have it look : valid. Isn't that an argument in favor of having an explicit option to control how we do the counting? otherwise we're still at risk of the scenerio i discribed (ie: jetty fixes the byte conversion code, but we're still counting the bytes "wrong" for them) with an explicit option we put control in the hands of the solr admin to decide what's right for them (we can even give them a little shell script to test it with) -Hoss