[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: Timothy Brownawell
Subject: Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
Date: Sat, 29 Aug 2009 10:11:22 -0500

On Sat, 2009-08-29 at 16:37 +0200, Ludovic Brenta wrote:
> Timothy Brownawell <address@hidden> writes:
> > On Tue, 2009-08-25 at 20:24 -0500, Timothy Brownawell wrote:
> >> 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).
> >
> > This is done. New-version servers can also talk to old-version clients,
> > they now start with usher_cmd (which the client ignores the version of)
> > instead of start_cmd.
> >
> > So we now have full protocol version negotiation between 0.44 (and
> > earlier) and 0.45dev (and future).
> Wow, I'm really impressed.  The monotone community is really amazing and
> I'm proud to be part of it (as the sponsor of the package in Debian and
> as a strong supporter, not as a developer).
> However I'd like to better understand how old and new monotones are
> compatible (or incompatible) WRT the new key hashes.  Could you explain
> what happens when:
> - a new client sends certs to an old server?
> - an old client (belonging to another developer) gets those certs from
>   the server
> ?
> i.e. how does the old monotone see the certs and how does it interpret
> them?  If there are any user-visible effects, I think they should be in
> the user's manual.

For certs signed by key address@hidden (abcd...):
 * If there is only one key with that name, there are no
   user-visible effects.
 * If there is also a key address@hidden (1234...):
    * If the new-version peer has both keys, there is no
      user-visible effect when it receives certs.
    * If the old-version peer only has 1234... and the
      new-version peer doesn't have abcd..., then the new-version peer
      will drop the incoming certs (because the old peer can't send it
      the correct key, so it can't correctly identify the key hash to
      attach the certs to) and print a warning.
    * When the old-version peer receives certs signed by the key it
      doesn't have, the new-version peer will try to send that key
      and the old-version peer will drop the connection with "received
      duplicate key".

Hmm. If you migrate a database containing key address@hidden (1234...) and
certs signed by key address@hidden (abcd...), the upgrade logic will attach
them to that (wrong) key because it assumes your db is consistent. So we
need a command that will try to reassign any invalid certs to the
correct key, and maybe optionally delete them if it doesn't have that
key (so you'll be able to get a good copy, with the key, during your
next pull). We probably also want to drop certs with bad signatures (ie,
attached to the wrong key) during netsync, so they don't spread.

> > we want to call it 1.0 due to caring about compatibility now?
> > *ducks*
> If the compatibility is good, there is no need for a major version
> number bump and no need for you to duck.  On the contrary you should
> stand proudly and let everyone else bow in reverence :)


Free public monotone hosting:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]