[Unison-hackers] version negotiation

Greg Troxel gdt at lexort.com
Tue Jun 29 19:38:39 EDT 2021


I just wrote to -users to ask if people really use socket mode, and if
so how it is sound from a security viewpoint.  I am guessing that the
answer is that some do, that it is not sound, but some people have
threat models that say their LAN is ok.

A PR to add version negotiation is on the table:

  https://github.com/bcpierce00/unison/pull/507


I am trying to meet the dual goals of allowing automatic compat and not
being complicated, with the following constraints:

  Eventually we should have a way for two unison instances to negotatiate
  and find a common version with no user/admin interaction.

  Right now there are some people running 2.48.  I am ignoring this.

  RIght now there are a lot of people running various 2.51.   If we can
  release a new 2.51.5 with the property that it works fine both ways with the
  existing 2.51.Y, Y <= 4, but can negotiate with itself (perhaps
  choosing the current protocol) and negotiate with some 2.52.0 which
  has the current protocol and a new one, all without config, that would
  be great.

  If the future 2.52 with the new protocol can also interop with
  2.51.<=4, that's nice, but I'm not sure it's realistic

With these properties, we can say to people

  update to 2.51.5, and don't worry it's safe.  packaging systems can do
  it, even in LTS, because is is just a new optional feature along 2.51

  once everything is 2.51.5, then you can update randomly to 2.52 and
  not have trouble



My understanding is that right now, unison simply assumes that the
remote side speaks the same protocol, and things deteriorate from there
if it is not true (because of a 2.48/2.51 mismatch).

#507, as I understand it, causes the server to start off with proto
version negotation instead, and the server can be configured not to, so
that old clients can connect.

So, I am wondering if instead, we say:

  2.51.5 will simply announce as 2.51.5

  2.51.5, if it sees the remote as 2.51.5 or higher, instead of starting
  the old protocol, will send the first message of the "determine
  supported proto versions negotiation protocol".  If it sees something
  earlier, it will just do the old protocol.


this makes a version higher than a magic number being sent from the
server be a clue to the client that it can do proto version negotiation
instead of just speaking the old protocol.  And maybe the client must do
this if it is 2.51.5 or higher, and must not otherwise.

This is a bit half baked, but I wanted to throw it out for discussion.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://LISTS.SEAS.UPENN.EDU/pipermail/unison-hackers/attachments/20210629/a0d0932f/attachment.asc>


More information about the Unison-hackers mailing list