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

[Tom Lord]

    > From: graydon hoare <address@hidden>

    >> you would be increasing, not decreasing vulnerability in really
    >> serious ways).

    > which sorts of vulnerability do you see?

One use for some of the cryptographic features is simply to provide a
form of reliable communication over insecure transports.  That can
work well enough, sure, and I guess that that was the original idea in
Monotone.

These two items in your "purpose" statement caught my eye:

    * defining different "acceptance criteria". monotone's update
      algorithm permits sorting and filtering by certificate; this
      means you can tell it to ignore changes until someone you trust
      is willing to attest to their quality, either by code review or
      test results. simply committing code does not force any other
      end-users to run it. (this feature is only partly finished --
      the UI for it is still wired to one setting).

    * decentralizing trust. monotone's operations are all based on
      checking RSA certificates. there is no central authority to
      which you must appeal to participate, or to be granted "commit
      access". on the other hand, nobody has to trust or accept your
      certificates, unless they happen to like you.

Very briefly: 

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.  Decentralizing trust in that manner accomplishes
nothing more than to raise the number of opportunities to steal
private keys, or worse, to play the "patient ringer" game of acquiring
undeserved trust by establishing a track record of apparently positive
participation in public projects.

In short, the spirit of those bullet points in the "purpose" list is
to create both motive and opportunity for crime -- the only missing
element is the bad guys.   The saving grace here is only that we
aren't (yet?) seeing deployment of these mechanisms in
security-sensative processes.

An alternative to an "acceptance criteria" based on trusted signatures
is the scientific method: repeatable results from independent code
reviews and independent testing.  To implement the scientific method
crypotgraphic _checksums_ have value: they allow experimenters to,
looking at the public records of other experimenters, verify that they
have done their part in ensuring that the same experiment has been
repeated.  "Trust, but verify!"  Signatures, on the other hand,
contribute very little.

Signatures contribute only one thing, that I can see: they can provide
a _mild_ amount security sufficient to turn an easily spoofed
transport into one that is relatively immune to spoofing.  For
example, if you're going to use NNTP or SMTP as a transport rather
than, for example, SFTP --- signatures can make it sufficiently hard
to "fake a message from Alan Cox" that, so long as the pay-off for
doing so isn't all that great anyway, few if any people will bother.
But talking about "acceptance criteria" and so forth goes well beyond
that fairly mundane use and calls to my mind the phrase "false sense
of security."  (One might argue, I think, that this is a good argument
against using such transports in a central way.  If a particular
transport solves the need for a transport but creates the new need for
an additional layer of security -- then perhaps that isn't the best
choice of transport.)

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.



    > > The rename-detection heuristics Graydon described have some uses,
    > > certainly -- but those uses are limited.

    > I think our rename handling is adequate, and is anyways a secondary
    > bit of information. the primary information -- which exact version of
    > a tree you are talking about -- is quite safe whether we detect a
    > rename as a rename or an add+delete.

That's fine for distributing trees but not for revision control.

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.

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.

In short, tree-deltas are a subject of programmer intention -- not
only of optimizing the size of a computed changeset.   Programmers
create changesets, not just trees.



    > > It sounds (Tromey's reply) like there will be no principled
    > > separation of patching from history that's stored only the meta-data
    > > of repositories -- that's a big mistake

    > I think you have misread. delta storage is handled by a dumb
    > SHA1-based subsystem which knows nothing about filenames, metadata or
    > other history. 

The missing element appears to be an arch-like `inventory' mechanism
that would let programmers control when and how tree-deltas are
considered.  I had the impression from Tromey that, in the absense of
`inventory', tree-deltas would be sometimes inferred from the
repository-side history of renames.  You seem to confirm that, below.


    > > A comparison of two manifests (at least as documented in the .info
    > > file) can never (accurately) yield "directory FOO was renamed" 

    > we treat directories as a side-effect of file paths. when a directory
    > is renamed, it is seen as a bunch of file paths changing. empty
    > directories are ignored.

That you wind up ignoring empty directories is a bug.

Treating directories as a side effect of paths means that a
programmer can not express, in a changeset that might be applied
inexactly, the idea of renaming a directory.


    > > Overall -- it's a relatively monolithic design in a design space that
    > > factors nicely and usefully into independent parts.

    > 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 :-)


    > but the
    > design is quite separated out: 

    >   - SHA1s denote file versions 
    >   - manifest SHA1s denote tree versions
    >   - every other bit of metadata (including the ancestry graph) is
    >     built from independent cryptographic certificates.

    > > Relying on history that way has significant operational drawbacks
    > > (i.e., _slow_) and semantic drawbacks (i.e., too many intertwingled
    > > factors).

    > the only present facts are file versions, their assignment to paths,
    > and a bag of certificates. renaming is a historical fact, not a
    > present fact. so I think it natural to calculate renames only as
    > needed when looking through history.

In arch-land, I've found some very handy uses for first-class
tree-deltas.

One use is merging changes from branches that haven't yet caught up
with a series of renames.

Another use is to maintain long-lived branches that differ primarily
by a tree-delta.

As a delta-compressed payload-generator for a protocol for
syncronizing trees, Monotone sounds like a potentially good design.

-t