Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of curt.arnld@gmail.com
 designates 209.85.210.185 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=D4zrzDbUPDapMv3EFvuUcVtWM2AJ3MqeJk1q0L2Pe0x5IdYdsF40k4wU0ZQToPimyW
         ReJrezISmQYqQNKJIVLpa3z4iDNOmKX9DWc10F/M0l4N4dVbXmlJeApsaiDjS8qNmCjU
         evqeVtDfRnd6kwGTtZR4Jw8opK/EGRtA8RnUQ=
Sender: Curt Arnold <curt.arnld@gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v1076)
Subject: Re: Second call for objections releasing 0.10
From: Curt Arnold <carnold@apache.org>
In-Reply-To: <e282921e0909201448h18e3813br960de58370792f4@mail.gmail.com>
Date: Sun, 20 Sep 2009 18:51:47 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <0C812947-DEF5-4B2D-8DC8-5AD39CF9A46C@apache.org>
References: <20090920130655.GG29736@tumbolia.org>
 <b7cd8ed10909200635r3db6376cp6f073835e28ef59f@mail.gmail.com>
 <e282921e0909201448h18e3813br960de58370792f4@mail.gmail.com>
To: dev@couchdb.apache.org


On Sep 20, 2009, at 4:48 PM, Chris Anderson wrote:
>
> That's the sort of thing that'd get backported for 0.10.1 anyway, so I
> don't think it's a blocker. Also, probably a fairly easy patch.
>
> Chris
>


COUCHDB-345 seemed to get no attention in the last call for objections  
(other than the fix to a unit test that would break if a patch were  
applied).

I believe the problem addressed in the issue that makes every CouchDB  
installation that allows untrusted users to write to the database  
vulnerable.  Also, as far as I know there is not a simple procedure to  
recover a CouchDB that has been wedged by a malicious or unintentional  
insert of a malencoded document.

No one has objected to the badenc1.patch, however I believe the  
performance cost could be reduced by first scanning the incoming byte  
array and only calling xmerl_ucs:from_utf8 on the portion beginning  
with the first byte value >= 0x80.  I'm not confident in my Erlang  
skills yet to think that I know the optimal way of coding that.   
However, I think it would be better to get some fix in than wait for  
an optimal fix.