The tweak to expose the md5 of the attachment is easy, but md5 is broken for this purpose. It's fine to detect corruption, but you shouldn't sign md5 values any more.
B. On Sat, Aug 21, 2010 at 6:31 PM, J Chris Anderson <[email protected]> wrote: > > On Aug 21, 2010, at 12:45 AM, sgoto wrote: > >> On Sat, Aug 21, 2010 at 12:43 AM, sgoto <[email protected]> wrote: >> >>> as far as i can understand, validation functions can't change either, >>> unless all previous documents get reapplied the same validation function, or >>> else replication will create a non-backward compatible merging conflict to >>> be resolved. > > yes, validation functions are not retroactive. furthermore, each user is in > charge of her own validation functions, so some intermediate nodes may choose > not to validate. > >>> >>> the way i'm trying to solve this problem is having each database have one >>> immutable validation rule: each document needs to be signed by a >>> per-database-constant-public-key or by a PGP certificate signed by that >>> public key (1 level of transitive trust, alla web of trust). > > why not just ensure that it is signed by any well-formed key? (in my model > each user has a key, and you might input a message on your localhost, that > replicates via N hops, to eventually reach my localhost, at which point I > know the signature applies cleanly, so all I need to do is decide if I trust > the key). > >>> >>> does that make sense ? >>> >>> >> >> ah, one more question: does validation functions have access to the binary >> data of attachments ? how can i make sure that the attachments are also >> signed ? >> > > no, attachments are not sent to the JS process. however, there is a ticket > out, for including the md5 checksum of the attachment as part of the > attachment stub. in that case, the md5 hash could be signed as well. > > Chris
