Re: [Monotone-devel] Monotone Security

[Daniel Carrera]

Zack Weinberg wrote:
> > Never trust a revision that is dated earlier than its parent
>
> is broken both ways: a malicious sender can ensure that all their bad
> revisions are dated later than their parents,

And that's what we want to achieve exactly. I was thinking that it would 
make it easier to delete the bad revisions because you could use a 
"later than <date>" selector. But thinking about it a little bit more, I 
found a way to get around that: The new revisions could be the child of 
very old revisions. So the date really becomes useless as a differentiator.


> More generally, Daniel, you seem to want to put security enforcement
> in the sender of revisions, which you simply can't do in distributed
> systems.

No! Of course not. You can't trust clients. I'm not so naive as to think 
that a malicious attacker won't have a compromised copy of Monotone. In 
the example of the date check, it would be the server that would check 
if the incoming revision had a sensible date.


> All security has to go in the *recipient*, because the
> sender could be completely malicious. 

Of course. Every check I have suggested has been server-side 
(recipient). The client (sender) is completely malicious.


> Are there any writeups of more-or-less-current policy branch thinking
> on the wiki or other convenient place?  We *have* thought about these
> issues at great length, but I'm not sure where to point new people so
> they can get past the simple, obvious, but wrong solutions quickly.

I hope you no longer think that I was hoping to enforce security on the 
client. I don't know what I said that gave you that impression.