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

[Tom Lord]

    > From: graydon hoare <address@hidden>

    > 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.


Nicely said and, wrong or at least misleading :-)

In the real world, signatures don't provide a vocuabulary for
_expressing_ trust, nor is one really needed.  "I trust
address@hidden" is a perfectly fine expression.  And that's the
expression of trust even where signatures are used -- it's just that I
then have some record somewhere of what public key
"address@hidden" refers to.

Signatures provide an imperfect mechanism for _communicating_
expression of trust and assertions about trust.  When I trust
address@hidden, let's call that "me trusting one thing".  When I
trust a signature from address@hidden, now I'm trusting _two_
things: graydon, still -- but also the mechanism for communication.
(Three things, really: I'm also trusting that certain math problems
are, in fact, hard.)  In this case, and especially when I'm dealing
with dozens or hundreds of these signatures including from people whom
I never have and likely never will meet -- my trust in the mechanism
for communication is the weak link.

I'm guessing that you, graydon, work in a typical office-park type
setting or else in a typical home somewhere.  Do you really think your
keys are so secure?  Do you have a garbage can in your office and is
it emptied every night?  Are you sure you'd know if someone came into
your home while you were away?  If your key is just a tiny bit
insecure but it is just one of 100 keys that I rely on, and all of
those 100 are just a tiny bit insecure, and the incentive for
thwarting my attempts at security are high --- that's motive and
opportunity:

   value-of-crime - cost-of-key-theft

is the price of the offer you're making to criminals.

Signatures are, sorry to say it, more than a little bit "snake oil".
They have their uses but, in the popular memesphere, those uses are
greatly exaggerated.

You say "I would like the ability to express that trust policy,
though."  You have that ability sans signatures.  What you lack, a
priori, is the ability to communicate digitally about assertions
relating to that trust policy.  One fairly unreliable way to achieve
that communication in a global context is to rely on your partner in
communication to maintain a private key robustly.  Another, superior
way is to rely on your partner to shout real loud so that many people
can hear -- and then you can ask around: "I think he said X.  Is that
what you heard, too?"  If someone disguises their voice as your
partner, with the shouting technique, word about that will get around
real quick if it matters and if your partner hasn't been completely
isolated and decapacitated.

Aside from the technological weaknesses of security, there's a broader
issue.  Trust in wet space works fairly well.  If I meet you, and you
lie to me, and I'm just a little bit skilled in this area -- I'll pick
up your tells.  I'll have a gut feel.  I'll know whether or not to
trust you or how much to trust you.  That's hard-wired at at the root
and developed with practice.  That's a product of evolution.

Digitally -- it's a whole new ball-game.  The "patient ringer" threat
is real and, as far as I can tell, an insurmountable threat to some
popular foss development practices.  People who want to reduce the
human experience of "trust" to a game that you can plan on the
internet are, as they say, Missing The Point.



    > 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.

There's a bit of a difference between digitally mediated development
and extension of trust and scientific experiments.  In the scientific
method, I _don't_ have to trust my equipment in any absolute sense.
It's precisely repeatability of experimentation -- the fact that my
peers will be using _their_ independently constructed equipment to try
to reproduce the results -- that overcomes the limits to which I can
vette my own equipment.  With cryptographic communication of
assertions about trust, in contrast, the number of
single-points-of-failure in the chain of reasoning to a conclusion
just grows and grows.


    > > 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.

Why in the world is this a new problem which requires a
version-control-specific solution?  Surely the various parts of this
company face a huge and open-ended number of needs for reliable
communication between parts.  Surely any one part of the company must
communicate reliably to other parts countless types of information,
constantly.   Why, then, a version-control-specific solution?

Furthermore, the stated goals on the web page about "acceptance
criteria" don't jive very well with the scenario of in-house QA
talking to other parts of the company.   It makes no sense.   Are you
saying that communications from in-house QA to the rest of the company
are constantly interrupted by spoofs and other communications from
outside parties?    If that's the case -- if the communications within
that company are that noisy -- then the assertions from the QA
department are clearly without any value whatsoever because, heck, if
the bad guys can't spoof a QA declaration, they'll just spoof
something else instead.    Again: there seems to be a big confusion
here between the need for reliable communication and the issues
specific to version control.


    > 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.

Right.   So, the trick here is to make the _consequence_ of forging
signatures worth far, far, less than the cost, from as many bad-guy
perspectives as you can think of.



    > > 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. 

I don't follow you there.   I mean, I get the literal meaning but I
don't see the point.


    > > 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.

We'll see.   There's a fairly comprehensive solution to this in the
inventory/mkpatch/dopatch mechanisms of arch which it may be helpful
to consider.


    > > 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.

"Seen to be renamed" implies an access on both ends to complete
history and agreement upon a common reference revision.


    > > 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.

Glad to help.


    > >     > 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.

Ok.

-t