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

[Timothy Brownawell]

On Tue, 2009-08-25 at 11:07 -0400, address@hidden wrote:
> 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.

I'm now thinking we can make the about-to-be-released clients work with
current-version servers. If they see an earlier-version hello from the
server, they just need to store that in the session and use it for all
packets sent. The only actual difference would be the cert data packets,
and which hashes to use during cert refinement (would have to store both
old and new hashes in the db).

I'll see if I can code this up later this week or this weekend.

In the future, the server would also have to recognize earlier versions
in the auth/anonymous packets and adjust itself accordingly (easy, since
server/client use almost exactly the same code).

After looking at Philipp's email about what SMTP does for SSL, it looks
like just adding a third alternative to auth/anonymous would work, let
the client send a "SSL" packet (with no data) and then SSL negotiation
starts. Make this the required response for new protocol versions, so
the non-SSL stuff can be taken out eventually.

How would we go about testing this? Would we have to have a test that
looks for specifically named old monotone executables ("mtn-netsync6",
etc) in your path, and runs against those if they exist (and does
nothing if they don't exist)? It'd be nice to not require that much
special setup, so the test would be more likely to actually run.

How long would we want to try to stay compatible with old versions,
maybe 2.5 or 3 years? Debian releases last 4 years now (2 as stable, 2
as oldstable), and Ubuntu LTS releases happen every 2 years and are good
for 3 or 5 years. RHEL versions are apparently supported to some degree
for 7 (!) years.

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

If you have old hashes in your history, then people will still be
receiving them arbitrarily far in the future during initial pulls. And
there's no way to tell when those hashes were created.

I suppose the best we could do would be to explicitly forbid using
different hashes on a cert and on the revision it attaches to, and
require a --option in order to see old-hash certs as valid. Then at
least you know who is explicitly signing off on the validity of those
old hashes.