Re: [Monotone-devel] Monotone Security

[Timothy Brownawell]

On Tue, 2008-10-14 at 18:12 +0200, Daniel Carrera wrote:
> Hello,
> 
> I have been working on a paper on Monotone's security. I have tried to 
> make it accurate, but I'm sure that there are still errors. But it's 
> probably good enough to merit posting.
> 
> 
> http://daniel.carrera.name/Monotone_Security/
> 
> Yes, it's long. If you want a quick summary, here it is: "Monotone is 
> really good; encrypted archives would make it better".
> 
> I followed David A. Wheeler's criteria for secure SCMs. That is the best 
> impartial standard for SCM security that I know of. If you choose to 
> read some of this and spot some errors, please do let me know. Also, 
> feel free to reuse any of all of this. It's public domain.

Availability
        Anyone with write access can kill the server by sending
        invalid data. Most of our error checking is similar to
        "if (error) { complain(); die(); }".

        A network read error (say, unplugging the client's network
        cable) used to also kill the server in this manner, I don't
        know if that's been fixed.


Outsiders without privileges
        "If an attacker manages to insert a new RSA key into the
        database"... commits with that key will be ignored *IF* everyone
        is using custom get_revision_cert_trust hooks. If anyone uses
        the default hook, they'll only notice if they're paying
        attention. Keys are transferred whenever needed to validate a
        cert that's also being transferred.

        This should improve in the future, but there's no timeline for
        it.

Malicious developers
        "Encumbrance pollution attack"
                Our solution includes "everyone delete your database",
                does this really count as being able to resist such
                attackts? About the only problem you *won't* have is
                independent revisions changing their names the way some
                centralized systems could potentially change revision
                numbers.