acmeattic-devel team mailing list archive

[Aditya Manthramurthy <aditya.mmy@xxxxxxxxx>]

On Sunday 04 July 2010 09:29 AM, Karthik Swaminathan Nagaraj wrote:
> The server software is responsible for maintaining the revisions.
>
>     * A request for a certain revision is processed at the server and
>       the final file is sent to the client.
>     * Similarly, the server periodically needs to perform maintenance
>       on the stored revisions, so that it can support operations to
>       discard unwanted intermediate revisions. (Like what we discussed
>       already. A file that is more than a week old need not have daily
>       revisions stored - these can be merged into a single revision
>       for the week).
>
> For the server to process these locally, it should be able to decrypt 
> the content safely. (These operations can definitely be achieved by 
> transferring enough data to the client but that is too costly for the 
> network).
> If the server is trusted, it can decrypt these files at runtime and 
> store them in-memory. After finishing with the file, the memory is 
> just freed (or even erased for the paranoid people).
I think revisioning can be implemented on top of the encrypted text. 
Since most diff libs are line based, we can preserve newlines in the 
files (i.e. do not encrypt them), and use diffs on top of the encrypted 
content. It should still give fairly compact diffs. We could mitigate 
the performance loss from encryption in this way. There are also binary 
diff libraries, though I need to look at them more to understand them. 
These will work even better than the traditional diffs, and let us 
handle even large binary files (that get updated by a user), more or 
less gracefully.

> Also, from the Mercurial documentation, I noticed that it performs 
> different mechanisms on diff and compression for storing and network 
> transmission - runtime decisions are made based on what is found (or 
> predicted) to be optimal.
> Re-encryption can also be performed at the server without 
> client/network involvement.
>
> I have some interesting thoughts and questions myself:
>
>     * Is it possible to verify or sign the authenticity of the server
>       code? (So that the client can trust the server)
Though we can try a few things, I don't think it is possible. A patched 
server s/w can always pretend to be the unpatched s/w because all the 
info required to do so is already available to the server admins. For 
example, doing something like a hash of the server source code, and 
sending the digest to the client, is not only impractical, but the 
server can just pretend to send the right hash code as this can be known 
in advance.

>     * I imagine generating a user's AES key as a hash (SHA256) of his
>       password. This could be securely sent to the server
>       per-transaction, and the server could handle all its operations
>       and 'forget' the user's AES key.
I am not to follow this properly. Each user has an AES key? Or is it the 
file's AES key? The problem of patching the server code still presents 
itself.
>     * Even during the maintenance operations, it could be client
>       initiated. I still do not want the administrator to be able to
>       view *any* file by just logging in to the server.
>
> Does this sell the point that trusting the server to some extent is 
> not so bad?
This clearly needs more discussion. So let's think more.