[Monotone-devel] Re: Monotone and changesets

[graydon hoare]

Colin Walters wrote:

> Hm.  My problem with not having GUIDs (logical file identity) isn't so
> much that a patch could fail to apply, as that it could appear to apply
> successfully, but to the wrong file.

it seems unlikely to me, but who knows. we'll have to wait and see.

> Sure.  But this should be an extremely rare case, and both parties
> involved will likely quickly understand the benefit of common file
> identities.

well, now we're just comparing subjective opinions on the unlikeliness 
of various failures. I think it's probably an issue which will be 
tolerable if either of us are right or wrong.

> So I think it would be useful for Monotone to support explicit file
> identity as well.

ok .. erm, I don't. but if you want to submit a patch, or perhaps talk 
me into it further, I suppose I can't stop you. I can think of a few 
ways to do it, but you know, it's extra code and extra concepts to add. 
monotone is less than half of tla's size at the moment. that's not an 
accident: I'm a bit more selective about adding new concepts.

> > this sounds more complex than necessary, because some of arch's merge 
> > commands (perhaps not star-merge with the --three-way option?) treat 
> > edges as boolean sets of "applied or not" patches.
>
>
> edges == changesets?  

no, edge == "the sequence of all the changesets between an ancestral 
point and a merge candidate". suppose you have two lines of development:

   a->b1->b2->b3   and   a->c1->c2->c3

if I understand correctly, arch's merge algorithm considers the presence 
or absence of each changeset, a->b1, b1->b2, b2->b3, in the edge a->c3, 
when deciding which changes to apply to c3. monotone compares the 
composite changeset a->b3 to the composite changeset a->c3; so if for 
example c1->c2 is a copy of b1->b2, then the a->c3 composite changeset 
will just happen to have more in common with the a->b3 composite 
changeset, making the 3-way merge easier.

> Not sure I understand; how does this changeset copying work?  Wouldn't
> that be cherrypicking?

yeah. I expect "cherrypick" means, in monotone's context, "copy 
changeset from one place to another and try to apply it". I don't think 
we have much need to keep extra metadata about that copy. maybe we will, 
I'm not certain.

> > anyways, OpenPGP keys are different from OpenPGP certs. OpenPGP certs 
> > don't express name/value pairs at all, just this "I trust key X from 1 
> > to N" setting. so we can't really use them "directly" anyways.
>
>
> Not sure I understand - wouldn't you just e.g. sign the manifest with
> the OpenPGP key?

well, we use certs to express arbitrary name=value metadata, such as 
"branch=foo" or "author=bob". we could write this string out and then 
make an OpenPGP signature of it, but then OpenPGP is really not serving 
much more than an RSA signing mechanism, and it's a bit complex for such 
a simple task. (note: tla doesn't use gpgme either; it just forks and 
execs a shell command it reads from a text file and captures the result: 
lots of failure cases, terrible performance)

I'm not arguing this in terms of ideals, I'm arguing it mostly in terms 
of implementation pragmatics. our crypto glue costs only a couple 
hundred lines of code, and can chew through thousands of certs per 
second. the keys, certs, and signatures are just simple strings kept in 
the same general SQL store. gpgme would have been thousands of lines of 
code, with dozens of potential leaks and failure modes related to 
misconfiguration, process management, environmental interaction, etc. 
I'd have had far less confidence that it was working right, and I'd have 
very little recourse if it performed poorly.

> > it's quite possible that we could teach it to import *keys* from OpenPGP 
> > (and SSH, and openSSL/.pem), since the RSA key primitives are just a 
> > couple of large integers in some arcane byte-string encoding.
>
>
> eek :)

no, I mean that for real. it'd probably win most of the benefits you 
want, and it's just a parsing problem. very likely less hassle than 
trying to migrate to gpgme, and more likely to be innocuous in terms of 
performance. keep in mind, we're doing bulk operations which can require 
thousands of verifications. it's important to be fast.

> Hmmm.  I don't like that argument very much.  If our OpenPGP
> distribution system is flawed, we have very serious problems.  Having
> Monotone still work in that scenario isn't all that valuable.

oh, I think the OpenPGP distribution system is full of flaws, chief 
among them transitive trust system. the meet-and-greet aspect of it is 
also nonsense imo, but mostly my objection is just that it's 
overengineered, hard to understand, hard to use, hard to integrate into 
programs, etc. if integrating it was only a few extra lines of code, I'd 
be happy to put my security objections aside.

I do understand there's value to be had from interoperability, just not 
*unlimited* value. SSH and SSL don't speak OpenPGP either, yet they seem 
to work.

-graydon