Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0

[hendrik]

On Tue, Aug 25, 2009 at 08:04:02AM -0500, Timothy Brownawell wrote:
> On Mon, 2009-08-24 at 21:17 -0400, address@hidden wrote:
> > So this time around we're stuck.  Well, not entirely.  I suppose it *is* 
> > possible for a development group to upgrade all their clients first...  
> > And I suppose we could leave a monotone server that serves the 
> > new-protocol monotone source code running on the old protocol so that 
> > people are capable of upgrading.
> > 
> > But could we install negotiation in the new protocol we're introducing 
> > now so that next time around we have a chance of avoiding this mess?  
> > There will be even more monotone users out there by then.  I don't think 
> > we want monotone to end up like gnutella, which treats the use of an 
> > obsolete client as an attack.
> > 
> > That's something I learned years back when I was implementing OSI 
> > protocols.  Always negotiate the protocol version.
> 
> I guess there are really 2 kinds of protocol changes we make:
>   1) The actual data structures (certs, revisions, keys) change.
>      This would be like 'changesetify', or the current change,
>      or (probably) probably moving to SHA-3.
>   2) Only the network part changes.
>      This would be moving to SSL, or changing how refinement works.
> 
> In case (2) negotiation could be possible, but not in case (1).

In case (1) it would be difficult, but there might still be a way to 
bridge the old and the new, dependint on just what the changes are.   It 
might be possible, for example, to store both old-format certs and 
new-format ones.  Or to have new certs certifying that the old ones are 
valid.  The details will depend on the change being made.  And if the 
change is severe enough it may still be impossible.  If user communities 
are large enough and find migration difficult enough, a flag day may 
have the effect of forking the project.  I don't think we're really at 
that point now, but we may be in a few years.

> 
> We know there's an instance of case (1) coming up in about 3 years
> (SHA-3), which will probably require a flag day (and a full history
> rebuild).
> 
> Before that, there's moving to SSL. This is case (2), so we could try to
> add negotiation now to support it. Or we could make it possible for one
> server to serve both SSL and non-SSL at the same time on different
> ports, and not risk mucking up the nice encryption properties.
> 
> I'd prefer to plan for the "different ports" solution for next time,
> just because we're mucking around with the cryptography and want the
> final result to be nice and clean at that level. That next time should
> have plenty of planning, and we can come up with a decent negotiation
> scheme (which we very well might not get a chance to use before SHA-3
> comes out :) ).

In order to have a decent negotiation scheme next time, we have to have 
the elements of a bootstrap loader for the negotiation scheme this time.

The standard way to negotiate a protocol version is for one system to 
send a packet identifying (among other information) the protocol 
versions it supports.  Then the other responds with the verion it's 
chosen, and further communication proceeds with that one.

Is there any reason not to use this technigue with the new protocol 
we're introducing now?  We'd need to reserve a field in the first packet 
sent that identifies the protocol version.  I've been told there already 
is such a field.  Then we'd have to ensure that the first packet sent 
from the other end contains some fixed binary string.  The initiator of 
the connection can take that as a confirmatino that the other end will 
speak the same protocol.  Finally, the initiator has to refrain from 
sending further data (except maybe a retry of the initial packet) until 
it has received that confirmation.

That's enough for us to be able to piggyback future protocol 
negotiations onto the new one we're putting out now.  By the time we 
have to face this again, we'll be glad we have this one in place.  We 
may not be expecting this to happen soon, but we weren't expecting this 
one, either.

> 
> We'll also need to figure out how long to maintain compatibility for in
> the case of type (2) changes, even though this probably won't be an
> issue until after SHA-3 (unless we decide to allow for mixed hash types
> in your history or something, seems vaguely dangerous)

There probably are safe ways to do this.  As long as you limit the time 
span during which old hashes can be created to the period in which they 
are still cryptographically sound.  And you'd have to have some kind of 
marker on the hashes identifying which hash-coding was used for each 
hash.  As well as some way of connecting old hashes with new ones.

> Perhaps we also
> want to limit 'db migrate' compatibility to the same time span?
> 
> 
> 
> _______________________________________________
> Monotone-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel