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

[hendrik]

On Tue, Aug 25, 2009 at 08:24:24PM -0500, Timothy Brownawell wrote:
> 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.

I'll have to think a bit more about this.  There must be a solution.
I hope it'll turn out to be a practical one.

-- hendrik

> 
> 
> 
> _______________________________________________
> Monotone-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel