monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Monotone Security


From: Timothy Brownawell
Subject: Re: [Monotone-devel] Monotone Security
Date: Wed, 15 Oct 2008 21:47:11 +0000

On Wed, 2008-10-15 at 14:40 +0200, Daniel Carrera wrote:
> > 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.
> 
> Is it possible to write a custom get_revision_cert_trust hook that makes 
> a lot of noise when it finds a key that it doesn't know about?
> 
> MTN: WARNING! Unrecognized key in the server:
> MTN:
> MTN: address@hidden bc552a65085e0e55472b91a2c169af76ce7b1a62

Sure, but that only gets triggered when someone using that hook does a
checkout / update that wants to use a revision signed by the bad key. It
would mostly work, but wouldn't be foolproof.

> > 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.
> 
> Is it really that bad? Can't people make a new database like the article 
> suggests?
> 
> mtn db kill_rev_locally <rev-id>
> mtn db init --db=new_db.mtn
> mtn serve --db=old_db.mtn
> mtn --db=new_db.mtn pull localhost 'net.example*'
> <kill mtn serve>
> mv new_db.mtn old_db.mtn

Sure, but *everyone* has to do that, and all at the same time. If
someone forgets, the bad revision comes right back. So the safe way is
to have one person make the change and set the branch epoch (a cookie
that tells netsync to abort if the two sides don't match), and then
everyone else pulls a fresh db from that person. Then if someone with
the bad revision tries to sync they'll get an error message saying the
epoch doesn't match, and maybe they should look into why.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]