couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Second call for objections releasing 0.10
Date Mon, 21 Sep 2009 15:23:21 GMT
On Mon, Sep 21, 2009 at 10:08 AM, Curt Arnold <> wrote:
> On Sep 20, 2009, at 8:06 AM, Noah Slater wrote:
>> Hey,
>> I've been following the first thread, but am unsure where we all stand.
>> This is
>> my second call for objections following our previous discussion. Do we all
>> feel
>> ready to prepare and vote on the 0.10 release now?
>> Thanks,
>> --
>> Noah Slater,
> The "invalid json allowed into CouchDB" thread on
> appears to offer a means of gaming a system to place
> data in a document that would be seen by CouchDB, but could be hidden from
> clients.
> I think the issue needs to be resolved before cutting 0.10.  It does appear
> to be a security issue, but one which the resolution could negatively impact
> some fraction of apps that depended on the behavior.  If we address it
> before 0.10, we could just reject the document as invalid.  As a security
> patch in a 0.10.1 or so, we may feel compelled to try to merge the data to
> preserve the rare app that depended on the function.
> My initial opinion is that any document with multiple occurrences of a
> property should be rejected and it could just be weaved into the patch for
> COUCHDB-345.

As I described in the user@ thread, the status of repeated property
names in JSON is arguable in either direction. I find it a bit of a
stretch to label this a security concern though. I do agree that it
could present some irritating behavior in places, and it theoretically
might be possible to break something somewhere but I'm having a hard
time thinking of something specific to CouchDB that would break.

Attempting to merge fields in JSON automatically is completely out of
the question though. We either allow repeated fields or we don't.
Either behavior is acceptable to me with a couple notes:

Checking for repeated properties is gonna be a bit of a performance
hit in the JSON parser. The Erlang parsers all allow repeated
properties because the underlying structure is a proplist, which is
just a list of key-value tuples. Checking for repeats would either be
a call to one of the proplist normalization functions and checking for
identity or a sort and foldl to check. No idea how much of a hit
that'd be exactly, but I imagine it could be measured for anything
bigger than trivial docs.

Secondly, if we do add this check, we'll have to consider what happens
with databases that already have docs with repeated fields. The
simplest way would be to just keep serving content and reject new
edits. Which is kind of weird. But forcing a dump/reload for *all*
databases for what I would think is a relatively small number of
affected db's seems cumbersome. Perhaps a tool that would dump a db
and determine if it was in offense would be all that's needed.

Paul Davis

Not to future self:

lists:foldl(fun({K, V}, P) when P =/= K -> K end, lists:sort(Props),

That popped into my head. Figured I should write it down before it un pops.

View raw message