Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Tue, 2009-08-25 at 20:37 -0700, Zack Weinberg wrote:
> On Tue, Aug 25, 2009 at 6:24 PM, 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).
>
> 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?
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Wed, 2009-08-26 at 12:52 +1000, Daniel Carosone wrote: > On Tue, Aug 25, 2009 at 08:24:24PM -0500, Timothy Brownawell wrote: > > 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. > > I'm really struggling with this whole concept. It's come up both in > this thread, and in zwol's about dependencies. > > I don't see why an operating system choice (let alone which variant of > an operating system, or which variant of the variant) by an end user > matters. If end-users can do "apt-get install monotone" (or equivalent), that's a rather lower barrier than having to go find a more recent version on our downloads page, and is one less reason for projects to avoid us. So it would be nice to have compatibility back far enough to cover whatever "most" people who might want version control are running, or would be thought to be running. > For building new versions of the application on that platform, with > minimal fuss in terms of additional dependencies, as a common courtesy > to maintainers within reasonable bounds, sure. That's just a general > portability goal. Providing support guarantees, especially outside > those reasonable bounds, surely is the support vendor's risk, > responsibility and therefore business model. I'm not thinking about maintainers at all here, I'm wondering if requiring extra setup by whatever fraction of other projects' developers are running a stable distro release might scare projects away. Maybe that's a completely bogus concern, though. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Tue, Aug 25, 2009 at 6:24 PM, 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).
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
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Tue, Aug 25, 2009 at 08:24:24PM -0500, Timothy Brownawell wrote: > 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. I'm really struggling with this whole concept. It's come up both in this thread, and in zwol's about dependencies. I don't see why an operating system choice (let alone which variant of an operating system, or which variant of the variant) by an end user matters. For building new versions of the application on that platform, with minimal fuss in terms of additional dependencies, as a common courtesy to maintainers within reasonable bounds, sure. That's just a general portability goal. Providing support guarantees, especially outside those reasonable bounds, surely is the support vendor's risk, responsibility and therefore business model. I don't get why some vendor's OS support cycle dictates the application's cycle. Whatever the numbers above and today, do ours change if a new vendor appears with bigger numbers? Are we really saying that just because someone still runs "pink pantyhose 11", which was originally shipped when monotone 1.1 was current 11 years ago, they will also still be running monotone 1.1? Must every software project/author (monotone, botan, sqlite, etc) wear those pink pantyhose as a result? There seem to be contradictory requirements between the two threads, and moreso the discussion seems to be heading that we're to be constrained by the intersection of both. That's especially hard to swallow when I'm having difficulty understanding why we should be (heavily) bound by either. Of course we should avoid unnecessary compatibility breaks between our own releases, and I encourage the discussion of how we might do so before making our next release. Ultimately, upgrades will be required if you want new features, including new features adopted by others in the broader community of clothing colours, and db migrate is our upgrade path. -- Dan. pgp2eh1Pq0rsE.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Tue, Aug 25, 2009 at 08:24:24PM -0500, Timothy Brownawell wrote:
> On Tue, 2009-08-25 at 11:07 -0400, hend...@topoi.pooq.com wrote:
> > In order to have a decent negotiation scheme next time, we have to have
> > the elements of a bootstrap loader for the negotiation scheme this time.
> >
> > The standard way to negotiate a protocol version is for one system to
> > send a packet identifying (among other information) the protocol
> > versions it supports. Then the other responds with the verion it's
> > chosen, and further communication proceeds with that one.
> >
> > Is there any reason not to use this technigue with the new protocol
> > we're introducing now? We'd need to reserve a field in the first packet
> > sent that identifies the protocol version. I've been told there already
> > is such a field. Then we'd have to ensure that the first packet sent
> > from the other end contains some fixed binary string. The initiator of
> > the connection can take that as a confirmatino that the other end will
> > speak the same protocol. Finally, the initiator has to refrain from
> > sending further data (except maybe a retry of the initial packet) until
> > it has received that confirmation.
> >
> > That's enough for us to be able to piggyback future protocol
> > negotiations onto the new one we're putting out now. By the time we
> > have to face this again, we'll be glad we have this one in place. We
> > may not be expecting this to happen soon, but we weren't expecting this
> > one, either.
>
> 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).
>
> 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.
>
> 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.
>
> 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.
>
> > > We'll also need to figure out how long to maintain compatibility for in
> > > the case of type (2) changes, even though this probably won't be an
> > > issue until after SHA-3 (unless we decide to allow for mixed hash types
> > > in your history or something, seems vaguely dangerous)
> >
> > There probably are safe ways to do this. As long as you limit the time
> > span during which old hashes can be created to the period in which they
> > are still cryptographically sound. And you'd have to have some kind of
> > marker on the hashes identifying which hash-coding was used for each
> > hash. As well as some way of connecting old hashes with new ones.
>
> 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.
>
> I suppose the best we could do would be to explicitly forbid using
> different hashes on a cert and on the revision it attaches to, and
> require a --option in order to see old-hash certs as valid. Then at
> least you know who is explicitly signing off on the validity of those
> old hashes.
I'll have to think a bit more about this. There must be a solution.
I hope it'll turn out to be a practical one.
-- hendrik
>
>
>
> ___
> Monotone-devel mailing list
> Monotone-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/monotone-devel
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Tue, 2009-08-25 at 11:07 -0400, hend...@topoi.pooq.com wrote:
> In order to have a decent negotiation scheme next time, we have to have
> the elements of a bootstrap loader for the negotiation scheme this time.
>
> The standard way to negotiate a protocol version is for one system to
> send a packet identifying (among other information) the protocol
> versions it supports. Then the other responds with the verion it's
> chosen, and further communication proceeds with that one.
>
> Is there any reason not to use this technigue with the new protocol
> we're introducing now? We'd need to reserve a field in the first packet
> sent that identifies the protocol version. I've been told there already
> is such a field. Then we'd have to ensure that the first packet sent
> from the other end contains some fixed binary string. The initiator of
> the connection can take that as a confirmatino that the other end will
> speak the same protocol. Finally, the initiator has to refrain from
> sending further data (except maybe a retry of the initial packet) until
> it has received that confirmation.
>
> That's enough for us to be able to piggyback future protocol
> negotiations onto the new one we're putting out now. By the time we
> have to face this again, we'll be glad we have this one in place. We
> may not be expecting this to happen soon, but we weren't expecting this
> one, either.
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).
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.
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.
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.
> > We'll also need to figure out how long to maintain compatibility for in
> > the case of type (2) changes, even though this probably won't be an
> > issue until after SHA-3 (unless we decide to allow for mixed hash types
> > in your history or something, seems vaguely dangerous)
>
> There probably are safe ways to do this. As long as you limit the time
> span during which old hashes can be created to the period in which they
> are still cryptographically sound. And you'd have to have some kind of
> marker on the hashes identifying which hash-coding was used for each
> hash. As well as some way of connecting old hashes with new ones.
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.
I suppose the best we could do would be to explicitly forbid using
different hashes on a cert and on the revision it attaches to, and
require a --option in order to see old-hash certs as valid. Then at
least you know who is explicitly signing off on the validity of those
old hashes.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
Thomas Keller spake unto us the following wisdom: > However, I strongly oppose to revert the current work from Timothy in > nvm, just because this would put this particular, very useful change > back on a work bench where it is easy to get forgotten about. There are > no other big changes sitting in 0.45dev which would need an immediate > release, so I also have absolutely no rush releasing 0.45, say, next week. > > So I think now that this change is in nvm, we should start dealing with > that. I see basically three options: > > a) We don't care at all about netsync breakage. After all there *is* a > reason why we have no 1 as major version number... If you find this > unfair towards bigger projects, ok, then lets make a 0.44.x branch and > split up the development here. If people want the new features, they > have to upgrade, if not, we promise that we fix critical bugs for the > 0.44.x line for at least the additional time we see projects using the > old client. Since this is a rather small community and monotone hasn't > seen many critical bugs in its history, I think this is managable. As a member of one of the large projects using monotone (Pidgin), this seems OK to me. The fact that monotone does not require any support libraries/etc. means that dealing with version skew across servers/projects is as simple as 'cp /usr/local/bin/mtn /usr/local/bin/mtn0.44' before 'make install'. In fact, we already do this, so that our downloadable bootstrap database will work for users of Debian Lenny. It is created by /usr/local/bin/mtn-0.39. :-) As I type that, it does occur to me that this means that our downloadable bootstrap db will *have* to upgrade, as we will no longer be able to use netsync to "backport" the db format. I don't think this is an earth-shattering loss, though. Frankly, anyone who is serious about using monotone is using something post-0.40 anyway, for the various speedups. > b) We do not release 0.45 unless we have some netsync version > negotiation in place, like some people spoke about. I'm not quite sure > if /how this will seamlessly work with current mtn netsync versions, > because I don't see (from a glance over the netsync code) an easy way to > tell the user "hey, please upgrade to 0.45 - your client is too old". > > c) We do not release 0.45 unless we made the server part accepting the > pre-0.44 client requests. This seems to be related to b) in the way that > at least the server has to somehow figure out what kind of client speaks > to him, but as a start we could maybe say "no version field -> pre 0.44, > version field available -> 0.45 or later". Either of these would, of course, be superior -- but I think a) is sufficient if push comes to shove. That said, don't rush an 0.45 on our account. I know I have complained early and often about the key ID thing, and it is indeed a problem for us, but a few weeks or even months won't make a huge difference. > Again, I still think its *good* to have this change in nvm - even if > this makes the next release take a little longer. Agreed. Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 signature.asc Description: Digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
Zack Weinberg schrieb: > On Tue, Aug 25, 2009 at 11:17 AM, Ludovic > Brenta wrote: >> Richard Levitte writes: >>> stephen_leake> I agree; we should hold the next monotone release until >>> stephen_leake> netsync version negotiation is supported. >>> >>> So now, all we gotta do is hack that as good and fast as we can? >>> >>> Cheers, >>> Richard ( it won't help current clients anyway, will it? ) >> Yes, it would; a client built from today's n.v.m head cannot speak to a >> server running on a long-term-support operating system such as Debian >> stable. Not can it speak to any other client a week old, for that >> matter. > > This is bad enough that we might want to consider reverting the > keys-by-hash change until we have protocol negotiation in place, > however we wind up doing that. As the current release manager I haven't yet spoken up just because I've seen a lot of other people with lots of good arguments for either case and I haven't had to add much to them. However, I strongly oppose to revert the current work from Timothy in nvm, just because this would put this particular, very useful change back on a work bench where it is easy to get forgotten about. There are no other big changes sitting in 0.45dev which would need an immediate release, so I also have absolutely no rush releasing 0.45, say, next week. So I think now that this change is in nvm, we should start dealing with that. I see basically three options: a) We don't care at all about netsync breakage. After all there *is* a reason why we have no 1 as major version number... If you find this unfair towards bigger projects, ok, then lets make a 0.44.x branch and split up the development here. If people want the new features, they have to upgrade, if not, we promise that we fix critical bugs for the 0.44.x line for at least the additional time we see projects using the old client. Since this is a rather small community and monotone hasn't seen many critical bugs in its history, I think this is managable. b) We do not release 0.45 unless we have some netsync version negotiation in place, like some people spoke about. I'm not quite sure if /how this will seamlessly work with current mtn netsync versions, because I don't see (from a glance over the netsync code) an easy way to tell the user "hey, please upgrade to 0.45 - your client is too old". c) We do not release 0.45 unless we made the server part accepting the pre-0.44 client requests. This seems to be related to b) in the way that at least the server has to somehow figure out what kind of client speaks to him, but as a start we could maybe say "no version field -> pre 0.44, version field available -> 0.45 or later". Again, I still think its *good* to have this change in nvm - even if this makes the next release take a little longer. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Tue, Aug 25, 2009 at 11:17 AM, Ludovic Brenta wrote: > Richard Levitte writes: >> stephen_leake> I agree; we should hold the next monotone release until >> stephen_leake> netsync version negotiation is supported. >> >> So now, all we gotta do is hack that as good and fast as we can? >> >> Cheers, >> Richard ( it won't help current clients anyway, will it? ) > > Yes, it would; a client built from today's n.v.m head cannot speak to a > server running on a long-term-support operating system such as Debian > stable. Not can it speak to any other client a week old, for that > matter. This is bad enough that we might want to consider reverting the keys-by-hash change until we have protocol negotiation in place, however we wind up doing that. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
Richard Levitte writes: > stephen_leake> I agree; we should hold the next monotone release until > stephen_leake> netsync version negotiation is supported. > > So now, all we gotta do is hack that as good and fast as we can? > > Cheers, > Richard ( it won't help current clients anyway, will it? ) Yes, it would; a client built from today's n.v.m head cannot speak to a server running on a long-term-support operating system such as Debian stable. Not can it speak to any other client a week old, for that matter. This is acceptable for individualls or small teams but not for the scenario where a central server is involved. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Tue, Aug 25, 2009 at 04:42:50PM +0200, Richard Levitte wrote: > In message on Tue, 25 Aug 2009 07:36:20 > -0400, Stephen Leake said: > > stephen_leake> I agree; we should hold the next monotone release until > stephen_leake> netsync version negotiation is supported. > > So now, all we gotta do is hack that as good and fast as we can? > > Cheers, > Richard ( it won't help current clients anyway, will it? ) Not unless we can identify some kind of bitstring somewhere in the first packet or so that current clients always return that we can hijack as an kind of protocol ID. Just make sure that the new protocol never returns that bitstring. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Tue, Aug 25, 2009 at 07:36:20AM -0400, Stephen Leake wrote: > hend...@topoi.pooq.com writes: > > > On Tue, Aug 25, 2009 at 03:32:23AM -0400, Stephen Leake wrote: > >> Ludovic Brenta writes: > >> > >> > I am of the opinion that the next version of monotone should be 1.0 > >> > because of > >> > the netsync flag day. > >> > > >> > This would allow us, maintainers of monotone in Debian, to provide two > >> > versions of monotone in parallel: monotone (the latest) and monotone0 > >> > (0.44), > >> > or monotone1 and monotone. This would allow people to have both versions > >> > installed at the same time, without a clash. > >> > >> Makes sense; people dealing with more than one server will have > >> different flag days, and will need both clients until all transition. > >> > >> > I think this would be desirable because Debian 5.0 "Lenny" contains > >> > version > >> > 0.40, runs on many servers including www.ada-france.org, and will remain > >> > in > >> > service for at least another two years. Thus the transition period for > >> > the > >> > netsync change cannot be shorter than that. > >> > >> Can't people install a newer version of monotone on the server? > > > > As mentioned elsewjere, even if monotone were to support both versions > > of the protocol, it's the clients who would have to be updated first, > > because the existing protocol doesn't allow for version-negotiation, and > > the server sends the first packet. Let's try not to make this mistake > > again. > > I agree; we should hold the next monotone release until netsync version > negotiation is supported. > > >> Is there > >> some reason to stick to a "pure" Debian 5.0 version? > > > > There's a strong reluctance to bypass the Debian packaging system, > > because doing so leads to confusion about just what is installed on the > > system. > > > > This is what backports is for. We'd have to ask for backports to > > provide an up-to-date monotone. > > Ok. > > That's a good reason _not_ to bump required package versions over what > Debian 5.0 Lenny has now. Backports rules allow new backports when the new version ot the software reaches testing (at present, this is squeeze). So there will still be a period when ther new version is out but not yet available thtough backports. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Tue, Aug 25, 2009 at 08:04:02AM -0500, Timothy Brownawell wrote: > On Mon, 2009-08-24 at 21:17 -0400, hend...@topoi.pooq.com wrote: > > So this time around we're stuck. Well, not entirely. I suppose it *is* > > possible for a development group to upgrade all their clients first... > > And I suppose we could leave a monotone server that serves the > > new-protocol monotone source code running on the old protocol so that > > people are capable of upgrading. > > > > But could we install negotiation in the new protocol we're introducing > > now so that next time around we have a chance of avoiding this mess? > > There will be even more monotone users out there by then. I don't think > > we want monotone to end up like gnutella, which treats the use of an > > obsolete client as an attack. > > > > That's something I learned years back when I was implementing OSI > > protocols. Always negotiate the protocol version. > > I guess there are really 2 kinds of protocol changes we make: > 1) The actual data structures (certs, revisions, keys) change. > This would be like 'changesetify', or the current change, > or (probably) probably moving to SHA-3. > 2) Only the network part changes. > This would be moving to SSL, or changing how refinement works. > > In case (2) negotiation could be possible, but not in case (1). In case (1) it would be difficult, but there might still be a way to bridge the old and the new, dependint on just what the changes are. It might be possible, for example, to store both old-format certs and new-format ones. Or to have new certs certifying that the old ones are valid. The details will depend on the change being made. And if the change is severe enough it may still be impossible. If user communities are large enough and find migration difficult enough, a flag day may have the effect of forking the project. I don't think we're really at that point now, but we may be in a few years. > > We know there's an instance of case (1) coming up in about 3 years > (SHA-3), which will probably require a flag day (and a full history > rebuild). > > Before that, there's moving to SSL. This is case (2), so we could try to > add negotiation now to support it. Or we could make it possible for one > server to serve both SSL and non-SSL at the same time on different > ports, and not risk mucking up the nice encryption properties. > > I'd prefer to plan for the "different ports" solution for next time, > just because we're mucking around with the cryptography and want the > final result to be nice and clean at that level. That next time should > have plenty of planning, and we can come up with a decent negotiation > scheme (which we very well might not get a chance to use before SHA-3 > comes out :) ). In order to have a decent negotiation scheme next time, we have to have the elements of a bootstrap loader for the negotiation scheme this time. The standard way to negotiate a protocol version is for one system to send a packet identifying (among other information) the protocol versions it supports. Then the other responds with the verion it's chosen, and further communication proceeds with that one. Is there any reason not to use this technigue with the new protocol we're introducing now? We'd need to reserve a field in the first packet sent that identifies the protocol version. I've been told there already is such a field. Then we'd have to ensure that the first packet sent from the other end contains some fixed binary string. The initiator of the connection can take that as a confirmatino that the other end will speak the same protocol. Finally, the initiator has to refrain from sending further data (except maybe a retry of the initial packet) until it has received that confirmation. That's enough for us to be able to piggyback future protocol negotiations onto the new one we're putting out now. By the time we have to face this again, we'll be glad we have this one in place. We may not be expecting this to happen soon, but we weren't expecting this one, either. > > We'll also need to figure out how long to maintain compatibility for in > the case of type (2) changes, even though this probably won't be an > issue until after SHA-3 (unless we decide to allow for mixed hash types > in your history or something, seems vaguely dangerous) There probably are safe ways to do this. As long as you limit the time span during which old hashes can be created to the period in which they are still cryptographically sound. And you'd have to have some kind of marker on the hashes identifying which hash-coding was used for each hash. As well as some way of connecting old hashes with new ones. > Perhaps we also > want to limit 'db migrate' compatibility to the same time span? > > > > ___ > Monotone-devel mailing list > Monotone-devel@nongnu.org > http://lists.nongnu.org/mailman/listinf
Re: [Monotone-devel] Bumping required library versions
On Tue, Aug 25, 2009 at 4:56 AM, Stephen Leake wrote: > Zack Weinberg writes: >> I'd like to bump to: >> >> automake 1.11 >> autoconf 2.64 >> botan 1.8.2 or 1.8.3 >> sqlite 3.6.12 >> boost 1.34 or 1.35 > > As pointed out in the flag day discussion, it might be good to support > Debian 5.0 Lenny via backports of new monotone versions for a couple > more years. That means not bumping any package version higher than > what Lenny has: > > automake 1.10.1 > autoconf 2.61 > botan 1.7.8 > sqlite 3.5.9 > boost 1.35 I could live with these. It's unfortunate that we can't get a newer version of botan, but 1.7.8 is at least after the API change that's producing the largest number of #ifdefs in our code. > The Lenny backports requirements include building on Lenny with no > other backports, so these automake and autoconf versions are required. Debian builds from tarball releases that contain the automake and autoconf output, so technically we could get away with later versions, but if we ever needed to patch the configure script it would be a pain. Automake 1.10 is enough for the most important thing I want (native support for generating HTML from Texinfo). zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
In message on Tue, 25 Aug 2009 07:36:20 -0400, Stephen Leake said: stephen_leake> I agree; we should hold the next monotone release until stephen_leake> netsync version negotiation is supported. So now, all we gotta do is hack that as good and fast as we can? Cheers, Richard ( it won't help current clients anyway, will it? ) -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
Timothy Brownawell: > Before that, there's moving to SSL. This is case (2), so we could try to > add negotiation now to support it. Or we could make it possible for one > server to serve both SSL and non-SSL at the same time on different > ports, and not risk mucking up the nice encryption properties. Would it be possible to serve both variations on the same network port? I don't know netsync and how it does handshaking (if at all). But as I learned not long ago, for example SMTP uses plain and also SSL encrypted connections over the same port. Both end points negotiate about their capabilities and at some point one of them says "starttls" and the encryption handshake begins. Could be that most of the connection handling code would have to be rewritten to offer this feature. But everytime I read "let's use another port" the word "firewall" comes to my mind. Just my little thoughts... Greetings, Philipp signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Mon, 2009-08-24 at 21:17 -0400, hend...@topoi.pooq.com wrote: > So this time around we're stuck. Well, not entirely. I suppose it *is* > possible for a development group to upgrade all their clients first... > And I suppose we could leave a monotone server that serves the > new-protocol monotone source code running on the old protocol so that > people are capable of upgrading. > > But could we install negotiation in the new protocol we're introducing > now so that next time around we have a chance of avoiding this mess? > There will be even more monotone users out there by then. I don't think > we want monotone to end up like gnutella, which treats the use of an > obsolete client as an attack. > > That's something I learned years back when I was implementing OSI > protocols. Always negotiate the protocol version. I guess there are really 2 kinds of protocol changes we make: 1) The actual data structures (certs, revisions, keys) change. This would be like 'changesetify', or the current change, or (probably) probably moving to SHA-3. 2) Only the network part changes. This would be moving to SSL, or changing how refinement works. In case (2) negotiation could be possible, but not in case (1). We know there's an instance of case (1) coming up in about 3 years (SHA-3), which will probably require a flag day (and a full history rebuild). Before that, there's moving to SSL. This is case (2), so we could try to add negotiation now to support it. Or we could make it possible for one server to serve both SSL and non-SSL at the same time on different ports, and not risk mucking up the nice encryption properties. I'd prefer to plan for the "different ports" solution for next time, just because we're mucking around with the cryptography and want the final result to be nice and clean at that level. That next time should have plenty of planning, and we can come up with a decent negotiation scheme (which we very well might not get a chance to use before SHA-3 comes out :) ). We'll also need to figure out how long to maintain compatibility for in the case of type (2) changes, even though this probably won't be an issue until after SHA-3 (unless we decide to allow for mixed hash types in your history or something, seems vaguely dangerous). Perhaps we also want to limit 'db migrate' compatibility to the same time span? ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Bumping required library versions
Zack Weinberg writes: > If we're thinking about bumping the major version number to 1.0, that > would seem to be the right time to bump up our minimum library > requirements as well. We currently have backward compatibility > kludges in place for: > > - automake <1.11 (current: 1.11) > - autoconf <2.64 (current: 2.64) > - botan <1.7.22 (current: 1.8.5) > - sqlite <3.3.14 (current: 3.6.17) > - boost <1.3[45] (not sure exactly) (current: 1.39) > > I'd like to bump to: > > automake 1.11, autoconf 2.64 (these are both brand new, but only > developers need them) > > botan 1.8.2 or 1.8.3 (whichever is the earliest version that fixes the > "netsync server run as root on Linux hangs reading /proc/kmsg" bug) > > sqlite 3.6.12 (sqlite.org recommends upgrading from any version older than > this) > > boost 1.34 or 1.35 (whichever is the oldest version that provides > boost/circular_buffer.hpp, so we can drop our bundled copy) > > Thoughts? As pointed out in the flag day discussion, it might be good to support Debian 5.0 Lenny via backports of new monotone versions for a couple more years. That means not bumping any package version higher than what Lenny has: automake 1.10.1 autoconf 2.61 botan1.7.8 sqlite 3.5.9 boost1.35 The Lenny backports requirements include building on Lenny with no other backports, so these automake and autoconf versions are required. I think we should accept these requirements at least for this next release, which should include netsync protocol negotiation. After that, new clients will be able to cope with old servers, and there won't be such a strong need to support backports on Lenny. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
hend...@topoi.pooq.com writes: > On Tue, Aug 25, 2009 at 03:32:23AM -0400, Stephen Leake wrote: >> Ludovic Brenta writes: >> >> > I am of the opinion that the next version of monotone should be 1.0 >> > because of >> > the netsync flag day. >> > >> > This would allow us, maintainers of monotone in Debian, to provide two >> > versions of monotone in parallel: monotone (the latest) and monotone0 >> > (0.44), >> > or monotone1 and monotone. This would allow people to have both versions >> > installed at the same time, without a clash. >> >> Makes sense; people dealing with more than one server will have >> different flag days, and will need both clients until all transition. >> >> > I think this would be desirable because Debian 5.0 "Lenny" contains version >> > 0.40, runs on many servers including www.ada-france.org, and will remain in >> > service for at least another two years. Thus the transition period for the >> > netsync change cannot be shorter than that. >> >> Can't people install a newer version of monotone on the server? > > As mentioned elsewjere, even if monotone were to support both versions > of the protocol, it's the clients who would have to be updated first, > because the existing protocol doesn't allow for version-negotiation, and > the server sends the first packet. Let's try not to make this mistake > again. I agree; we should hold the next monotone release until netsync version negotiation is supported. >> Is there >> some reason to stick to a "pure" Debian 5.0 version? > > There's a strong reluctance to bypass the Debian packaging system, > because doing so leads to confusion about just what is installed on the > system. > > This is what backports is for. We'd have to ask for backports to > provide an up-to-date monotone. Ok. That's a good reason _not_ to bump required package versions over what Debian 5.0 Lenny has now. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Tue, Aug 25, 2009 at 03:32:23AM -0400, Stephen Leake wrote: > Ludovic Brenta writes: > > > I am of the opinion that the next version of monotone should be 1.0 because > > of > > the netsync flag day. > > > > This would allow us, maintainers of monotone in Debian, to provide two > > versions of monotone in parallel: monotone (the latest) and monotone0 > > (0.44), > > or monotone1 and monotone. This would allow people to have both versions > > installed at the same time, without a clash. > > Makes sense; people dealing with more than one server will have > different flag days, and will need both clients until all transition. > > > I think this would be desirable because Debian 5.0 "Lenny" contains version > > 0.40, runs on many servers including www.ada-france.org, and will remain in > > service for at least another two years. Thus the transition period for the > > netsync change cannot be shorter than that. > > Can't people install a newer version of monotone on the server? As mentioned elsewjere, even if monotone were to support both versions of the protocol, it's the clients who would have to be updated first, because the existing protocol doesn't allow for version-negotiation, and the server sends the first packet. Let's try not to make this mistake again. > Is there > some reason to stick to a "pure" Debian 5.0 version? There's a strong reluctance to bypass the Debian packaging system, because doing so leads to confusion about just what is installed on the system. This is what backports is for. We'd have to ask for backports to provide an up-to-date monotone. -- hendrik > > -- > -- Stephe > > > ___ > Monotone-devel mailing list > Monotone-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
Ludovic Brenta writes: > I am of the opinion that the next version of monotone should be 1.0 because of > the netsync flag day. > > This would allow us, maintainers of monotone in Debian, to provide two > versions of monotone in parallel: monotone (the latest) and monotone0 (0.44), > or monotone1 and monotone. This would allow people to have both versions > installed at the same time, without a clash. Makes sense; people dealing with more than one server will have different flag days, and will need both clients until all transition. > I think this would be desirable because Debian 5.0 "Lenny" contains version > 0.40, runs on many servers including www.ada-france.org, and will remain in > service for at least another two years. Thus the transition period for the > netsync change cannot be shorter than that. Can't people install a newer version of monotone on the server? Is there some reason to stick to a "pure" Debian 5.0 version? -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
Hi, Quoting "Timothy Brownawell" : Well, it depends on what you take the version numbers to mean. :) Full ACK. If it's ., then it makes perfect sense. Well, assuming a large enough user-base that "0.x == anything-goes" doesn't fly. AFAIUI that's how we used the version number so far. We didn't ever increment the major version for flag days. And I'd like to keep it that way for now. Some reasons for this one getting less discussion than otherwise are that it's fixing a longstanding bug with moderately severe consequences (which was starting to really annoy the pidgin people), that there wasn't anything else to batch it up with, and even to some extent that things have seemed rather dead lately. And that nobody said anything about it when I asked about merging the branch in two weekends ago. Yeah, I remember reading that mail, but didn't really gather the fact that it includes a flag day. Never mind, I understand the reasons for the change and I can easily handle the flag day for my own projects (mostly coordinating me with myself ;-) ). Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
