On Thu, Oct 16, 2008 at 9:56 AM, Daniel Carrera <[EMAIL PROTECTED]> 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 _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel