Delegate API to encode attachments on-disk about couchbase-lite-ios HOT 4 CLOSED

Here's an idea for an API. The idea is that the application registers a block that when called creates an object that knows how to transform data. One transformer object is created for each attachment, and it's passed all the data of the attachment in one or more chunks, and returns the encoded (or decoded) data in chunks.

@protocol CBLAttachmentTransformer : NSObject
/** Transforms the next byte range of an attachment. This method will be called zero of more times, passing in
    contiguous ranges of the attachment data with competed=false, and then once on the last section of the
    data with completed=true. It should output contiguous portions of the encoded data. */
- (NSData*) transformBytes: (NSData*)inputBytes completed: (bool)completed;
@end

/** Returns a new CBLAttachmentTransformer instance that's ready to start encoding or decoding an
    attachment, depending on the setting of the 'encoding' flag. */
typedef id<CBLAttachmentTransformer> (^CBLAttachmentTransformerFactory)(bool encoding);

Somewhere (either globally or on the CBLManager instance) there is a property of type CBLAttachmentTransformerFactory that the application can set to its own block value.

from couchbase-lite-ios.

I would vote to have the SHA-1 digest of the encoded blob not the original.

My reasoning is:

1. I might wish to store the same data encrypted by two different private keys in the same blob store, not possible if the blob key is based on the unencrypted "in the clear" data.

2. Creating the digest from the original unencrypted data opens up the possibility of determining the content of an encrypted blob by comparing the digest with known "in the clear" data. A hacker would have to already have the original data or it's "in the clear" digest, but they could use this information to find out who has a copy of the data even when it is encrypted.

from couchbase-lite-ios.

The only way I got this to work was to hook the API into more places than described above.
-[CBLAttachment body] is one of those places: it has a conditional branch which returns data from straight from a file URL. -getAttachmentForSequence:... looks suspicious too.

from couchbase-lite-ios.

I've just finished implementing database/attachment encryption — see the feature/encryption branch. Encrypting the attachments turned out to be hard because, as mentioned above, there were leaks in the abstraction where callers could discover the attachment file. So I had to do a lot of refactoring in CBLDatabase+Attachments. I didn't add a delegate API, I just implemented the encryption/decryption directly in CBLBlobStore.

from couchbase-lite-ios.