lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: svn commit: r808988 - in /lucene/solr/trunk: CHANGES.txt src/java/org/apache/solr/request/PHPSerializedResponseWriter.java
Date Sat, 12 Sep 2009 00:37:47 GMT

: > 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


Mime
View raw message