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.
pgpELXUzoR8W5.pgp
Description: PGP signature
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel