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