[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] netsync flag day justifies bumping version number t
From: |
hendrik |
Subject: |
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0 |
Date: |
Tue, 25 Aug 2009 22:12:39 -0400 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
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
- [Monotone-devel] netsync flag day justifies bumping version number to 1.0, Ludovic Brenta, 2009/08/24
- Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, hendrik, 2009/08/24
- Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, Tero Koskinen, 2009/08/24
- Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, Timothy Brownawell, 2009/08/24
- Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, hendrik, 2009/08/24
- Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, Timothy Brownawell, 2009/08/25
- Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, Philipp Gröschler, 2009/08/25
- Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, hendrik, 2009/08/25
- Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, Timothy Brownawell, 2009/08/25
- Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0,
hendrik <=
- Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, Daniel Carosone, 2009/08/25
- Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, Timothy Brownawell, 2009/08/26
- Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, Daniel Carosone, 2009/08/26
- Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, Zack Weinberg, 2009/08/25
- Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, Timothy Brownawell, 2009/08/26
- Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, Zack Weinberg, 2009/08/27
- Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, Timothy Brownawell, 2009/08/27
- Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, Markus Wanner, 2009/08/27
- Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, Zack Weinberg, 2009/08/27
- Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, Markus Wanner, 2009/08/28