Re: [Monotone-devel] newcomer (rude, but hopefully not to rude) questions

[graydon hoare]

Tom Lord <address@hidden> writes:

> Incorporation of cryptographic-signature based "acceptance criteria"
> into security-sensative processes accomplishes nothing more than to
> raise the pay-off to bad guys for acquiring the ability to spoof or
> abuse a signature.

I disagree. signatures provide a useful, practical vocabulary for
expressing trust. if you only want to trust your own in-house
autotester, that is up to you. I would like the ability to express
that trust policy, though.

of course misplaced trust can be abused, but that is a fact of
life. you must be careful who you trust. if you run scientific
experiments, you must trust your experimental equipment to tell you
the truth too. life has compromises like this.

> An alternative to an "acceptance criteria" based on trusted
> signatures is the scientific method: repeatable results from
> independent code reviews and independent testing.

I agree that self-verified or third party testing is good. my major
motivation here is to make it possible for an in-house QA lab to
publish quality metrics that the rest of the company (or developer
community) uses, internally. this is what the vocabulary is for.

I don't believe that the *possibility* of forging signatures
represents a compelling argument that they not be used as a vocabulary
for expressing trust. all trust devices have failure modes.

> This is also, in some sense, an example of how Monotone is
> needlessly and counterproductively monolithic.  The scientific
> method of establishing trust in code doesn't require signatures --
> but the use of an easily spoofable transport does.  It then looks
> like there's kind of a mission creep for those signatures -- in a
> dangerous direction.

I disagree. there are two kinds of facts monotone can look at: those
which are self-evidently true (content-hashes) and those which are
possibly-untrue assertions made by humans (this file is an ancestor of
that, this changelog is associated with this tree, etc.) the "mission"
of certs has always been to provide a vocabulary for expressing the
trustworthyness of facts in the latter category. 

> As a simple example from arch, if I commit a change which renames a
> directory, that's recorded as renaming a directory.  Consequently,
> if you want to apply that change to your diverged tree, in which
> files have been added to that directory, the change applies in a
> useful, controllable way.

true, merging an added file in a "renamed directory" in this case will
land the add on its "old" path, so you will have to move it
later. this is an interesting case, and I thank you for pointing it
out, but I don't think a very deep problem. we can either infer the
directory move by looking at path prefixes, or just store directories
as extra (empty) items in a manifest.

> As another example: if I have renamed a file and made minor changes
> while you've modified the file under it's original name -- I want to
> reliably identify your changes as being intended for my renamed
> file.

hm, I think you misread. this works in monotone: the file is seen to
be renamed on one edge but not another, so the 3-way merge at the
manifest level incorporates the non-conflicting change to the name,
and the 3-way merge at the file level incorporates the non-conflicting
edit.

> That you wind up ignoring empty directories is a bug.

I see. it seems people keep caring about empty and moved directories.
I hadn't previously thought of them as important enough to warrant
effort, but I suppose I shall add support for them. your examples are
worth addressing. thanks for the tip.

>     > the tool is monolithic. I consider that a selling point. 
> 
> Wow.  You're not the only person I've ever heard say something like
> that.  Where I come from, that's a very odd thing to say.  Kind of
> dadaist :-)

as with many things in programming, I think the main issue is taste,
deciding where to draw lines. I like where monotone draws its lines.

-graydon