On Tue, Aug 25, 2009 at 08:24:24PM -0500, Timothy Brownawell wrote: > On Tue, 2009-08-25 at 11:07 -0400, hend...@topoi.pooq.com 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 > Monotone-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/monotone-devel _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel