Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0

[Timothy Brownawell]

On Tue, 2009-08-25 at 20:37 -0700, Zack Weinberg wrote:
> On Tue, Aug 25, 2009 at 6:24 PM, Timothy Brownawell<address@hidden> 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).
> 
> That sounds good, but what about old-client, new-server?

The clients that are out there now would see a too-new 'hello' packet
and tell you to upgrade. AFAICT the only (mostly) dead space we have to
hack around this with is if we stole some bits from the nonce, which
doesn't seem like that great an idea.

> > 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.
> 
> As long as we have the old protocol code in the executable, we could
> have a debugging option that makes it only speak the old protocol, and
> use that for testing.

Sounds reasonable.

> > 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.
> 
> You can still send mail with the protocol defined in RFC 822.
> 
> I think it's a mistake to think about this in terms of time.  Instead,
> we should think about it in terms of code burden to maintain support
> for the old protocol, and security-model burden to maintain the
> meaningfulness of old signatures.

We probably want to consider both, really. If compatibility is very
cheap to keep around, we might as well. Or if 3/4 of people only have an
older version available through their distro, we might want to make a
bit more effort if needed to keep working with it.

> We last had a "you must re-issue all of your certs" event at version
> 0.25.  There's no point in maintaining wire compatibility past that
> point (in fact, I doubt there is any point in keeping the
> rosterify/changesetify code anymore).
> 
> It sounds like the keys-by-hash change introduces a weaker sort of
> cert flag day, where old signatures can no longer be unambiguously
> verified (do I understand correctly?) However, there's a
> straightforward way to keep old history meaningful (see below), and it
> doesn't sound like it will be hard to keep speaking the old protocol
> (modulo negotiation issues) so we should.

The old-format certs become ambiguous about which key they were signed
with. They can be disambiguated by trying to verify the signature
against each matching key (typically there will only be one) and seeing
which one works. But you might not be easily able to obtain the correct
key, if the (old-format) server knows a different key with the same
name.

Once the certs are taken off the wire they'll be matched with the
correct key (or I guess dropped with a warning if we can't find that
key) before being stored in the db, so any ambiguity will be confined to
netsync time.

> > 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.
> 
> What I think this calls for is a new cert type, which I'm going to
> call "voucher".  A voucher cert places a new-form signature on a
> particular set of old-form certs for a revision.  The data I think we
> need to sign is
> 
>   revision_id || ( cert_hash || old_keypair_id || new_keypair_hash )*
> 
> where || is concatenation-with-separator and ( ... )* is repetition.
> (There's no need to include any of the data of the old cert since its
> hash is over all of that.)
> 
> New clients trust certs in the old form if and only if there is a
> new-form voucher cert attesting to their validity.  We then document
> that for this transition, one person per project must run a special
> command to generate voucher certs for all the old certs in the
> database, then everyone should pull from them, and if you have
> unpublished revisions you need to generate vouchers for those
> yourself.

I guess the trust hooks would see this as if the voucher key had signed
the original certs?