On Sat, 2009-08-29 at 16:37 +0200, Ludovic Brenta wrote:
> Timothy Brownawell <tbrow...@prjek.net> 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 f...@bar.com (abcd...):
* If there is only one key with that name, there are no
user-visible effects.
* If there is also a key f...@bar.com (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 f...@bar.com (1234...) and
certs signed by key f...@bar.com (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.
> > ...do 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 :)
>
--
Timothy
Free public monotone hosting: http://mtn-host.prjek.net
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
