Re: [Monotone-devel] Monotone Security

[Daniel Carosone]

On Thu, Oct 16, 2008 at 09:12:35PM +0200, Daniel Carrera wrote:
>> Make more sense now?
>
> I think we are on the same wavelength. You gave a good example where the  
> security check really belongs at checkout time and not at propagation  
> time. Please keep in mind that I was thinking about one specific attack.  
> I was not intending to speak in the abstract.

There's quite a bit of stuff in the wiki around trust and when to do
the evaluation, that talks about exactly these kinds of examples
(though not by name).  Another (less hypothetical) example involves
code review within the one project, such as promotion of committed
changes into a release branch; this involves different trust settings
in a release-branch workspace vs the code-review workspace.

The separation of communication from merging from trust evaluation is
a vitally important (to me, at least) core aspect of the monotone
model.  This is something you perhaps still need to get your head
around fully, in the sense of looking at where to apply solutions to
the problems you see.  In particular, when you think of 'recipient',
think of the recipient not at netsync time, but as the recipient of
information in the database - the relying party of the signatures when
running a checkout or merge or similar operation.  From this point of
view, the database is really just a (write-back, sometimes dirty)
cache for netsync - the coarse-grained netsync permissions are mostly
there to avoid cache pollution.  It's exactly this that lets us rely
(almost) entirely on recovery rather than the other means you
mentioned in another thread.

From what I gather, most of the rest of the current crop of
dvcs tools seem to conflate two or more of those steps (in different
permutations).  As a result, you have to trust someone's code before
you talk to them, or have to resolve merge conflicts as you talk to
them, or as you commit, or other various inconveniences.  Monotone
simply records these things in history and empowers the end user to
evaluate the fitness of a revision for his current purposes based on
the (crptographically verifiable) historical record.

As for dates, there are very good reasons why revisions might be
deliberately marked with a non-current date. There are even cases
(though they're admittedly rarer and rather specialised) where the
signing-date of another non-date cert may be non-current, when we
change the cert format to contain this information.  Database and
vcs-tool migrations are a clear example here.

Mmost importantly, please remember that it is fundamental that an old
revision (which has many children) can be given a new cert.  Test
results, or branch approvals after code review and collection of
enough test results, or even just additional comments are all common
and important uses for this.  So the logic you're trying to apply just
simply doesn't apply - regardless of whether in sender or recipient.

In monotone, ancestry is time; the clock ticks in revisions and certs
are applied independently of that chronology.  It may me illuminating
to compare the kinds of metadata that are stored in certs on revisions
with the metadata that's stored in attr's within revisions (and thus
tightly bound in history).  The difference in this context is an
important reason to use one method over another for a given purpose. 

Lastly, though, let me say that I welcome your work and discussion,
and would like to see it integrated with the rest of the documentation
in the wiki.  Even if there are mistakes or subtleties you have missed
in your first analyses, that we are correcting here with further
discussion, that learning process is itself valuable to capture and
improve the documentation and guidance for future new users.

--
Dan.

pgpa0uvxgJqve.pgp
Description: PGP signature