[Vm-dev] re: deployment components

[Craig Latta]

Hi Frank--

     I wrote:

> Right, there's no need for anyone to use UUIDs when referring to
> classes in Smalltalk expressions.

     Torsten responded:

> Yes, exactly this. We still use regular names for the classes - but
> for the tools they have a distinguishable ID. Best is to use a UUID
> for the ID as it is unique from the beginning. So if you create a
> class "Foo" and I create one both are unqique by ID - even when using
> the same name.

     You responded to Torsten:

> The problem I have with UUIDs is that...

     Hooray! Discussion! :)

> ...in a distributed setting, you need to rely on everyone to generate
> UUIDs correctly. Now IF everyone implements UUID generation
> correctly...

     This is not hard, if there are common implementations at the
Smalltalk level (like we have common collection classes), or at the
virtual machine level (like we have common plugins).

> ...and IF everyone plays the game in good faith...

     Whoa, if you're going to invoke that concern, then I wonder how you
can tolerate what we've already been doing. Namely:

-    Compiling source code with no way to trust its authorship.

-    Compiling source code with no way to trust that the code does what
     the authors say it does (trusting authorship would help somewhat).

-    Compiling source code with no way to trust that the target
     compilation environment is sufficiently like the one in which the
     source code was developed.

> ...you will almost certainly not get a UUID clash. But when you say
> your code depends on package/class/object/method with guid SOME_GUID,
> and I as a bad actor inject my own class with guid SOME_GUID, how are
> you to know that you've just been 0wned?

     Again, how would you know today that the filein or Monticello
package you just loaded has 0wned you? When would you know? What would
you do about it?

     I think we have to concede that a motivated insider will always be
able to do bad things for a while before being caught, probably
involving social mechanisms. I'm interested in how to minimize this
time, and how to undo the bad things. With the Naiad module system, I
want to identify, as soon as possible, the human interactions required
to establish trust, and facilitate them.

     Naiad modules are synchronized live between systems (without
recompiling source code; only authors compile source code). You could
know you're likely to be 0nwed if you proceed with a module
synchronization because the cryptographic signature of a module is
incorrect for its purported authors. It would be similar to knowing that
the PGP-signed message you just read isn't really from the person whose
key you verified earlier.

> Wouldn't it be better, instead of using a key-value store (key K maps
> to value V), we have a store that uses function_of(V) maps to value V?
> Like in git: a commit is uniquely identified by its hash and, because
> the hash is a checksum, you can't - short of engineering a SHA-1
> collision (good luck with that) - forge part of the system.

     The things we want to identify have state that changes over time;
their hashes would also change over time. This is fine for things like a
module signature during a synchronization conversation (in fact, I'd
like to leverage the actual existing public-key cryptography
infrastructure for Naiad). It's inappropriate for referring to a
changing class over the course of years. UUIDs are a straightforward and
well-known way of generating IDs for things which change.

     Anyway, there it is, both UUIDs and hashing are involved.


-C

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)