On Tue, Aug 25, 2009 at 6:24 PM, Timothy Brownawell<tbrow...@prjek.net> 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?
> 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.
Yeah.
> 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.
> 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 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.
> 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.
zw
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
