Re: [Monotone-devel] Monotone Security

[Zack Weinberg]

On Thu, Oct 16, 2008 at 9:56 AM, Daniel Carrera <address@hidden> wrote:
> Zack Weinberg wrote:
>
>> 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.

I used the terms "sender" and "recipient" deliberately; as Ethan says
downthread, the server itself is not a trusted entity in this
architecture.  Or, more precisely, security decisions are intended to
be made at checkout time, not at propagation time.

To motivate this, consider the case where you have multiple variations
on a single project sharing repositories  (There have, for instance,
been several attempts to merge the *BSD userland source tree at least
partially.)  A revision might be trusted by one group's standards and
not trusted by another's; yet you want all revisions to be propagated
among the (no doubt multiple) servers and local repositories, so that
people can inspect those untrusted revisions and decide whether they
want to promote them to trusted.

Projects may *also* want to restrict the set of keys that can push
revisions at all, for copyright and spam protection, but that is
intended to be an entirely separate mechanism.

(And to be clear, most of this is not yet implemented, because of lack
of time plus serious design questions as yet only partially answered
-- Nathaniel was telling me the other week that he thought he had a
proper calculus of trust finally, but the algorithm was
exponential...)

Make more sense now?

zw