On Sun, Nov 20, 2011 at 1:54 AM, Alex Besogonov <[email protected]> wrote: > On Thu, Nov 17, 2011 at 5:57 PM, Randall Leeds <[email protected]> > wrote: >> On Wed, Nov 16, 2011 at 09:46, Alex Besogonov <[email protected]> >> wrote: >>> On Tue, Nov 15, 2011 at 4:23 PM, Randall Leeds <[email protected]> >>> wrote: > [skip] >> I hope that settles the "why", reassures any >> "oh-my-god-my-couch-is-vulnerable", and motivates the >> "hey-lets-make-a-patch" if you still want the feature, with the >> understanding that it's unlikely the project will specify this as a >> necessary condition for general-purpose replication. If you have more >> bullet-proof needs, dev that armor up and I'll review it, but I'd >> advise making it a config option. > Well, I'm currently trying to replicate Couch DB behavior exactly, but > I'm slowly moving > towards 'hey, I'll just write a patch' stage. However, I like an idea > of waiting for SHA-3 > competition to finish since it give me more time :) >
Just a note, but remember that you should be able to use sha-8billion in your replicator and it'd work fine with CouchDB (and if it doesn't, its a bug in CouchDB that we'd want to fix). The replicator/revision mechanism is written so that once generated, the _rev tokens are opaque and the only tests used are equality comparisons. HTH, Paul Davis >>> >>>> Then, if I understand Jason >>>> correctly, we're also talking about a situation where Couch B is >>>> insecure... it's allowing a malicious user to change documents. If >>>> these documents are anything more important than something affecting >>>> the user herself then what you have is a malicious administrator or an >>>> insecure deployment. I don't think MD5 is to blame here. >>> No, the issue here is a possibility to break the synchronization. >>> >>>> Does that sound like a reasonable assessment to you, Alex? >>> Almost. >>> >>>> Also, I'd love to hear about your C++ replicator as it develops. >>> Sure, I'm developing a very small and fast embedded storage for mobile >>> devices and desktop apps. It'll be open source once I finish its core. >>> >>>> -Randall >>>> >>>>> For switching from MD5 to SHA-1, I say no. If we switch, let's use >>>>> something contemporary like SHA-256. Better yet, let's wait for the >>>>> winner of the SHA-3 competition. >>>>> >>>>> B. >>>>> >>>>> On 15 November 2011 07:57, Jason Smith <[email protected]> wrote: >>>>>> On Tue, Nov 15, 2011 at 7:34 AM, Alex Besogonov >>>>>> <[email protected]> wrote: >>>>>>>>> Now I make a change to 'Doc' at machine A. This creates a new revid >>>>>>>>> with new md5 hash. >>>>>>>>> A malicious software somehow learns about this update and creates >>>>>>>>> another document >>>>>>>>> on machine B, contriving it so to make the resulting hash to be the >>>>>>>>> same as on machine A. >>>>>>>> Before going any further, you must show why we care about the contents >>>>>>>> of machine B. >>>>>>>> Why would I log in to machine B if I do not trust B's owner? Why would >>>>>>>> I clone your Git repository if I do not know you? >>>>>>> The problem is, MD5 hash depends on _untrusted_ data that external >>>>>>> processes might put into the database. >>>>>>> >>>>>>> For example, imagine that machines A and B use CouchDB to store >>>>>>> certificates. >>>>>> >>>>>> I ask again. >>>>>> >>>>>> -- >>>>>> Iris Couch >>>>>> >>>>> >>>> >>> >> >
