Hi Timothy,
Thanks a lot for the corrections. I have added them to the document, and
I expanded the list of recommendations for Monotone. More comments below.
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.
Ouch! Hopefully it's not too hard to change this to:
if (error) {
if (server) stop_processing();
if (client) { complain(); die(); }
}
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: [EMAIL PROTECTED] bc552a65085e0e55472b91a2c169af76ce7b1a62
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
Daniel.
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
