[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Monotone Security
From: |
Zack Weinberg |
Subject: |
Re: [Monotone-devel] Monotone Security |
Date: |
Thu, 16 Oct 2008 11:35:29 -0700 |
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
- Re: [Monotone-devel] Monotone Security, (continued)
- Re: [Monotone-devel] Monotone Security, Nathaniel Smith, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Thomas Keller, 2008/10/17
- Re: [Monotone-devel] Monotone Security, Zack Weinberg, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Ethan Blanton, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/16
- Re: [Monotone-devel] Monotone Security,
Zack Weinberg <=
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Daniel Carosone, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Jack Lloyd, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Markus Wanner, 2008/10/17
- [Monotone-devel] hypothetical - future-dated certs (Re: Monotone Security), Daniel Carosone, 2008/10/19
- [Monotone-devel] Re: hypothetical - future-dated certs (Re: Monotone Security), Markus Wanner, 2008/10/20
- Re: [Monotone-devel] Re: hypothetical - future-dated certs (Re: Monotone Security), Daniel Carosone, 2008/10/20
- Re: [Monotone-devel] Re: hypothetical - future-dated certs (Re: Monotone Security), Markus Wanner, 2008/10/20
- Re: [Monotone-devel] Re: hypothetical - future-dated certs (Re: Monotone Security), Daniel Carosone, 2008/10/20
- Re: [Monotone-devel] Monotone Security, hendrik, 2008/10/16